jQuery versions older than 3 are end of life.

Before we can update to jQuery 3, we need to update to jQuery UI 1.12.* because the version we're on at the moment (1.11.*) was released before jQuery 3 was available and isn't 100% compatible.

Proposed resolution

Update jQuery ui, need latest version with this patch: because of

Since the compile+split is not officially supported we might want to ship the whole thing at once. Makes it easier for maintainance.

This version only supports IE11 btw.

Remaining tasks

User interface changes

API changes

Data model changes

Members fund testing for the Drupal project. Drupal Association Learn more


nod_ created an issue. See original summary.

effulgentsia’s picture

This version only supports IE11 btw.

More detail on this in From there:

jQuery UI 1.11 officially dropped support for IE7 but left all the existing workarounds in place. jQuery UI 1.12 has removed all of the IE7 workarounds. In addition, official support for IE8, IE9, and IE10 have been removed, but the workarounds are still in place and will be removed in 1.13.

I'm not sure what that means yet in terms of our ability to upgrade, so tagging for framework manager review. Until we officially change our browser support matrix via #2390621: [policy, no patch] Discuss aligning Drupal's browser support with jQuery 3's. Decide on exceptions. or a similar issue, still says that IE9 is "a browser that is known to work well with Drupal 8 and support all of its features". If jQuery UI 1.12 still in fact retains all of the workarounds for IE9 and IE10 per above, then potentially we're okay to upgrade to it even if official support from jQuery UI is dropped. Though we might be putting ourselves at risk in terms of future patch releases of 1.12.x.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

effulgentsia’s picture

Priority: Normal » Major
Issue tags: -Needs framework manager review

While #2842298: [policy, no patch] Drop IE9 and IE10 support from Drupal 8.4.x is still under discussion, no one there has expressed concerns with doing the jQuery UI update. I discussed this issue with the framework and release managers, and all are in favor of it.

Per, this can go into 8.3 up until RC, but if people here are able to get it ready by Monday, it would be awesome to have it land before beta1, and thereby get wider testing during the beta phase.

Raising to Major, because AFAICT, jQuery UI does not release patch releases (even for critical bug fixes) for outdated minors, so we pretty much have to get onto the latest minor.

Wim Leers’s picture

Status: Needs work » Needs review
Issue tags: +JavaScript
711 bytes
893.41 KB

attached patch with vendor updated not the libs definitions.

Updated the libs definitions. It was less painful than I expected. :)

Wim Leers’s picture

Issue tags: +Needs manual testing

This needs manual testing of at least the following four:

  1. dialogs
  2. Quick Edit
  3. autocomplete
  4. CKEditor config UI

Status: Needs review » Needs work

The last submitted patch, 5: core-update-jquery-ui-1.12-2809427-5.patch, failed testing.

andypost’s picture

effulgentsia’s picture

+++ b/core/assets/vendor/jquery.ui/ui/core.js
@@ -0,0 +1,4 @@
+/*! jQuery UI - v1.12.2-pre - 2016-09-30

Looks like what's actually in the patch is 1.12.2-pre, which probably means wherever the branch tip was when the initial patch for this issue was made, which was on 2016-09-30. That's not good. We need a tagged release. Either 1.12.0 or 1.12.1 would be fine, since we can always do patch-level updates later, but since this needs to be rerolled anyway, I see no reason not to just get onto the latest one now.

xjm’s picture

Lots of JS tests failing also, which would seem germane here.

xjm’s picture

Version: 8.4.x-dev » 8.3.x-dev
Issue tags: +rc deadline

Marking explicitly for the RC deadline. Thereafter it would probably be 8.4.x-only given that it's a minor update and apparently has some disruption for us. Thanks!

andypost’s picture

sergeiimalyshev’s picture

Patch for 1.12.1.
Unfortunately I did not find the minimized js files, so they were compressed manually via

sergeiimalyshev’s picture

Version: 8.3.x-dev » 8.4.x-dev
Status: Needs work » Needs review

Status: Needs review » Needs work

The last submitted patch, 13: core-update-jquery-ui-1.12.1-2809427-13.patch, failed testing.

effulgentsia’s picture

8.3 RC is approaching fast (commit freeze for it will be early next week). Anyone have insight into #13's test failures?

xjm’s picture

Version: 8.4.x-dev » 8.3.x-dev

Let's keep this filed against 8.3.x until RC so we don't lose track of it. If it does not land by Feb. 28 we can move it back to 8.4.x. Note that it's possible to attach 8.4.x test runs to a patch even if the issue is filed against 8.3.x. Thanks!

xjm’s picture

Version: 8.3.x-dev » 8.4.x-dev
Issue tags: -rc deadline

Since 8.3.x is now in commit freeze for its release candidate phase, this minor version dependency update should now be targeted for 8.4.x. Thanks!

gnuget’s picture

I will work on this.

new patch in my next comment.


gnuget’s picture


I won't provide an interdiff because it is almost as big as the patch itself, I think is better start fresh.

We need to take some decisions before to merge this because jquery ui 1.12.1 has some changes that will require updating the way how we use it.

In particular on this

The "core" module that used to bundle various utilities is deprecated. Other source files no longer depend on core.js, which is now just a single define() call that specifies all the modules it previously bundled as dependencies.

And this

Core.js is not meant for manual inclusion in a page its simply backcompat for those using amd and refrencing the core module. This file was broken down into smaller modules. Just include the ones you need.

So, we have two options now, create a library per every new smaller module and deprecate jquery.ui

or do what I did it on this patch, basically instead to load the core-min.js on the jquery.ui library load all the smaller modules contained on that file, something like this:

  version: &jquery_ui_version 1.12.1
  license: &jquery_ui_license
    name: Public Domain
    gpl-compatible: true
    assets/vendor/jquery.ui/ui/data-min.js: { weight: -11, minified: true }
    assets/vendor/jquery.ui/ui/disable-selection-min.js: { weight: -11, minified: true }
    assets/vendor/jquery.ui/ui/form-min.js: { weight: -11, minified: true }
    assets/vendor/jquery.ui/ui/labels-min.js: { weight: -11, minified: true }
    assets/vendor/jquery.ui/ui/jquery-1-7-min.js: { weight: -11, minified: true }
    assets/vendor/jquery.ui/ui/scroll-parent-min.js: { weight: -11, minified: true }
    assets/vendor/jquery.ui/ui/tabbable-min.js: { weight: -11, minified: true }
    assets/vendor/jquery.ui/ui/unique-id-min.js: { weight: -11, minified: true }
    assets/vendor/jquery.ui/ui/version-min.js: { weight: -11, minified: true }
    assets/vendor/jquery.ui/ui/focusable-min.js: { weight: -11, minified: true }
    assets/vendor/jquery.ui/ui/ie-min.js: { weight: -11, minified: true }
    assets/vendor/jquery.ui/ui/keycode-min.js: { weight: -11, minified: true }
    assets/vendor/jquery.ui/ui/plugin-min.js: { weight: -11, minified: true }
    assets/vendor/jquery.ui/ui/safe-active-element-min.js: { weight: -11, minified: true }
    assets/vendor/jquery.ui/ui/safe-blur-min.js: { weight: -11, minified: true }
      assets/vendor/jquery.ui/themes/base/core.css: {}
      assets/vendor/jquery.ui/themes/base/theme.css: {}
    - core/jquery

other changes worth to mention:

Let me know what you think about the jquery.ui library.


gnuget’s picture

Status: Needs work » Needs review

Status: Needs review » Needs work

The last submitted patch, 20: core-update-jquery-ui-1.12.1-2809427-20.patch, failed testing.

gnuget’s picture

The first error was a typo in my side (duh!) and the second one is that jquery ui now use the unicode space character (\x00a0) instead to an empty string so I updated the test.

Let's see if I can make happy the testbot this time.


catch’s picture

Priority: Major » Critical
Issue summary: View changes
Issue tags: +blocker

Bumping this to critical because it blocks #2533498: Update jQuery to version 3 assuming we do them as separate patches. My understanding is we can do them together, or jQuery UI first, but not jQuery 3 first.

catch’s picture

There's a short mention of jQuery UI in the 3.0 release announcement:

cilefen’s picture

Issue tags: +Triaged D8 critical

As always, thank you for the hard work on this.

@xjm, @alexpott, @effulgentsia, @lauriii, @catch and I discussed this issue at a recent meeting and agreed that since this is blocking a critical, it should remain critical. If we run into issues upgrading UI, we should think about opening a jQuery migrate issue. Either this issue or the other will be critical so long as it is blocking #2533498: Update jQuery to version 3.

Status: Needs review » Needs work

The last submitted patch, 23: core-update-jquery-ui-1.12.1-2809427-23.patch, failed testing. View results

Manuel Garcia’s picture

Assigned: Unassigned » Manuel Garcia
Status: Needs work » Needs review
899.29 KB

Reroll of #23.

Manuel Garcia’s picture

4.25 MB

I did a bit of manual testing, on ckeditor configuration, which makes use of dialogs i think. See the gif attached, looks ok to me.

At the end the form fails to save, throwing Drupal\Core\Entity\EntityStorageException: 'editor' entity with ID 'basic_html' already exists.. That isn't related to jquery ui though, its a known bug: #2701393: Form API-induced madness: EntityStorageException when trying to save a predefined text format on clean installation

Still needs manual testing on quickedit and autocomplete as per #6

Manuel Garcia’s picture

1.1 MB

Here's a recording of testing quickedit on an article on the frontpage, everything seems to be working. Mind you that the autocomplete works for selecting the user within quickedit.

Manuel Garcia’s picture

1.65 MB

And here a recording of testing the autocomplete for the article tags field. Also working fine.

Leaving the Needs manual testing tag in place in case we can come up with other things to test, let me know =]

amateescu’s picture

Status: Needs review » Reviewed & tested by the community
Issue tags: -Needs manual testing

The animations of the manual testing and the patch looks great, let's do this :)

Wim Leers’s picture

It'd be great if somebody could apply #2828528: Add Quick Edit Functional JS test coverage plus this patch and confirm that it's passing. That's adding JS tests for Quick Edit, but due to testbot problems, that's not been committed yet :(

Manuel Garcia’s picture

@Wim Leers: Applied both patches, and ran the new test plus the modified QuickEditImageTest:


Testing Drupal\Tests\image\FunctionalJavascript\QuickEditImageTest

Time: 1.05 minutes, Memory: 6.00MB

There was 1 failure:

1) Drupal\Tests\image\FunctionalJavascript\QuickEditImageTest::testImageInPlaceEditor
Javascript condition met:
function () {
  var activeFieldID = Drupal.quickedit.collections.entities
    .filter(function (fieldModel) {
      var state = fieldModel.get('state');
        return state === 'active' || state === 'changed';
  return document.querySelector('[data-quickedit-field-id="' + activeFieldID + '"] .quickedit-image-dropzone') === null;
Failed asserting that false is true.


Tests: 1, Assertions: 53, Failures: 1.


Testing Drupal\Tests\editor\Kernel\QuickEditIntegrationTest

Time: 8.92 seconds, Memory: 6.00MB

OK (4 tests, 18 assertions)
Manuel Garcia’s picture

Assigned: Manuel Garcia » Unassigned
Wim Leers’s picture

#34: ❤️ Thank you so much!

Wim Leers’s picture

Given the manual testing in #30 + #31 by @Manuel Garcia and in #32 by @amateescu — let's get this in!

Any remaining problems can be surfaced during the alpha phase.

drpal’s picture


tedbow’s picture

Issue summary: View changes
43.91 KB
39.7 KB

Tested this out in relation to Settings Tray module. It extensively uses the JQuery UI dialogs.

We have a lot of JS testing of the module and it still passes so that is good sign!

I did some manual testing to see if there any other changes.

I did notice 1 small visual change. The edge of the tray after update has small white line.

Pre update, no white line

Post update, thin white line

Otherwise didn't notice any changes.

catch’s picture

Status: Reviewed & tested by the community » Fixed

Great to see this RTBC. Anything that comes up we should be able to resolve during alpha or roll back if we really have to, but wider testing seems like the best way to keep going with this.

Committed/pushed to 8.4.x, thanks!

  • catch committed e05bab8 on 8.4.x
    Issue #2809427 by gnuget, Manuel Garcia, Wim Leers, nod_,...
Wim Leers’s picture

gnuget’s picture

Thanks all for the help testing this. :-)

xjm’s picture

Issue tags: +8.4.0 release notes

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.