jQuery UI 1.13.0-rc.2 released

After a long break, it is our pleasure to announce the 1.13.0-rc.2 release. The release is feature-complete, we just wanted to give developers some time to test it & report any critical issues before we release the final. We didn’t find any such issues during our internal testing. If no blocking issues get reported, we expect to release 1.13.0 final in a few weeks.

You might be wondering what happened to 1.13.0-rc.1. A critical issue in the release script made the final built file not work at all, only individual AMD modules were fine. This made us not announce that release.

The main focus of this release was improving compatibility with recent jQuery versions so we postponed most breaking changes like removal of deprecated APIs and removal of legacy browser support to a possible future release.

Usage of deprecated jQuery APIs have been removed. jQuery UI 1.13 triggers no jQuery Migrate warnings when running its test suite against jQuery 3.6.0 with jQuery Migrate 3.3.2, i.e. the latest versions at the moment of this release.

Support for jQuery 1.7 has been dropped; jQuery 1.8 & newer remain supported.

In this release, all individual module files as well as bundled jQuery UI copies produced by the Download Builder have all its code running in strict mode. This shouldn’t matter for most users as jQuery has been running in strict mode since 3.0 released in 2016.

Apart from that, two small features were added:

  1. Accordion’s header option may now accept not only a selector matching header elements but also a function taking the accordion element as a parameter and returning the header elements; more details in the docs for the header option.
  2. Datepicker options now include the optional onUpdateDatepicker callback, called when the datepicker widget’s DOM is updated.

To simplify the maintenance of jQuery UI, we’re sunsetting the old bug tracker at https://bugs.jqueryui.com (we’ll keep it in read-only mode) in favor of GitHub issues.

jQuery UI has struggled with finding contributors for the past few years; our goal is to move it more to a maintenance state: we’ll make sure the library is compatible with new jQuery releases and that security issues are fixed but no new significant feature work is planned. We’ll also try to fix important regressions from jQuery UI 1.12.1; older long-standing bugs may not get fixed. We’ll get a longer blog post about the state of jQuery UI when we release 1.13 final. Note that this does not affect jQuery Core which is still actively maintained.

Download

File Downloads

Git (contains source files, with @VERSION not yet replaced with 1.13.0-rc.2, base theme only)

Comments

Note: please report bugs to the jQuery UI Bug Tracker; support questions should be posted on Stack Overflow with the jquery-ui tag. Please don’t use comments to report bugs.

If you have feedback on us doing our RC release for jQuery UI 1.13.0, feel free to leave a comment below. Thank you.

Source: jQuery UI

jQuery project updates addressing temporary CDN issues

As part of its ongoing infrastructure updates, the jQuery infrastructure team is making configuration and deployment changes to address intermittent outages reported by some users. The issue is the result of faulty IP allowlisting which affects users downloading jQuery project assets from certain IP addresses.

This issue is expected to be resolved in the next few weeks. In the interim, users can mitigate the issue by downloading and serving the files they need.

CDN migration is part of a package of infrastructure improvement projects the project has been undertaking this year. The infrastructure team plans to provide a full overview of these improvements, which will help support the long-term maintenance of jQuery and its related projects, later this summer.

jQuery continues to be a widely-used open source project with active maintainers. While many sites host jQuery locally, others rely upon the jQuery CDN to deliver the library on demand. On average, the jQuery CDN delivers over 2 petabytes of code per month. The project is hosted at the OpenJS Foundation, the vendor-neutral organization to grow and sustain the JavaScript and web ecosystem.

Source: jQuery

jQuery 3.6.0 Released!

jQuery 3.6.0 has been released! In jQuery 3.5.0, the major change was a security fix for the html prefilter. This release does not include a security fix, but does have some good bug fixes and improvements. We still have our eyes on a jQuery 4.0 release, but until then we will continue to support the 3.x branch and address important issues.

As usual, the release is available on our cdn and the npm package manager. Other third party CDNs will probably have it soon as well, but remember that we don’t control their release schedules and they will need some time. Here are the highlights for jQuery 3.6.0:

Returning JSON even for JSONP errors

You may have guessed from the minor version that a feature snuck into this release. In previous versions, when a JSONP request responded with an error, often the response was still an executable script. We’ve changed the default behavior to try and execute the response in this situation. Normal scripts will still be skipped when an error is encountered. See gh-4771 for more information.

Fixes

One bug worth highlighting has to do with redirecting focus to another element in a focus handler. Take this example where a focus handler is triggered inside another focus handler:

elem1.on( "focus", function() {
  elem2.trigger( "focus" );
} );

Due to their synchronous nature everywhere outside of IE, a fix added in 3.4.0 to leverage native events caused the native .focus() method to be called last for the initial element, making it steal the focus back. While the code continues to leverage native focus and blur events, we were able to fix this by aligning even more with native methods and only propagating the last focus event up the DOM tree.

Other bug fixes and improvements include a fix for retrieving dimensions on table rows in Firefox, a fix for a crash in Chrome when a focusout event was triggered on a removed element, several improvements to some tests, and more. You’ll find the full changelog below.

Upgrading

Aside from the change to no longer ensure XHTML-compliant tags for you, we do not expect other compatibility issues when upgrading from a jQuery 3.0+ version. To upgrade, have a look at the new 3.5 Upgrade Guide. If you haven’t yet upgraded to jQuery 3+, first have a look at the 3.0 Upgrade Guide.

The jQuery Migrate plugin will help you to identify compatibility issues in your code. Please try out this new release and let us know about any issues you experienced.

If you can’t yet upgrade to 3.5+, Daniel Ruf has kindly provided patches for previous jQuery versions.

Download

You can get the files from the jQuery CDN, or link to them directly:

https://code.jquery.com/jquery-3.6.0.js

https://code.jquery.com/jquery-3.6.0.min.js

You can also get this release from npm:

npm install jquery@3.6.0

Slim build

Sometimes you don’t need ajax, or you prefer to use one of the many standalone libraries that focus on ajax requests. And often it is simpler to use a combination of CSS and class manipulation for web animations. Along with the regular version of jQuery that includes the ajax and effects modules, we’ve released a “slim” version that excludes these modules. The size of jQuery is very rarely a load performance concern these days, but the slim build is about 6k gzipped bytes smaller than the regular version. These files are also available in the npm package and on the CDN:

https://code.jquery.com/jquery-3.6.0.slim.js

https://code.jquery.com/jquery-3.6.0.slim.min.js

These updates are already available as the current versions on npm and Bower. Information on all the ways to get jQuery is available at https://jquery.com/download/. Public CDNs receive their copies today, please give them a few days to post the files. If you’re anxious to get a quick start, use the files on our CDN until they have a chance to update.

Thanks

Thank you to all of you who participated in this release by submitting patches, reporting bugs, or testing, including Dallas Fraser, Michal Golebiowski-Owczarek, Wonseop Kim, Wonhyoung Park, Beatriz Rezener, Natalia Sroka, and the whole jQuery team.

Changelog

Full changelog: 3.6.0

Ajax

Core

Deferred

Dimensions

  • Modify reliableTrDimensions support test to account for FF (#4529, bcd40aa7)

Docs

  • Change JS Foundation mentions to OpenJS Foundation (db43ef0b)

Event

Selector

Support

  • ensure display is set to block for the support div (#4844) (#4832, f8bdb127)

Tests

  • Fix tests for not auto-executing scripts without dataType (7298e04f)
  • Skip the jQuery.parseXML error reporting test in Legacy Edge (bf06dd47)
  • Fix the jQuery.parseXML error reporting test (1ec36332)
  • Recognize callbacks with dots in the Node.js mock server (4c572a7f)
  • Skip the “jQuery.ajax() on unload” test in Safari (4f016c64)
  • Remove an unused local variable (beea433d)
  • Remove remaining obsolete jQuery.cache references (5e028c76)
  • Remove obsolete jQuery data tests (8ad78cdb)

Source: jQuery

jQuery 3.5.1 Released: Fixing a Regression

I’ve never gotten to say this on a jQuery release, but May the 4th be with you! A short time ago in a galaxy exactly like this one, we released jQuery 3.5.0. We have a quick fix for a regression in that release.

Specifically, we had changed our internal data object to use Object.create( null ) instead of a plain object ({}). We did that to prevent collisions with keys on Object.prototype properties. However, this also meant that users (especially plugins) could no longer check what was in jQuery data with the native .hasOwnProperty() method, and it broke some code. We’ve reverted that change, but plan to put it back in jQuery 4.0. This change is the only code change in this release. Other changes include some minor updates to our docs and build system.

Security fixes in 3.5.0

jQuery 3.5.0 included fixes for two security issues in jQuery’s DOM manipulation methods, as in .html(), .append(), and the others. Security advisories for both of these issues have been published on GitHub. While we provided all of the details on the first issue in the jQuery 3.5.0 blog post, we did not provide all of the details on the second and would like to do that in this post.

The second issue was very similar to the first. It was an XSS vulnerability that had to do with passing <option> elements to jQuery’s DOM manipulation methods. Essentially, we’re using a regex to wrap <option> elements with <select> elements to ensure those elements get parsed correctly in old IE (IE <= 9 replaces any <option> tags with their contents when inserted outside of a <select> element).

Our fix is to only apply this code where it is needed. Fortunately, because of the different parsing behavior in IE9, we can keep the fix in IE9 without exposing it to the same vulnerability as other browsers. Please upgrade when you get a chance to avoid these vulnerabilities.

Upgrading

If you haven’t yet upgraded to jQuery 3.5, have a look at the 3.5 Upgrade Guide. If you haven’t yet upgraded to jQuery 3+, first have a look at the 3.0 Upgrade Guide. Also, the jQuery Migrate plugin will help you to identify compatibility issues in your code.

If you can’t yet upgrade to 3.5+, Daniel Ruf has kindly provided patches for previous jQuery versions. Please try out this new release and let us know about any issues you experienced.

Download

You can get the files from the jQuery CDN, or link to them directly:

https://code.jquery.com/jquery-3.5.1.js

https://code.jquery.com/jquery-3.5.1.min.js

You can also get this release from npm:

npm install jquery@3.5.1

Slim build

Sometimes you don’t need ajax, or you prefer to use one of the many standalone libraries that focus on ajax requests. And often it is simpler to use a combination of CSS and class manipulation for web animations. Along with the regular version of jQuery that includes the ajax and effects modules, we’ve released a “slim” version that excludes these modules. The size of jQuery is very rarely a load performance concern these days, but the slim build is about 6k gzipped bytes smaller than the regular version. These files are also available in the npm package and on the CDN:

https://code.jquery.com/jquery-3.5.1.slim.js

https://code.jquery.com/jquery-3.5.1.slim.min.js

These updates are already available as the current versions on npm and Bower. Information on all the ways to get jQuery is available at https://jquery.com/download/. Public CDNs receive their copies today, please give them a few days to post the files. If you’re anxious to get a quick start, use the files on our CDN until they have a chance to update.

Thanks

Thank you to all of you who participated in this release by submitting patches, reporting bugs, or testing, including Pierre Grimaud, Michal Golebiowski-Owczarek, Ed S, vanillajonathan, and the whole jQuery team.

Changelog

Full changelog: 3.5.1

Build

  • Test on Node.js 14, stop testing on Node.js 8 & 13 (205dd134)
  • Enable reportUnusedDisableDirectives in ESLint (b21d6710)
  • Updating the 3.x-stable version to 3.5.1-pre. (898784ab)

Data

Docs

Tests

  • Workaround failures in recent XSS tests in iOS 8 – 12 (ea2d0d50)
  • Add tests for recently fixed manipulation XSS issues (58a8e879)
  • Cleanup `window` & `document` handlers in a new event test (c1c0598d)
  • Fix flakiness in the “jQuery.ajax() – JSONP – Same Domain” test (46ba70c5)

Source: jQuery

jQuery 3.5.0 Released!

jQuery 3.5.0 has been released! As usual, the release is available on our cdn and the npm package manager. Other third party CDNs will probably have it soon as well, but remember that we don’t control their release schedules and they will need some time.

We hope you’re staying healthy and safe while so many of us are stuck at home. With a virus ravaging the planet, we realize that jQuery may not be a high priority for you or the sites you manage. When you do have a moment, we recommend that you review this new version and upgrade.

Security Fix

The main change in this release is a security fix, and it’s possible you will need to change your own code to adapt. Here’s why: jQuery used a regex in its jQuery.htmlPrefilter method to ensure that all closing tags were XHTML-compliant when passed to methods. For example, this prefilter ensured that a call like jQuery("<div class='hot' />") is actually converted to jQuery("<div class='hot'></div>"). Recently, an issue was reported that demonstrated the regex could introduce a cross-site scripting (XSS) vulnerability.

The HTML parser in jQuery <=3.4.1 usually did the right thing, but there were edge cases where parsing would have unintended consequences. The jQuery team agreed it was necessary to fix this in a minor release, even though some code relies on the previous behavior and may break. The jQuery.htmlPrefilter function does not use a regex in 3.5.0 and passes the string through unchanged.

If you absolutely need the old behavior, using the latest version of the jQuery migrate plugin provides a function to restore the old jQuery.htmlPrefilter. After including the plugin you can call jQuery.UNSAFE_restoreLegacyHtmlPrefilter() and jQuery will again ensure XHTML-compliant closing tags.

However, to sanitize user input properly, we also recommend using dompurify with the SAFE_FOR_JQUERY option to sanitize HTML from a user. If you don’t need the old behavior, but would still like to sanitize HTML from a user, dompurify should be used without the SAFE_FOR_JQUERY option, starting in jQuery 3.5.0. For more details, please see the 3.5 Upgrade Guide.

Features

With what we call “positional selectors” being deprecated and slated for removal in jQuery 4.0, we’ve added the last two necessary replacement methods. Specifically, we’ve added the .even() and .odd() methods to replace the :even and :odd selectors. With these methods in place, we can safely remove these overly complicated selectors in jQuery 4.0.

Another small feature that we’ve added to this release is the ability to add a context to jQuery.globalEval. This was done as part of fixing a bug with script execution in iframes.

Fixes

One bug worth highlighting is a bug we fixed in the Ajax script transport. jQuery used to evaluate any response to a request for a script as a script, which is not always the desired behavior. This is different than other data types where such a convention was fine (e.g. in the case of JSON). jQuery 3.5.0 will now only evaluate successful HTTP responses.

Other bug fixes and improvements include performance improvements in Sizzle, support for massive arrays in jQuery.map, using the native .flat() method where supported, a fix for syntax errors in the AMD modules, several improvements to our testing infrastructure, and more. You’ll find the full changelog below.

Deprecations

It wouldn’t be a jQuery release without some deprecations. In jQuery 3.5.0, we’ve put jQuery.trim on the list. JavaScript’s own String.prototype.trim() is an easy replacement for it.

We’ve also put AJAX event aliases on the list, they can be replaced by .on("ajaxStart", …) and the like. jQuery Migrate will warn about these now-deprecated methods, but they’ll stick around until jQuery 4.0.

Upgrading

Aside from the change to no longer ensure XHTML-compliant tags for you, we do not expect other compatibility issues when upgrading from a jQuery 3.0+ version. To upgrade, have a look at the new 3.5 Upgrade Guide. If you haven’t yet upgraded to jQuery 3+, first have a look at the 3.0 Upgrade Guide.

The jQuery Migrate plugin will help you to identify compatibility issues in your code. Please try out this new release and let us know about any issues you experienced.

If you can’t yet upgrade to 3.5+, Daniel Ruf has kindly provided patches for previous jQuery versions.

Download

You can get the files from the jQuery CDN, or link to them directly:

https://code.jquery.com/jquery-3.5.0.js

https://code.jquery.com/jquery-3.5.0.min.js

You can also get this release from npm:

npm install jquery@3.5.0

Slim build

Sometimes you don’t need ajax, or you prefer to use one of the many standalone libraries that focus on ajax requests. And often it is simpler to use a combination of CSS and class manipulation for web animations. Along with the regular version of jQuery that includes the ajax and effects modules, we’ve released a “slim” version that excludes these modules. The size of jQuery is very rarely a load performance concern these days, but the slim build is about 6k gzipped bytes smaller than the regular version. These files are also available in the npm package and on the CDN:

https://code.jquery.com/jquery-3.5.0.slim.js

https://code.jquery.com/jquery-3.5.0.slim.min.js

These updates are already available as the current versions on npm and Bower. Information on all the ways to get jQuery is available at https://jquery.com/download/. Public CDNs receive their copies today, please give them a few days to post the files. If you’re anxious to get a quick start, use the files on our CDN until they have a chance to update.

Thanks

Thank you to all of you who participated in this release by submitting patches, reporting bugs, or testing, including Ahmed S. El-Afifi, Michal Golebiowski-Owczarek, Wonseop Kim, Dave Methvin, Shashanka Nataraj, Pat O’Callaghan, Sean Robinson, Christian Oliff, Christian Wenz, and the whole jQuery team.

We also would like to thank Masato Kinugawa for helping us identify and fix the security-related issues in this release.

Changelog

Full changelog: 3.5.0

Ajax

  • Do not execute scripts for unsuccessful HTTP responses (#4250, #4655, da3dd85b)
  • Overwrite s.contentType with content-type header value, if any (#4119, 065143c2)
  • Deprecate AJAX event aliases, inline event/alias into deprecated (7a3cf9c0)

Build

  • Resolve Travis config warnings (7506c9ca)
  • Enable ESLint one-var rule for var declarations in browser code (0fdfdd82)
  • Test the no-Sizzle build on Travis (362075ae)
  • Update .mailmap & AUTHORS.txt (19f2dcba)
  • Tests: Fix custom build tests, verify on Travis; name Travis jobs (d525ae34)
  • Lint the minified jQuery file as well (#3075, 37df5cdf)
  • Make Karma work in AMD mode (46c284b1)
  • Create a `grunt custom:slim` alias for the Slim build (4cbdc745)
  • Run tests on Travis only on browsers defined in the config (471b0043)
  • Run tests on Firefox ESR as well (0a73b94a)
  • Run tests on Node.js 13 in addition to 8, 10 & 12 (64c1fcc1)
  • Drop workarounds for Node.js 6 in Gruntfile.js (9f4204ec)
  • Run tests on Travis on FirefoxHeadless as well (ad3c2efa)
  • Require strict mode in Node.js scripts via ESLint (ac2da4e6)
  • Support jquery-release –dry-run flag (c7a5e1bd)
  • Stop copying src/core.js to dist on release (#4489, 279d2e97)
  • ESLint: forbid unused function parameters (d7e13f12)
  • Fix the regex parsing AMD var-modules (#4389) (36b59c96)

Core

  • Ajax: Align nonce & global with master, fix an AMD issue (22bf701f)
  • Fire iframe script in its context, add doc param in globalEval (#4518, 3dedc3f2)
  • Deprecate jQuery.trim (#4363, 56e73e0c)
  • Use Array.prototype.flat where supported (#4320, 2f666c1d)
  • Implement .even() & .odd() to replace POS :even & :odd (409cbda7)

CSS

  • Workaround buggy getComputedStyle on table rows in IE/Edge (#4490, 6d31477a)

Data

  • Event:Manipulation: Prevent collisions with Object.prototype (#3256, 413ff796)

Docs

  • Update links to EdgeHTML issues to go through Web Archive (d72faced)
  • Convert link to Homebrew from HTTP to HTTPS (ff5a43eb)

Effect

  • Fix a unnecessary conditional statement in .stop() (#4374, 30f5c6c3)

Event

  • Use only one focusin/out handler per matching window & document (#4652, 9e15d6b4)
  • Only attach events to objects that accept data – for real (#4397, f36f6abb)

Manipulation

  • Skip the select wrapper for option elements
  • Make jQuery.htmlPrefilter an identity function (1d61fd94)

Offset

Selector

Tests

  • Blacklist one focusin test in IE (1a4f10dd)
  • Pass a number of necessary done() calls to assert.async() (5ea844f6)
  • Make the support tests pass on Firefox 4x/5x/60 (f0d5ec62)
  • Skip a “width/height on a table row with phantom borders” test in Firefox (c79e1d5f)
  • Don’t test synchronous XHR on unload in Chrome (c5b48c8c)
  • Fix offset fractions tests in Chrome for Android (0c67da4b)
  • Move Android user agent detection above iOS, put Safari last (6276cb2e)
  • Make support tests accept Safari 13 & newer (8167327f)
  • update npo.js and include unminified source instead (3654bc83)

Traversing

  • Fix contents() on object elements with children in IE (90f78b9a)
  • Fix contents() on object elements with children (#4384, 42badf34)

Source: jQuery

jQuery 3.4.1: triggering focus events in IE and finding root elements in iOS 10

Hello again! jQuery 3.4.0 was released just three weeks ago, but we’ve had a few issues reported that warranted a patch release. Thank you to everyone that reported issues and helped us get these fixed quickly. Here are the changes:

Triggering focus or blur more than once in IE

jQuery 3.4.0 came with some changes to the way the event handler triggered native events such focus and blur. These changes caused a regression that sometimes resulted in an enigmatic error being thrown in the form of "saved.shift is not a function". This is now fixed.

Example

// Error thrown in IE10-11
// after clicking #test-element twice
jQuery("#test-element").click(function() {
  jQuery(this).trigger("blur");
});

Checking element attachment in iOS 10.0-10.2

When releasing 3.4.0, we ran our tests in several versions of iOS, including iOS 10.3 but not 10.0-10.2. Those versions do not support a native function we use to determine whether an element is attached to the DOM. Other versions of iOS were not affected. We added a guard to ensure that this method exists and fall back to other options if necessary.

Loading jQuery with AMD

A small module was added in jQuery 3.4.0 that used the global jQuery rather than the local jQuery loaded with AMD. This resulted in "jQuery is undefined" errors when loading with AMD, but this should now be fixed.

 


Upgrading

There should be no compatibility issues if upgrading from jQuery 3.0+. If you haven’t yet upgraded to jQuery 3+, please have a look at the 3.0 Upgrade Guide. The jQuery Migrate 3.0 plugin will help you to identify compatibility issues in your code.

Please try out this new release and let us know about any issues you experienced.

Download

You can get the files from the jQuery CDN, or link to them directly:

https://code.jquery.com/jquery-3.4.1.js

https://code.jquery.com/jquery-3.4.1.min.js

You can also get this release from npm:

npm install jquery@3.4.1

Slim build

Sometimes you don’t need ajax, or you prefer to use one of the many standalone libraries that focus on ajax requests. And often it is simpler to use a combination of CSS and class manipulation for web animations. Along with the regular version of jQuery that includes the ajax and effects modules, we’ve released a “slim” version that excludes these modules. The size of jQuery is very rarely a load performance concern these days, but the slim build is about 6k gzipped bytes smaller than the regular version. These files are also available in the npm package and on the CDN:

https://code.jquery.com/jquery-3.4.1.slim.js

https://code.jquery.com/jquery-3.4.1.slim.min.js

These updates are already available as the current versions on npm and Bower. Information on all the ways to get jQuery is available at https://jquery.com/download/. Public CDNs receive their copies today, please give them a few days to post the files. If you’re anxious to get a quick start, use the files on our CDN until they have a chance to update.

Thanks

Thank you to all of you who participated in this release by submitting patches, reporting bugs, or testing, including Richard Gibson, Michal Golebiowski-Owczarek, and the whole jQuery team.

Changelog

GitHub changelog: Issues fixed in 3.4.1 | All changes

Build

  • Fix unresolved jQuery reference in finalPropName (#4358, 0d4af529)

Core

Event

  • Prevent leverageNative from registering duplicate dummy handlers (6c1e7dbf)
  • Fix handling of multiple async focus events (#4350, 24d71ac7)

Source: jQuery

jQuery 3.4.0 Released

jQuery has a new release! It’s been a while since our last release, but we expect this to be the last minor release in the 3.x branch, and then we will move on to the overhaul that will be jQuery 4.0. But before we get to 4.0, we’re excited to share the bug fixes and improvements included in jQuery 3.4.0. Here are some of the highlights:

Performance improvement in .width and .height

When getting and setting dimensions, there were certain cases where this could cause layout thrashing, which basically means that the browser calculated layout more times than necessary. We fixed this in all browsers except IE, where it can’t be avoided.

nonce and nomodule support

To support adding script elements through methods like .html and .append, jQuery separates them and appends new script tags to load and execute the remote content. During this process, attributes such as nonce and nomodule were ignored, but jQuery 3.4.0 now hangs onto them.

Radio elements: expected state in event handlers

We had already fixed the same issue with checkboxes, but accidentally left out radio inputs. In the following example, true was logged the first time the element was clicked. We fixed it so that the checked property is updated before the event handler is executed.

Example

var $radios = jQuery(".example");
var $firstRadio = $radios.first();
var firstCheckedState = $firstRadio.prop("checked");
$radio.on("click", function() {
  // true in <3.4.0
  console.log($firstRadio.prop("checked") === firstCheckedState);
});
$radios.eq(1).click();

Minor vulnerability fix: Object.prototype pollution

jQuery 3.4.0 includes a fix for some unintended behavior when using jQuery.extend(true, {}, ...). If an unsanitized source object contained an enumerable __proto__ property, it could extend the native Object.prototype. This fix is included in jQuery 3.4.0, but patch diffs exist to patch previous jQuery versions.

Example

jQuery.extend(true, {},
  JSON.parse('{"__proto__": {"test": true}}')
);
console.log( "test" in {} ); // true

Note that while jQuery does its best to protect users from security vulnerabilities, jQuery is a DOM manipulation library that will generally do what you tell it to do. In this case, the behavior was likely unexpected, so jQuery.extend will no longer write any properties named __proto__. But guards such as this one are not replacements for good security practices such as user input sanitization.

Deprecating positional selectors and the sunset of Sizzle

The basic API of jQuery is to select something and then do something with what was selected. Sizzle, the selector engine in jQuery, handles the first half. It’s been a fast and efficient little engine that has paved the way for native selector APIs like querySelectorAll and additional native JavaScript and CSS selectors. Now that many of these selectors have made their way into modern browsers, it’s almost time to say goodbye to Sizzle. But in order to remove Sizzle in jQuery 4.0, we will also need to remove what we refer to as positional selectors, which are non-standard selectors.

Specifically, jQuery 3.4.0 is deprecating :first, :last, :eq, :even, :odd, :lt, :gt, and :nth. When we remove Sizzle, we’ll replace it with a small wrapper around querySelectorAll, and it would be almost impossible to reimplement these selectors without a larger selector engine.

We think this trade-off is worth it. Keep in mind we will still support the positional methods, such as .first, .last, and .eq. Anything you can do with positional selectors, you can do with positional methods instead. They perform better anyway.

Upgrading

There should be no compatibility issues if upgrading from jQuery 3.0+. If you haven’t yet upgraded to jQuery 3+, please have a look at the 3.0 Upgrade Guide. The jQuery Migrate 3.0 plugin will help you to identify compatibility issues in your code.

Please try out this new release and let us know about any issues you experienced.

Download

You can get the files from the jQuery CDN, or link to them directly:

https://code.jquery.com/jquery-3.4.0.js

https://code.jquery.com/jquery-3.4.0.min.js

You can also get this release from npm:

npm install jquery@3.4.0

Slim build

Sometimes you don’t need ajax, or you prefer to use one of the many standalone libraries that focus on ajax requests. And often it is simpler to use a combination of CSS and class manipulation for web animations. Along with the regular version of jQuery that includes the ajax and effects modules, we’ve released a “slim” version that excludes these modules. The size of jQuery is very rarely a load performance concern these days, but the slim build is about 6k gzipped bytes smaller than the regular version. These files are also available in the npm package and on the CDN:

https://code.jquery.com/jquery-3.4.0.slim.js

https://code.jquery.com/jquery-3.4.0.slim.min.js

These updates are already available as the current versions on npm and Bower. Information on all the ways to get jQuery is available at https://jquery.com/download/. Public CDNs receive their copies today, please give them a few days to post the files. If you’re anxious to get a quick start, use the files on our CDN until they have a chance to update.

Thanks

Thank you to all of you who participated in this release by submitting patches, reporting bugs, or testing, including abnud1, Jason Bedard, buddh4, Kris Borchers, Andrei Fangli, Oleg Gaidarenko, Richard Gibson, Michal Golebiowski-Owczarek, Marja Hölttä, Dave Methvin, Ed S, Luis Emilio Velasco Sanchez, Saptak Sengupta, tmybr11, Bert Zhang, and the whole jQuery team.

Changelog

GitHub changelog: Issues fixed in 3.4.0 | All changes

Ajax

Core

  • Use isAttached to check for attachment of element (662083ed)
  • Tiny efficiency fix to jQuery.extend / jQuery.fn.extend (#4246) (#4245, 4ffb1df8)
  • Preserve CSP nonce on scripts with src attribute in DOM manipulation (#4323, 00504037)
  • Preserve CSP nonce on scripts in DOM manipulation (#3541, c7c2855e)
  • Support passing nonce through jQuery.globalEval (#4278, 5bdc85b8)
  • Recognize Shadow DOM in attachment checks (#3504, 9b77def5)
  • Prevent Object.prototype pollution for $.extend( true, … ) (753d591a)

CSS

  • Ensure camel- vs kebab-cased names are not collapsed for CSS vars (f8c1e902)
  • Avoid filling jQuery.cssProps (#3986, 2b5f5d5e)
  • Correctly detect scrollbox support with non-default zoom (#4029, 821bf343)
  • Don’t auto-append “px” to CSS variables (#4064) (#4063, 75b77b48)
  • Skip the px-appending logic for animations of non-element props (f5e36bd8)
  • Avoid forcing a reflow in width/height getters unless necessary (#4322, a0abd15b)
  • Don’t read styles.position in the width/height cssHook unless necessary (#4185, 354f6036)
  • Don’t auto-append “px” to possibly-unitless CSS grid properties (#4007, f997241f)

Dimensions

  • fix computing outerWidth on SVGs (#3964, e743cbd2)
  • avoid fetching boxSizing when setting width/height – this avoids forcing a reflow in some cases (#3991, 73d7e625)
  • fall back to offsetWidth/Height for border-box in IE (#4102, 315199c1)

Event

  • Prevent leverageNative from double-firing focusin (fe5f04de)
  • Add “code” property to Event object (#3978, 899c56f6)
  • Leverage native events for focus/blur/click; propagate additional data (#1741, #3423, #3751, #4139, 669f720e)
  • Respect script nomodule attribute in DOM manipulation (#4281, e4de8b46)
  • Restore _evalUrl jQuery.ajax calls to dataType: script (13de7c9e)
  • Only evaluate HTTP-successful script src (#4126, c2026b11)

Manipulation

  • Properly detect HTML elements with single-character names (#4124, 979809c5)

Misc

  • Add config for lockbot (2348f399)
  • Update license prolog/epilog to placate Github checker (29e76e25)

README

  • add gitter badge to README.md (7869f83d)
  • Add FOSSA license scan status badge (45f08588)

Selector

Serialize

  • jQuery.param: return empty string when given null/undefined (#2633, 0645099e)

Traversing

Internal

  • Seasonal update of uglify and its options (09684ba3)
  • Remove unnecessary ESLint exception (dc05f3c1)
  • Run the basic test suite in jsdom (0ec25abb)
  • Remove manual QUnit fixture resetting (84b6a0be)
  • Make Promises/A+ tests use the dot reporter instead of the default (ca9356ec)
  • Update QUnit from 1.23.1 to 2.9.2 (6ced2639)
  • Run Karma browser tests on Node.js 10 instead of 8 (16ad9889)
  • Update jsdom; migrate a test with Symbol polyfill to an iframe test (9cb124ed)
  • Remove obsolete globals from ESLint configuration (c10945d0)
  • Update most dependencies (8751e9ef)
  • Update test code for compatibility with QUnit 2.x (#4297) (c3498187)
  • Advise to create test cases on JS Bin or CodePen, drop JSFiddle (da44ff39)

Source: jQuery

Bad map file for jQuery 1.9.1 in the jQuery CDN

Quite a while back, Mike Taylor pointed out that the jQuery CDN has a minified copy of jQuery 1.9.1 with an incorrect map file reference. Basically, it refers to the map for jQuery 1.11.1, and that’s just wrong. If you are trying to debug a site that uses the minified jQuery 1.9.1 file, dev tools will get very confused and make a hard job even harder.

You might think that we could just edit the https://code.jquery.com/jquery-1.9.1.min.js file to point to the correct map file, which does exist as https://code.jquery.com/jquery-1.9.1.min.map. There are at least two problems with doing that. The first is that the file is heavily cached across the internet, since it’s been assumed for years that it will never change once the release occurs. Even if we edited the file, both the JavaScript and map file might never actually update at the point where they’re being used.

A second problem is even more serious. We’ve been advocating that developers use the script’s integrity attribute to ensure that the file you are including has not been modified since you originally wrote the script tag. If we modify the contents of the file this attribute will be wrong and the page will no longer include the file. This is likely to completely break the page! Given the age of jQuery 1.9.1 it is possible that many of the pages including this file are not being actively maintained. Thus, we can’t seriously consider changing the JavaScript file in any way, not even one byte.

The least disruptive option is to remove the jquery.min.map file that the jQuery 1.9.1 minified file references. It does not affect whether jQuery runs correctly for the visitors of a site. It only has the effect of disabling the source map. Because of these pitfalls of including the sourceMappingURL map reference in CDN JavaScript files that are often copied elsewhere, we no longer include it.

If you need to debug a site using one of these minified files, it is possible to manually associate a map file in Chrome. Open the minified source file, right click over the area of the minified source, and select “Add source map…”.

The incorrect jquery.min.map file has been removed from the jQuery CDN. We expect that there won’t be any observable change from removing this file, other than restoring sanity to debugging a site that uses jQuery 1.9.1. The jQuery 1.11.1 minified file does not reference its map, so it will continue to work fine and you can associate a map file as mentioned above.

Because caches are so aggressive on CDNs and across the internet, it’s possible that you may still see this map file for a while. If you see some unusual behavior that you think is related to the missing jquery.min.map file you can open a ticket on the CDN issue tracker.

Source: jQuery

4.9.8 Bug Scrub Summary: July 26

This post summarizes the 4.9.8 bug scrub meeting from July 26th (Slack archive).

TL;DR

  1. 4.9.8 RC2 has been released.
  2. We are on target for final 4.9.8 release on Tuesday July 31st as originally scheduled that includes the Try Gutenberg callout, and we have a number of fallback plans should that not happen.

Agenda

  • Identify and discuss any new issues or problems that may have surfaced as a result of testing the 4.9.8 betas and RC1. If no issues occur, we’ll move to a RC2 after the meeting, if yes we’ll work through them during the meeting and then decide next actions.
  • Update on the Try Gutenberg callout / Gutenberg readiness
  • Quick straw emoji poll on moving forward with release next week.

4.8.9 Betas and RC1 Testing

During the meeting several people shared that they conducted significant testing and did not discover any problems.

One person reported that in RC1 the Try Gutenberg callout was not completely dismissable: if a user dismissed it, the next time that user went to the Dashboard the callout appeared again.  This problem had already been identified and a fix for it had already been committed for inclusion in RC2.

Since no other problems were reported, it was decided to go ahead with the release of RC2, which happened right after the bug scrub.

Update on the Try Gutenberg callout / Gutenberg readiness

@danielbachhuber, a member of the Gutenberg team, joined us to give an update on Gutenberg readiness from his perspective.

He shared that the Gutenberg team has been working through a number of issues that have been identified as “Try Gutenberg blockers”, which are defined as:

The issue causes some amount of data transformation that would be non-trivial to recover from at scale (particularly if revisions are disabled).

The most recent list of such blockers is at https://github.com/WordPress/gutenberg/issues/7147 and the Gutenberg team has been working from a Try Callout milestone.

Daniel then reported that

It’s looking likely that we’ll have a Gutenberg v3.4 release at some point in the next few days.

That Gutenberg release will address the blockers referenced above.

He also reported that the Gutenberg team is prepared to quickly release Gutenberg v3.4.1 and v3.4.2, etc, as new problems are reported resulting from the increased usage of Gutenberg because of the callout.

Big props to @danielbachhuber for that update and his input on other questions raised during the scrub!

Quick straw emoji poll on moving forward with release next week

Before the straw poll, there was a discussion of what should happen IF it was decided to punt the callout to 4.9.9: specifically, whether an RC3 that did not contain the callout would be needed and how long that RC3 should be available before releasing 4.9.8 Final without the callout.

There was some support for doing an RC3, to ensure that the revert of the callout was clean.  As to how long RC3, if it were needed, should be out before final was released, two alternatives were suggested:

  1. Have RC3 available for testing for 1 week, which would delay the final release of 4.9.8 by 1 week.
  2. Allow RC3 testing for 1-2 days, which would allow final to be released within the same week as originally scheduled.

No decision was made on those alternatives, but the release co-leads will announce which alternative is most ideal should the need for RC3 arise (see @pento‘s suggestion below).

We then moved on to the following straw poll:

Straw poll: How do you feel about having the Try Gutenberg callout in 4.9.8 release on Tuesday? I’ll add 3 emojis, feel free to vote accordingly on each one. (Please note, this doesn’t denote a decision, just seeing where folks are landing)
👍 👎 ❓

The final result of the poll (as of the writing of this post) was:

13 👍
6 👎
1 ❓

Note: the straw poll is still open and the community is encouraged to cast your votes.

Those voting 👎 were asked to share their reasoning and what it would take to turn their vote into 👍.

The main reasons fell into 2 categories:

  1. Agencies (or others that manage large numbers of sites) not yet being ready to roll out Gutenberg
  2. Hosting companies needing more time to prepare for a Gutenberg rollout

During the ensuing discussion, it was clarified that the inclusion of the callout does not force users, nor agencies nor hosting companies, to roll out Gutenberg with 4.9.8 (which changed a few, but not all, votes to 👍).

While it didn’t come up during the discussion, it should be noted that the changes to the callout between RC1 and RC2 provide a hook to give hosting companies (and agencies) more control over the callout.

Update: discussion after the scrub

After the scrub, @pento shared his thoughts on the topics covered during the scrub (he was unable to join the scrub, a worldwide team definitely lends itself to async communication).

The most important (IMHO) of those thoughts are:

As we’re about to put Gutenberg in front of a lot of sites with existing content, it’s a reasonable assumption that folks will try out the block editor, find that it doesn’t quite work for them yet, and switch back to the classic editor. It’s not a bad thing if this happens, these folks will be able to give us insight into the myriad of WordPress configurations that exist out there, and how they interact with the block editor.

At this stage, Gutenberg will be ready for the current 4.9.8 release schedule. The remaining issues in the Try milestone are either nearing completion, relatively simple (or non-invasive) to implement, or stretch goals. However, it’s good to have a plan for if this changes.

Should something happen to delay clearing the Try milestone, someone from the Gutenberg crew (probably me) will keep the release leads informed on what’s happening, how much time is needed, and what our recommendations are. Again, it would ultimately be up to the release leads to decide their course of action.

In response to a follow-up question, @pento said:

If Gutenberg was not quite ready come Tuesday, I would be inclined to delay a little. We have the option of delaying 1-2 days, or delaying a week: both of those options have merits and drawbacks. My primary concern is that we’ve announced, then pulled, the Try callout twice, I don’t think there’s any benefit (and there’s significant drawback) of doing it a third time.

If we did need to pull the callout, however, I don’t think we’d need an RC3, we didn’t do an extra RC the last two times. The callout is quite self contained, it’s pretty simple to revert.

We really appreciate the work everyone has done to help bring this release together. It’s been a tremendous opportunity to support and help make sure all the pieces can fall into place at the right time. Thanks to everyone who has been helping get this release ready!

#4-9-8

Source: WordPress Development Updates

Registering Metadata in 4.9.8

With WordPress 4.9.8, the register_meta() function supports registration of metadata not only for an entire object type (posts, terms, comments, users), but also for a specific object subtype (such as a specific post type or taxonomy).

Since the enhanced way of metadata registration was introduced in WordPress 4.6 developers could register their meta keys for an entire object type (post, term, commentor user). Post meta is the most popular use-case for register_meta, so most current uses of register_meta specify the object type post. While a given post meta key is often specific to only one post type, meta registration did not account for object subtypes, causing any registered post meta keys that specify "show_in_rest" => true to appear in the REST API responses for any and all post types.

As long as registered meta keys were appropriately prefixed, this produced only a bit of unnecessary metadata being present in some endpoints. However when two meta keys of the same name were registered by different plugins for use with different post types this could introduce conflicts and possible data inaccuracy, as well as potential capability and thus security implications.

In WordPress 4.9.8, meta keys specific to only one or a few post types may now be properly registered without impacting meta keys for unrelated post types. This also applies to term metadata specific to only one or a few taxonomies.

How it works

Two new utility functions have been introduced to register metadata for posts and terms respectively. These functions are now the recommended way to register post and term meta:

  • To register post metadata, use register_post_meta( $post_type, $meta_key, $args ).
  • To register term metadata, use register_term_meta( $taxonomy, $meta_key, $args ).

The first parameter for each new method is the name of the post type or taxonomy for which to register the meta key, and the third parameter works exactly like the third parameter of the existing register_meta() function.

By using these functions, the registered metadata is only associated with the specified post type/taxonomy (also more broadly called the object subtype). Its sanitization and authentication callbacks only affect that object subtype, and the registered key is only exposed in that specific object subtype’s REST API endpoint when show_in_rest is set to true.

Internally these two functions wrap register_meta(), which now supports a new object_subtype argument. register_post_meta and register_term_meta simply provide a more convenient way to specify this new parameter.

Example using register_post_meta():

register_post_meta( 'my_cpt', 'my_key', array(
	'show_in_rest'      =&gt; true,
	'sanitize_callback' =&gt; 'absint',
) );

Achieving exactly the same result using register_meta():

register_meta( 'post', 'my_key', array(
	'object_subtype'    =&gt; 'my_cpt',
	'show_in_rest'      =&gt; true,
	'sanitize_callback' =&gt; 'absint',
) );

It is possible to use register_post_meta() or register_term_meta() to call register_meta() just as before, without an object subtype, by passing an empty string as the first parameter. Going forward this is not recommended, as meta keys should be specific to only the object subtypes that they are needed for.

Backward compatibility

All old code using register_meta() as before will continue to work. However, if you have been using the function with the intention to actually register meta keys for only a certain object subtype, it is recommended to adjust the code accordingly.

The changes have been implemented in a way that meta keys registered for a certain object subtype take precedence over those registered for an entire object type. An example:

  • Let’s say a site has three post types: “post”, “page”, and “attachment”.
  • Someone registers the meta key “my_key” for all posts of all post types, using register_meta() like before.
  • Someone else registers the meta key “my_key” only for the post type “page”, using register_post_meta( 'page', ... ).
  • The result is that for pages the arguments from the second registration are taken into account, while for posts and attachments the arguments from the first registration are taken into account.

What about comments and users?

Comments and users are object types that at this point do not support object subtypes. While there is technically a comment_type field in the comments database table, comment types are not clearly scoped in core (for example there is no register_comment_type()), so it was decided to leave them out for now.

For this reason, there are no register_comment_meta() or register_user_meta() functions at this point.


If you are interested in more about the history of these changes, you can read the initial background post for these efforts, or look into the related ticket #38323.

One last thing: Keep in mind, that, even though meta keys can now be handled per object subtype, it is still recommended to choose specific names that are appropriately prefixed.

Source: WordPress Development Updates