jQuery 1.11.2 and 2.1.3 Released – Safari Fail-Safe Edition

Posted on by

Season’s greetings! After a thoughtful review of the Naughty and Nice lists, we have decided to leave a small present under the tree to finish 2014: jQuery 1.11.2 and 2.1.3! These releases include several bug fixes to make your cross-browser development experience better.

The most significant fix in this release is a workaround for a serious querySelector bug in Safari 8.0 and 7.1. When this bug popped up we were hopeful that it would be fixed in patch releases but that did not happen. Apple is by far the least transparent browser maker, and we have very little information about when the Webkit patch for this bug might be pulled into Safari. As a result, we have decided to patch this in Sizzle, the selector engine used by jQuery.

A bug like this one emphasizes the benefit of using a library like jQuery rather than going directly to the DOM APIs. Even modern browsers can suffer from bugs that aren’t fixed for a long time, and there are still cross-browser feature differences with several browsers in wide use such as Android 2.3. Special-case code for obscure browser issues can seem unnecessary until you spend a day trying to debug a problem in your own code caused by one. Or worse, lose a paying customer because they couldn’t use your site from their old phone.

Another bug that makes it difficult for us to test jQuery on iOS 8 is that the user agent of the simulator is incorrect so the iOS 8 simulator is not recognized by our unit test infrastructure. The fix for that issue is very simple but Apple won’t tell us if we can count on it being done. For now we’re doing our iOS 8 testing manually.

In addition, this release includes several changes inside jQuery to avoid holding onto DOM elements unnecessarily. Although the old code generally wouldn’t cause things to run incorrectly, web pages might run slowly and use more memory than necessary.

You may notice that we skipped a patch release number in the 2.x branch. We didn’t actually skip it, we built it and found a problem that caused problems when jQuery was used with node. (Many thanks to Denis Sokolov for letting us know immediately and prodding us to fix it!) Rather than shipping those files to the other CDNs, we decided to create new releases.

As far as the potential for compatibility or regression issues, we believe this is a very low-risk upgrade for anyone currently using 1.11.1 or 2.1.1. We are making this release ahead of jQuery 3.0 to ensure that you can use a Safari-safe version of jQuery without the need to review your code for compatibility with changes being anticipated in jQuery 3.0. If you do encounter bugs, in upgrading from the previous version, please let us know.

You can include these files directly from the jQuery CDN if you like, or copy them to your own local server. The 1.x branch includes support for IE 6/7/8 and the 2.x branch does not.



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 and don’t be impatient. If you’re anxious to get a quick start, just use the files on our CDN until they have a chance to update.

Many thanks to all of you who participated in this release by testing, reporting bugs, or submitting patches, including Chris Antaki, Denis Sokolov, Jason Bedard, Julian Aubourg, Liang Peng, Michał Gołębiowski, Oleg Gaidarenko, PashaG, Richard Gibson, Rodrigo Rosenfeld Rosas, Timmy Willison, and TJ VanToll.

Since the last release of jQuery we have moved from a Trac installation to GitHub issues, so there are currently tickets for this release in both bug trackers. References to the Trac tickets have been migrated to GitHub issues, however, so you can use this GitHub Issues query to review all the tickets.

Thanks for all your support, and see you at jQuery 3.0!

Improving the Pointer Events Polyfill

Posted on by

Today, we’re excited to announce that Google has transferred its Pointer Events polyfill to the jQuery Foundation. This polyfill was originally written by Google’s Polymer team but since Google has chosen to put their Pointer Event implementation on hold, we engaged to ensure that the polyfill is maintained and continues to be a tool developers can use as a path to the eventual native implementation in all browsers. Many thanks to Google and the Polymer Team for allowing us to build off their work and continue development.

The jQuery Foundation has been, and continues to be a strong proponent of standards and we are specifically strong proponents of the Pointer Events standard because it will simplify the way web developers handle user interactions. Today developers are saddled with two very different event models for mouse and touch, even though they share many similarities. The result is often code that has a myriad of special cases, particularly when the device itself generates “fake” mouse events from touches. The jQuery Foundation hopes to drive developer adoption of this unified event system. Our goal is to have all browsers implement this standard natively.

Just yesterday, the W3C took the Pointer Events specification to the Proposed Recommendation stage. This makes Pointer Events one step closer to a finished standard and gives browsers a solid base on which to implement these APIs. Some browsers have even begun their implementation. Unsurprisingly Internet Explorer, where the first implementation of Pointer Events began before being submitted to the W3C for standardization, has implemented Pointer Events and Firefox has a branch of their code base implementing Pointer Events which they intend to port to all version of Firefox. Both of these implementations recently passed 100% of the Pointer Events test suite so implementation is progressing nicely.

We want to thank Microsoft Open Technologies for their hard work on Pointer Events and their continued support. We also want to thank IBM, Mozilla, Google, Dojo and the many other organizations and individuals that have helped and continue to help make developers lives easier through the creation, fostering and promotion of new standards like Pointer Events. If you want to get involved or just want to start using Pointer Events in your projects, head over to the new Pointer Events repo and check it out.

QUnit 1.16 Release and Roadmap

Posted on by

We’ve just released QUnit 1.16, an important milestone for the project. This release introduces several new APIs that will become the default in QUnit 2.0. To help migrate to these APIs, you can start using them today in 1.16. Our 2.x upgrade guide provides all the details you need to change your existing test suite to the new APIs.

Here’s a quick overview of the new APIs:

QUnit.test( "assert.async() test", function( assert ) {
  var done = assert.async();
  var input = $( "#test-input" ).focus();
  setTimeout(function() {
    assert.equal( document.activeElement, input[0], "Input was focused" );

You still define tests by calling QUnit.test and passing a name and a callback. The callback receives a assert argument that contains all assertion methods. The assert.async() method is brand new, replacing the old stop() method. The returned callback, here named done is later called when the test is finished, replacing the old start() method.

In addition, QUnit 1.16 contains several improvements and new features:

  • Promise support: As an enhancement for the async control, test blocks are now Promise aware, meaning QUnit will wait for the test to resolve with the pass or fail statement.
  • QUnit asynchronous tests can also now be defined using the new var done = assert.async() method instead of the old stop()/start(), making them specific to the test block.
  • QUnit.skip: This method can be used to define tests that aren’t executed, as placeholders or to temporarily disable an existing test (instead of commenting it out). The skipped test is still displayed in the HTML reporter, marked prominently as “SKIPPED”.
  • testId URL parameter: When clicking the “Rerun” link for a single test, a hash of the test name is now used to reference the test, called testId, instead of the previous testNumber. Using a hash makes sure that the order of tests can change, and QUnit will still rerun the same test you’ve selected before.
  • CommonJS exports: QUnit now also looks for a exports object and uses that to export itself, making QUnit usable on Rhino with the -require option.
  • There are a few more minor changes. For a full list, check out the changelog.


For future releases, we have several improvements planned as well:

Standardized reporter interface

Currently integration of any unit testing library into other tools like PhantomJS or browserstack-runner or Karma requires custom integration code, a combination of library and tools. We’ve started an effort to create a standard reporter interface that all testing libraries could implement, called js-reporters, to be consumed by those tools. Coordinating between the various projects and getting them to agree on and implement a common API takes time, but will yield better testing infrastructure for everyone.

Better diff output

When writing unit tests that compare objects with deep structures or many properties, like Ember models or Moment instances, the current diff output is slow and inefficient. There are also comparisons where the diff is hard to read. Replacing the diff library and implementing custom optimizations, like only showing diffs for leafs in big objects, will make QUnit’s HTML reporter even more developer friendly. We have a list of all diff-related issues.

Better support for writing custom assertions

Custom assertions are a powerful method of abstraction in test suites. They are currently underused. We want to investigate better APIs for writing custom assertions, along with better documentation of existing and new APIs.

Support for nested modules

Nesting modules, like Jasmine and Mocha support it, gives more flexibility in structuring test suites. There is existing discussion and prototypes, but no consensus on the API, yet.

For any breaking changes, we’ll apply the same migration model that we’re currently using. All backwards compatible changes will make it into the next minor release, any incompatible changes will be introduced with a migration layer in a minor release, removing the migration layer in the next major release.

The QUnit Team

The QUnit team also would like to use this opportunity to introduce itself:

At the jQuery Conference in Chicago, September 2014, from left to right: Jörn Zaefferer, Timo “Krinkle” Tijhof, James M. Greene, and Leonardo Balter