jQuery 1.10.2 and 2.0.3 Released

Posted on by

It’s nearly Independence Day here in the USA, so we’re delivering something fresh off the grill: jQuery 1.10.2 and 2.0.3. These releases fix a few pesky bugs that have been reported over the past month, but the list is refreshingly small. Since some of the bugs spanned both the 1.x and 2.x branches we’re releasing new versions of both to keep them in sync.

You can get the latest files from the jQuery download page, including sourcemap files and links to helpful tools such as jQuery Migrate. If you’re upgrading from a version of jQuery before 1.9, please do read through that page carefully to make your migration as pain-free as possible. Remember that it may take a few days for the CDNs at Google, Microsoft, and CDNJS to respond to the rocket’s red glare and post the latest versions. In the meantime, use the copy on the jQuery CDN.

We’re pretty optimistic that these latest bug-fix releases should be free of surprises. If you drop the new files into your site and see fireworks, please do your patriotic duty and report a bug with a test case (preferably using jsFiddle) at our bug tracker.

These releases wouldn’t have happened without the contributions of Jason Bedard, Jason Merino, Jörn Zaefferer, Michał Gołębiowski, Nguyen Phuc Lam, Oleg Gaidarenko, Richard Gibson, Rick Waldron, Terry Jones, and Timmy Willison.

jQuery 1.10.2 and 2.0.3 Changelog (common to both)




jQuery 2.0.3 Changelog (specific to 2.x)



19 thoughts on “jQuery 1.10.2 and 2.0.3 Released

  1. Bagus on said:

    Always brilliant. Great job jQuery team!
    Thank you for presenting us jQuery, it really faster our development

  2. I’m impressed that you guys are always working tirelessly to provide solid support for even the most esoteric minutiae like this flexbox order property. Thank you.

  3. If you’re upgrading from a version of jQuery before 1.9,
    the jQuery Migrate plugin simplify the transition from older versions of jQuery

  4. Martijn on said:

    Waiting until the jQuery team sees the light and renames jQuery 2.0 to “2.0-lite” and jQuery 1.10 to “2.0”.

  5. quiz on said:

    Quick Access section at the bottom of page is still pointed to 1.10.1 version (and doesn’t contain 2.x version at all)

  6. Kevin on said:

    What version of the jquery UI is certified to work with 1.10.2 as the modal popup (dialog) in jquery-ui-1.10.3.jsjquery-ui-1.10.3.js is not working well with jquery-1.10.2.js.


  7. Version of the jquery UI 1.10.3. Index.html from zip. Drag for dialog in IE8,9 not work properly.

  8. You are doing a great jog! This version fixed a serious bug in the animate() function. I spent about 3 days trying to discover why when calling animate() more than once they were not chaining, they were executing together. This version fixed this. COOL!

  9. We have just integrated jQuery 2.0.3 hosted by Google. I just like to thank you for jQuery::mouveleave() method that accomplishes functions that DomElement.mouseout() cannot if the element is in autosize mode, such as a div used for a popup menu.

    You are very cool guys jQuery team.

  10. Christian Z. on said:

    Still a bad idea to have $.browser removed, especially now with the advent of IE10 (see: http://stackoverflow.com/questions/9900311/how-do-i-target-only-internet-explorer-10-for-certain-situations-like-internet-e). It is still my contention that $.browser covers rare cases that cannot be covered by feature detection (and, yes, I understand the benefits of and reasoning behind feature detection and use it when it is the tool to use; I’m not ignorant of it nor arguing against it). And although needs for browser detects over feature detects are rare (thankfully) they do manifest themselves enough to warrant the inclusion and re-insertion of $.browser.

    See also: http://blog.jquery.com/2013/02/16/jquery-migrate-1-1-1-released/comment-page-1/#comment-540373

  11. Actually, IE11 is a perfect example of why $.browser was removed. The reason Microsoft is removing the “MSIE” token is because it is used by broken software that expects something like IE7 or IE8 but then misbehaves on IE9. Asking “is this any version of IE” is the wrong question for any software to ask if it is trying to determine features. If you have a use case you feel is valid, feel free to examine navigator.userAgent directly and deal with the consequences.

  12. Christian Z. on said:

    “Asking ‘is this any version of IE’ is the wrong question for any software to ask if it is trying to determine features.”

    I know that *extremely* and *acutely* well and find it rather disheartening that a group of people who should be smarter keep thinking I am saying, “I want $.browser kept around so that I can feature detect” when I’ve succinctly stated that’s NOT what I’m talking about.

    I explained on a prior thread that I (and others) have run into cases where “feature detecting” doesn’t cut it (although I 100% agree it should be used when it’s the proper tool), where you really do have to check for what browser is being used. An example was a recent project I was on where Safari and Chrome were handling a particular issue differently (meaning that using a “-webkit” prefix wasn’t going to help; I really DID need to target Chrome only… and no other browser). That’s just one example. Yes, these are edge cases but when jQuery refuses to cover them jQuery might as well say, “We are becoming less capable and necessary over time. We can’t do that anymore. Use regular JavaScript for that.”

    But I guess you can continue to make jQuery irrelevant until everyone just goes back to regular JavaScript again. There’s already articles being written about how jQuery should be jettisoned.

    My original comment is here: http://blog.jquery.com/2013/02/04/jquery-1-9-1-released/comment-page-1/#comment-536442