@noraj the selector is invalid, it misses a closing attribute bracket. Try newline.find('label[for=mylabel]')

@juanca there is nothing on MDN that would claim start / end support in justify-self, which is perhaps why it's reported as supported since Safari 10.1. If those sub-entries were added, I'm sure the data would change.

As for align-content, this test case checks it: https://output.jsbin.com/hibahem/1. I also confirm it works in Safari 15.6 and does not work in Safari 14.1.

Tests: Fix selector tests in Chrome

For older Safari/iOS we needed to add the safari UA check as their reported WebKit version was not new enough. However, that check should have also excluded Chrome which was missed in the first iteration. This has been fixed.

Also, fix code formatting in test/unit/css.js.

Tests: Fix selector tests in Chrome

For older Safari/iOS we needed to add the safari UA check as their reported WebKit version was not new enough. However, that check should have also excluded Chrome which was missed in the first iteration. This has been fixed.

Also, fix code formatting in test/unit/css.js.

I changed in Typesetter CMS from UI 11.4 to 13.2 and suddenly get in the pagemanager the error in sortable.js : Uncaught TypeError: this.dragDirection is undefined . The string ' dragDirection' exists only in sortable.js 13.2 (with sortable.js v11.4 and ui 13.2 everything functions - and in sortable v11.4 exists no 'this.dragDirection' - so it must be the debugger : this.dragDirection exists 4 times in sortable.js 13.2) Is it really undefined , and if - how can i define the Type ? --- var dragDirection =""; in line 410 has no effect ? P.S. This error is not under Xampp but only in Web-installations.

Are you using the nestedSortable jQuery plugin? If so, it’s a duplicate of #1997.

Build: Migrate middleware-mockserver to modern JS

The test/middleware-mockserver.js file used to have the same ESLint settings applied as other test files that are directly run in tested browsers. Now it shares settings of other Node.js files.

The file is now also written using modern JS, leveraging ES2018.

Closes gh-5196

Build: Run GitHub Action browser tests on Playwright WebKit

So far, we've been running browser tests on GitHub Actions in Chrome and Firefox. Regular Safari is not available in GitHub Actions but Playwright WebKit comes close to a dev version of Safari.

With this change, our GitHub CI & local test runs will invoke tests on all actively developed browser engines on all PRs.

Also, our GitHub Actions browser tests are now running on Node.js 18.

Detection of the Playwright WebKit browser in support unit tests is done by checking if the test_browser query parameter is set to "Playwright"; this is a karma-webkit-launcher feature. Detecting that browser via user agent as we normally do is hard as the UA on Linux is very similar to a real Safari one but it actually uses a newer version of the engine.

In addition, we now allow to pass custom browsers when one needs it; e.g., to run the tests in all three engines on Linux/macOS, run:

grunt && BROWSERS=ChromeHeadless,FirefoxHeadless,WebkitHeadless grunt karma:main

Closes gh-5190

Ajax: Support binary data (including FormData)

Two changes have been applied:

• prefilters are now applied before data is converted to a string; this allows prefilters to disable such a conversion
• a prefilter for binary data is added; it disables data conversion for non-string non-plain-object data; for FormData bodies, it removes manually-set Content-Type header - this is required as browsers need to append their own boundary to the header

Ref gh-4150

Landed on main in b02a257f98688aa890e06a85672cd1a54c3ffa3a and on 3.x-stable (with slight modifications) in da7057e9b0d48afdf5666597279f0a24e9828bc8.

Build: Migrate middleware-mockserver to modern JS

The test/middleware-mockserver.js file used to have the same ESLint settings applied as other test files that are directly run in tested browsers. Now it shares settings of other Node.js files.

The file is now also written using modern JS, leveraging ES2018.

Closes gh-5196

Build: Run GitHub Action browser tests on Playwright WebKit

So far, we've been running browser tests on GitHub Actions in Chrome and Firefox. Regular Safari is not available in GitHub Actions but Playwright WebKit comes close to a dev version of Safari.

With this change, our GitHub CI & local test runs will invoke tests on all actively developed browser engines on all PRs.

Also, our GitHub Actions browser tests are now running on Node.js 18.

Detection of the Playwright WebKit browser in support unit tests is done by checking if the test_browser query parameter is set to "Playwright"; this is a karma-webkit-launcher feature. Detecting that browser via user agent as we normally do is hard as the UA on Linux is very similar to a real Safari one but it actually uses a newer version of the engine.

In addition, we now allow to pass custom browsers when one needs it; e.g., to run the tests in all three engines on Linux/macOS, run:

grunt && BROWSERS=ChromeHeadless,FirefoxHeadless,WebkitHeadless grunt karma:main

Closes gh-5190

Build: Run GitHub Action browser tests on Playwright WebKit

So far, we've been running browser tests on GitHub Actions in Chrome and Firefox. Regular Safari is not available in GitHub Actions but Playwright WebKit comes close to a dev version of Safari.

With this change, our GitHub CI & local test runs will invoke tests on all actively developed browser engines on all PRs.

Also, our GitHub Actions browser tests are now running on Node.js 18.

Detection of the Playwright WebKit browser in support unit tests is done by checking if the test_browser query parameter is set to "Playwright"; this is a karma-webkit-launcher feature. Detecting that browser via user agent as we normally do is hard as the UA on Linux is very similar to a real Safari one but it actually uses a newer version of the engine.

In addition, we now allow to pass custom browsers when one needs it; e.g., to run the tests in all three engines on Linux/macOS, run:

grunt && BROWSERS=ChromeHeadless,FirefoxHeadless,WebkitHeadless grunt karma:main

Closes gh-5190

(cherry picked from commit b02a257f98688aa890e06a85672cd1a54c3ffa3a)

Build: Run GitHub Action browser tests on Playwright WebKit

So far, we've been running browser tests on GitHub Actions in Chrome and Firefox. Regular Safari is not available in GitHub Actions but Playwright WebKit comes close to a dev version of Safari.

With this change, our GitHub CI & local test runs will invoke tests on all actively developed browser engines on all PRs.

Also, our GitHub Actions browser tests are now running on Node.js 18.

Detection of the Playwright WebKit browser in support unit tests is done by checking if the test_browser query parameter is set to "Playwright"; this is a karma-webkit-launcher feature. Detecting that browser via user agent as we normally do is hard as the UA on Linux is very similar to a real Safari one but it actually uses a newer version of the engine.

In addition, we now allow to pass custom browsers when one needs it; e.g., to run the tests in all three engines on Linux/macOS, run:

grunt && BROWSERS=ChromeHeadless,FirefoxHeadless,WebkitHeadless grunt karma:main

Closes gh-5190

(cherry picked from commit b02a257f98688aa890e06a85672cd1a54c3ffa3a)

@dmethvin I went ahead & merged it; we can sort out any potential Windows issues separately later.

Build: Run GitHub Action browser tests on Playwright WebKit

So far, we've been running browser tests on GitHub Actions in Chrome and Firefox. Regular Safari is not available in GitHub Actions but Playwright WebKit comes close to a dev version of Safari.

With this change, our GitHub CI & local test runs will invoke tests on all actively developed browser engines on all PRs.

Also, our GitHub Actions browser tests are now running on Node.js 18.

Detection of the Playwright WebKit browser in support unit tests is done by checking if the test_browser query parameter is set to "Playwright"; this is a karma-webkit-launcher feature. Detecting that browser via user agent as we normally do is hard as the UA on Linux is very similar to a real Safari one but it actually uses a newer version of the engine.

In addition, we now allow to pass custom browsers when one needs it; e.g., to run the tests in all three engines on Linux/macOS, run:

grunt && BROWSERS=ChromeHeadless,FirefoxHeadless,WebkitHeadless grunt karma:main

Closes gh-5190

Summary

So far, we've been running browser tests on GitHub Actions in Chrome and Firefox. Regular Safari is not available in GitHub Actions but Playwright WebKit comes close to a dev version of Safari.

With this change, our GitHub CI (& local test runs) will invoke tests on all actively developed browser engines on all PRs.

Also, switch our GitHub Actions browser tests to use Node.js 18.

In addition, we now allow to pass custom browsers when one needs it; e.g., to run the tests in all three engines on Linux/macOS, run:

grunt && BROWSERS=ChromeHeadless,FirefoxHeadless,WebkitHeadless grunt karma:main

I'd like to prepare a version for 3.x as well but that will be a bit more complex since the common AppleWebKit/605.1.15 token identifying Safari is only frozen in this version since Safari 13.

Checklist

• ~~New tests have been added to show the fix or feature works~~
• [x] 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~~

Landed on main in ce90a48450ba40586a6567235abb8fd2df84da97 & on 3.x-stable in 6b2abbdc46e9c4c37f515e838a7f820a4f2bb91a.

Build: Migrate middleware-mockserver to modern JS

The test/middleware-mockserver.js file used to have the same ESLint settings applied as other test files that are directly run in tested browsers. Now it shares settings of other Node.js files.

The file is now also written using modern JS, leveraging ES2018.

Closes gh-5196

(cherry picked from commit ce90a48450ba40586a6567235abb8fd2df84da97)

Build: Migrate middleware-mockserver to modern JS

The test/middleware-mockserver.js file used to have the same ESLint settings applied as other test files that are directly run in tested browsers. Now it shares settings of other Node.js files.

The file is now also written using modern JS, leveraging ES2018.

Closes gh-5196

(cherry picked from commit ce90a48450ba40586a6567235abb8fd2df84da97)

Build: Migrate middleware-mockserver to modern JS

The test/middleware-mockserver.js file used to have the same ESLint settings applied as other test files that are directly run in tested browsers. Now it shares settings of other Node.js files.

The file is now also written using modern JS, leveraging ES2018.

Closes gh-5196

Summary

The test/middleware-mockserver.js file used to have the same ESLint settings applied as other test files that are directly run in tested browsers. Now it shares settings of other Node.js files.

The file is now also written using modern JS, leveraging ES2018.

Checklist

• ~~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~~

(For simplicity, I'm talking exclusively about the non-qSA path as that's what's being triggered in Firefox for this invalid selector in jQuery 3.6.3.)

@timmywil @gibson042 I found what's up with this :before handling that we discussed at the team meeting. So, $('.foo:before,bar') always throws but $('.foo:before')throws only if $('.foo') doesn't match anything. The difference is caused by an optimization in: https://github.com/jquery/jquery/blob/c66d4700dcf98efccb04061d575e242d28741223/src/selector.js#L1575 where 1-elem selector lists are treated differently. Now, .foo:before looks like a class + a pseudo-class (just because of those legacy pseudo-elements allowing a single colon as well) and since .foo doesn't match anything, there's a bail out at: https://github.com/jquery/jquery/blob/c66d4700dcf98efccb04061d575e242d28741223/src/selector.js#L1615-L1621 On the other hand, .foo::before (with double colons) fails during tokenizing so $('.foo:before') does throw regardless of whether $('.foo') would match anything or not.

@dmethvin could you check if this works fine on Windows?