Core: Accept only jQuery 3.x-4.x, document supported jQuery versions

jQuery Migrate does two things:

1. Fills in removed APIs, warning when used.
2. Warns about deprecated APIs that still exist.

It makes sense to differentiate these two for a few reasons:

1. Teams may not always have the capacity to tackle all warnings, they may want to resolve just the ones that block Migrate removal and then remove Migrate, leaving resolving the other warnings for later, when they prepare for updating to the next major version.
2. A project may have already been on jQuery 3.x without Migrate and then it added Migrate to prepare for an update to jQuery 4.0. But Migrate would now also restore some APIs & behaviors removed in jQuery 3.0 which is counterproductive. Since gh-450, it's now possible to exclude warnings but this use case would require first determining those patches.

We should have an easier way to only enable patches required to address before removing Migrate or to only enable the ones preparing for the next major version.

Thoughts, @dmethvin @timmywil @gibson042?

Migrate warns against .removeAttr() called on boolean attributes as this used to set the associated property to false but it doesn't do so anymore since jQuery 3.0.0.

However, this is only an issue if the property wasn't already set to false. There are valid reasons to call removeAttr on boolean attributes and it shouldn't cause issues as long as the property is being updated first.

This is not just a theoretical concern - AngularJS sets both boolean properties & then associated attributes, calling removeAttr if the value passed was false. See a report about that at https://github.com/angular/angular.js/issues/16877. I also hit it at my employer when updating jQuery.

The proposal is to read the property and if it's already false, skip the warning.

Test Environment OS: Windows_11 Version: 21H2 OS Build: 22000.795 Browser: Version 103.0.1264.71 (Official Build) (64-bit) URL: eeee - Usage report - Skype Manager - Skype Screen Reader: Narrator User: hcltester200@outlook.com

Repro Steps:

1. Open the above-mentioned app.
2. Login with valid credentials.
3. Turn on Narrator via 'Ctrl+Win+Enter' keys.
4. Navigate to the ‘Features’ tab and activate it.
5. Allocate the skype credit then navigate to ‘Name’ column header.
6. Observe the issue here.

Actual Behavior: Incorrect role as 'link' is defined for the 'Name' column header sorted table button.

Expected Behavior: Correct information for 'Name' column header sorted table button should be announced by the narrator as 'Name button column header name then row information'.

https://user-images.githubusercontent.com/93735775/184137716-018d6a40-b70f-4e96-9cf7-31e5bce719a9.mp4

Test Environment OS: Windows_11 Version: 21H2 OS Build: 22000.795 Browser: Version 103.0.1264.71 (Official Build) (64-bit) URL: eeee - Usage report - Skype Manager - Skype Screen Reader: Narrator User: hcltester200@outlook.com

Repro Steps:

1. Open the above-mentioned app.
2. Login with valid credentials.
3. Turn on Narrator via 'Ctrl+Win+Enter' keys.
4. Navigate to the ‘Features’ tab and activate it.
5. Allocate the skype credit then navigate to ‘Name’ column header.
6. Observe the issue here.

Actual Behavior: Incorrect role as 'link' is defined for the 'Name' column header sorted table button.

Expected Behavior: Correct information for 'Name' column header sorted table button should be announced by the narrator as 'Name button column header name then row information'.

https://user-images.githubusercontent.com/93735775/184137716-018d6a40-b70f-4e96-9cf7-31e5bce719a9.mp4

Yes, it definitely doesn't look like a jQuery issue. Closing.

@rhu25 it hasn't been released yet. That said, we decided to postpone some of the tasks originally planned for 4.0 to 5.0 and we'll be working on preparing a 4.0.0 beta soon, maybe within the next few weeks.

That said, looking at the original report now, it seems the issue here may have lied elsewhere. The code path being modified was the one used for creating elements from passed HTML - and if you pass it as HTML with inline style definitions inside that element, you may very well trigger the same warning even if we don't modify the input.

That said, it's hard to tell without a test case. For now, you can try the jQuery Git build and see if it resolves your issue. Don't use it in production, though, as it's still a development version.

Summary

Due to the change of scope for 4.0.0, this re-introduces the selector-native module (removed in gh-4395) known from jQuery 3.x.

I wasn't sure what to name it as we shouldn't use the name Sizzle anymore so I opted for selector-full. Suggestions for better naming welcome.

Ref gh-4395

Checklist

• [x] New tests have been added to show the fix or feature works
• [ ] Grunt build and unit tests pass locally with these changes
• ~~If needed, a docs issue/PR was created at https://github.com/jquery/api.jquery.com~~

I find myself using the VSS/Controls/Dialogs in Web Extensión in tfs

Dialogs.showMessageDialog("Hello Word");

When trying to launch the confirmation window the following error is generated

in versión jQuery UI Widget 1.11.4 no error is displayed

in versión jQuery UI Widget 1.13.1 error id displayed

Internally the SDK is pointing to the version that fails (https://dev.azure.com/organization/_static/tfs/M208_20220803.13/_scripts/TFS/min/jQueryUI/widget.js), Microsoft recently updated the Jquery UI library but it fails

jQuery.uniqueSort was added in jQuery 1.12.0 but we're also filling it in for older jQuery versions in https://github.com/jquery/jquery-ui/blob/1.13.2/ui/jquery-patch.js#L36-L40. That file is included in the default build; if you're using a custom one, you need to include it if you use jQuery older than 3.5.0.

Thanks for the report! Fix at #2109.

The jquery-patch reference was included with the .js extension which is not allowed in AMD.

Fixes gh-2107

Could you read the attribute from document.documentElement instead? That’s always available.

The fact that body may not exist is the reason why jQuery switched to attaching elements used for support tests directly to documentElement instead of body in 2.1.0.

I tried swapping the blocks in ajax.js as @timmywil suggested in https://github.com/jquery/jquery/issues/4150#issuecomment-410866029 and all tests were still passing in the latest Chrome & Firefox.

Tests: Add a new esmodules flag, remove the raw one

Migrating from AMD to ES modules in gh-343 made the raw testing mode break as it relied on loading raw source files. This change removes the raw mode in favor of the new esmodules one.

Setup is different than in jQuery as jQuery uses AMD to load tests and Migrate just loads test files directly.

When Migrate is loaded via its source ES modules, test files are loaded as modules as well. This is necessary as module scripts behave as if loaded with the defer attribute so tests need to be deferred as well.

Iframe tests are skipped in esmodules mode as their setup is incompatible with the above considerations.

In addition to the above, Karma tests now also run in esmodules mode for easier verification this mode is not broken by PRs.

Closes gh-468 Ref gh-343

Migrating from AMD to ES modules in gh-343 made the raw testing mode break as it relied on loading raw source files. This change removes the raw mode in favor of the new esmodules one.

Setup is different than in jQuery as jQuery uses AMD to load tests and Migrate just loads test files directly.

When Migrate is loaded via its source ES modules, test files are loaded as modules as well. This is necessary as module scripts behave as if loaded with the defer attribute so tests need to be deferred as well.

Iframe tests are skipped in esmodules mode as their setup is incompatible with the above considerations.

In addition to the above, Karma tests now also run in esmodules mode for easier verification this mode is not broken by PRs.

Ref gh-343

@dependabot ignore this dependency

@fecore1 Can I ask you why you need to attach data to shadow roots? What's the use case?

Fixes gh-4018

Migrate has to make some shaky assumptions about the implementation of core's animations in order to warn about jQuery.fx.interval. It would be simpler if we used a private value for the interval value (basically just hard-code the default 13) so that any use of jQuery.fx.interval could be indentified as deprecated. There is a slight risk that someone might be changing that value but it seems unlikely since we are already ignoring it except for two rare-ish cases: 1) IE9 always, 2) browsers when the document is hidden.

In addition, per some discussion on https://github.com/jquery/jquery-migrate/pull/298 we may want to change from document.hidden to document.visibilityState since the standard has changed. From looking at caniuse.com it seems like IE10/IE11 support rAF and document.hidden but not document.visibilityState so I am not sure that is possible until we drop their support.

I missed it but we already removed jQuery.fx.interval in #5017.