Problem/Motivation
A jQuery 4 beta is available https://blog.jquery.com/2024/02/06/jquery-4-0-0-beta/
Steps to reproduce
Proposed resolution
Try to update to it and see what we may need to change. For jQuery 3, there was a compat library, check if there is one now. This is the suggestion from the beta release announcement:
Upgrading
We do not expect compatibility issues when upgrading from a jQuery 3.0+ version. If you haven’t yet upgraded to jQuery 3.0, have a look at the 3.5 Upgrade Guide and 3.0 Upgrade Guide.
The jQuery Migrate plugin will help you to identify compatibility issues in your code. Please try out this beta release and let us know about any issues you experience.
Remaining tasks
#3296098: Removal :tabbable usage in dialog.js
User interface changes
API changes
Data model changes
Release notes snippet
| Comment | File | Size | Author |
|---|---|---|---|
| #36 | 3411839-nr-bot.txt | 90 bytes | needs-review-queue-bot |
Issue fork drupal-3411839
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
- 3411839-jquery4-again
changes, plain diff MR !7550
- 3411839-update-to-jquery4
changes, plain diff MR !6484
Comments
Comment #2
andypostComment #3
gábor hojtsyPostponing until the beta becomes available. It is not yet on https://github.com/jquery/jquery/tags
Comment #4
catchhttps://blog.jquery.com/2024/02/06/jquery-4-0-0-beta/
Comment #5
gábor hojtsyUpdated issue summary including update instructions from the beta post.
Comment #6
catchDownloaded and copied the following files over the existing equivalents. They aren't actually linked on the download page, so lucky the URLs are predictable, at least once I realised it wasn't beta1.
Updated core.libraries.yml
Did nothing else, I might be missing an obvious step, we'll find out.
I didn't add the jquery-migrate plugin because the update instructions seem confident that projects that have already updated to 3.5.0 or higher (we're on 3.7) won't need it and we should find out whether that's true for core or not.
We'll need figure out whether we'd want to add the migrate plugin for contrib/custom or not, whether in the core library or via an extra jquery_migrate module in core or contrib.
Comment #8
catchIf this passes automated tests, we should tag this for manual testing and try to test some js-heavy UIs - ckeditor5 with the media library, menu or taxonomy drag and drop, views, layout builder, contextual links etc.
If those all work, then I think we should run the beta in 11.x HEAD (requires branching 10.3.x) so we've got the greatest chance of hitting any edge cases and to make it easier for contrib to start testing. We could even do that without resolving the migrate plugin question initially.
Comment #9
dqd.
Comment #10
catchReal fails on
https://git.drupalcode.org/project/drupal/-/jobs/765398
https://git.drupalcode.org/project/drupal/-/jobs/765399
https://git.drupalcode.org/project/drupal/-/jobs/765412
e.g.
This should give us something to work with :)
I think we should split each error, or type of error, off to its own issue, they should all be committable to 10.3, then we can just keep rebasing/rerunning here until green unless we hit something bad.
Comment #11
larowlan+1 to splitting issues for the issues and to committing this early to 11.x
Comment #12
catchOpened #3419730: [jQuery 4] TypeError: $.isArray is not a function at states.Dependent.verifyConstraints which seems hopefully trivial even to my non-JavaScript brain.
Also opened #3419734: [jQuery 4] jquery-form is unmaintained and not jQuery 4 compatible, fork it into core which is not going to be as trivial because it's in a library. edit, postponed that on #3189416: [PP-1] Remove jQuery Form dependency from misc/ajax.js which we should try to get done and is responsible for 99% of the test failures.
Comment #14
spokjeRebased after #3419730: [jQuery 4] TypeError: $.isArray is not a function at states.Dependent.verifyConstraints was committed.
Comment #15
nod_We do have a whole thing for third party js deps so we don't have to copy/paste manually:
It'll get the code in the right place and update the version in core.libraries.yml
Comment #16
spokjeAbsolutely right and thank you @nod_
(Weirdly at least for me, this knowledge is somehow only popping up in my brain when doing the "upgrade JS dependencies"-issues just before a new major/minor release.)
We should have done this straight away, but at least the MR does it now.
Comment #17
catchCombining #3420499: [jQuery 4] position.js uses deprecated function $.isWindow() and #3419734: [jQuery 4] jquery-form is unmaintained and not jQuery 4 compatible, fork it into core with the update from here, all tests are green except nightwatch: https://git.drupalcode.org/project/drupal/-/pipelines/91662
Comment #18
nod_Comment #19
catch#3419734: [jQuery 4] jquery-form is unmaintained and not jQuery 4 compatible, fork it into core gives us a green test run for functional javascript, but it looks like there's still some nightwatch failures too, haven't looked those at all yet.
Edit: opened #3420713: Nightwatch tests fail with "unsupported pseudo: tabbable" after jQuery 4 update.
Comment #20
catch#3296098: Removal :tabbable usage in dialog.js might be the nightwatch failure.
Comment #21
catchComment #22
catchComment #23
catch#3296098: Removal :tabbable usage in dialog.js is the remaining blocker here.
Comment #24
catchComment #26
catchRebased the original branch here but getting unexplained CSS linting errors. So I redid the jQuery update steps posted above (not my original manual ones) in a new branch just in case it was a problem with the rebase.
Comment #28
catchThe new MR is passing, not sure what the difference is since the diff is the same.
I had to remove the dialog :tabbable shim integration test, the deprecation message is no longer fired, presumably this is because we updated dialog in the blocking issue and now with jQuery 4 that code isn't executed. Maybe someone else understands that test better than me and I've got it wrong, but also we've now unblocked #3278625: Deprecate/remove jquery.tabbable.shim so should just go ahead there. There's still coverage, just not via dialog any more.
Comment #29
catchLooking at the performance test failures, but also it looks like #3420713: Nightwatch tests fail with "unsupported pseudo: tabbable" after jQuery 4 update is still a problem so unpostponed that one.
Comment #30
finnsky commented@catch i think you can remove
core/tests/Drupal/Nightwatch/Tests/tabbableShimTest.js
at all.
it tests old tabbable jquery,
Comment #31
catch@finnsky we still have:
in core - isn't it the test coverage for that?
#3278625: Deprecate/remove jquery.tabbable.shim has been open for a long time, but was blocked on #3296098: Removal :tabbable usage in dialog.js.
I personally think to enable jQuery 4 testing for contrib, we should indeed remove the nightwatch coverage and sort out anything else later - it could mean going ahead and deprecating the tabbable shim in 10.3.0 for removal in 11.x and removing it from 11.x anyway. But would be good to get thoughts from FEFMs whether that's an acceptable approach.
I might do that to get a green MR here since the diff is pretty small. Any other approach we'll be blocked again here anyway, so it won't exactly hold it up.
Comment #32
catch@finnsky is right, we need to do it a 10.3 deprecation, I think but MR up on #3278625: Deprecate/remove jquery.tabbable.shim now.
I will include the 11.x commits from #3278625: Deprecate/remove jquery.tabbable.shim because it is just removals and it will allow us to get to a green test run here (hopefully).
Comment #33
nod_this should use the vendor-upgrade script to pull jQuery 4it already does, my bad.Comment #34
catchRe #33 yeah I didn't the first time because I didn't know it existed, but now I do (and it's very nice).
Comment #35
catch#3278625: Deprecate/remove jquery.tabbable.shim is RTBC and tests are green here (with those changes applied).
Comment #36
needs-review-queue-bot commentedThe Needs Review Queue Bot tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".
This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.
Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.
Comment #37
nod_Comment #38
smustgrave commented@nod_ asked in the #needs-review-queue-initative channel.
So seems that all child issues for this have been merged already into 11.x
Applied the MR and tried to do as suggested and go to heavy JS pages
On a standard install of 11.x for all test
1. Created a basic page
2. Tested all the buttons of the Full HTML formatter
3. Tested uploading an image
Enabled Media Library
1. Enabled the media button
2. Verified I could embed media just fine
Drag n drop
1. Went to the block layout to test this
2. Reordered some default blocks to different regions without issue
Enabled layout builder
1. Enabled for article content type
2. Moved around blocks
3. Added custom blocks
no issues
For 11.x believe this is good to go.
Comment #39
alexpottGonna needs work now that #3441844: Set budgets rather than exact numbers of asset size assertions landed...
Comment #40
catchRebase looks good, thanks for lowering the budgets!
Comment #43
nod_Committed f45c7bd and pushed to 11.x. Thanks!
awesome :)
Comment #45
quietone commentedUpdate version to the branch this applies to.