jQuery 1.9.1 Released

Posted on by

The jQuery team is pleased to announced that jQuery 1.9.1 is available! This release addresses the bugs and regressions that have been reported during the past few weeks. Whether you’re using 1.9.0 or using an older version, these are the droids you’re looking for.

Please, please, please, use the jQuery Migrate plugin and look at the upgrade guide if you’re just starting your upgrade to jQuery 1.9. The plugin will quickly find and fix any compatibility issues, just look in the browser console. Once you fix the warnings you can remove it. Or, leave the plugin in place until you have the chance to fix your code and plugins to make them 1.9-compatible.

<script src="http://code.jquery.com/jquery-1.9.1.js"></script>
<script src="http://code.jquery.com/jquery-migrate-1.1.0.js"></script>

We’ve sent the files to the Google and Microsoft folks, so you should see them up on their CDNs shortly.

Many thanks to those of you who reported bugs, and to the following people who contributed patches to the 1.9.1 release: Adam Coulombe, Andrew Plummer, Corey Frang, Danil Somsikov, Jean Boussier, Julian Aubourg, Mike Sherov, Oleg Gaidarenko, Richard Gibson, Ryunosuke Sato, and Timmy Willison.

Gold-leaf-cluster thanks to Paul Irish, who mobilized special forces to find a solution for 13274!

Change Log










31 thoughts on “jQuery 1.9.1 Released

  1. mitchell zhu on said:

    i don’t need migrate plugin and i just need $.browser,because many many plugin use $.browser
    please please please support $.browser~~~~just $.browser~~ thank you

  2. Thanks!

    I must agree with mitchell that a separate file to support $.browser only which is used by some plugins would be great.

  3. $.browser is a bad practice jQuery moved away from. Plugin authors should switch to more reliable feature detection instead of relying on browser sniffs.

    I’m sure someone will throw $.browser into a plugin, but you should probably avoid it for future code, almost everything can be feature tested. http://modernizr.com

  4. Please please please add $.browser back, not only is it used to detect features (which can be replaced by moderniser or $.support), it’s also used in some cases where people only need to know browser version.

    For example:
    if ($.browser.msie) {
    $(”).html(‘Out website does not support Internet Explorer, please use Chrome instead.’).appendTo($(document.body));

  5. @Lee: your example still sounds like something that could be replaced with feature sniffing. Your website does not support IE because IE does not support certain things, right? So your logic should be “browser needs features A, B and C”, not “browser should not be this particular browser brand”.

  6. As mentioned above, you people should try something like Modernizr and detect actual features instead of plain blocking (which is bad and you should feel bad) of specific browsers.

  7. noname on said:

    @Adeel: thanks! I just needed the $.browser to know which effin’ browser and version was visiting my website :)

  8. “$.browser is a bad practice jQuery moved away from. Plugin authors should switch to more reliable feature detection instead of relying on browser sniffs.”

    I’ve explained elsewhere that feature detection does NOT always cut it. On a project I am working on now I need “$.browser” to handle a Firefox bug that cannot be sussed out with feature detection. See http://stackoverflow.com/questions/14105890/jhtmlarea-adding-unwanted-br-tag for some info on just one such problem. Once I figured out this was a Firefox-only problem I had to use “$.browser” to account for the unwanted BR tag in Firefox only.

    It is rare, fine-grained instances like this where “$.browser” is still needed. In saying this I am not recommending that “$.browser” be used to “sniff” for a certain browser at the beginning of page load and then serve totally separate large chunks of JavaScript/jQuery to different browsers as back in the old days of browser sniffing (“Here’s one enormous set of JavaScript for Internet Explorer and one for Netscape.”).

    Please consider re-including “$.browser.” Hopefully people can grasp what I’m saying here rather than tuning out what I’ve said and thinking that I and others are trying to “block” certain browsers or some other such bad scenario.

  9. I saw it. I am giving a reason for its inclusion in jQuery itself, emphasizing that this feature is something other than just a poor replacement for feature detecting.

  10. Martijn on said:

    Personally I don’t see the point in saving <1KB (minified) in a 91KB framework (the 33KB specified is false; just checked it) by removing features that are going to cause backward compatibility issues.

  11. @Martijn: it’s not just about size, but also maintenance (among other likes, like consistency, best practices, etc). Keeping old features is not “free”. If the jQuery team wants to reorganize or rethink their code (and they keep doing it), then having fewer things to worry about speeds things up.

  12. And as always, you are welcome to put browser detection back via jQuery Migrate, using the older version, the gist from Adeel above, checking navigator.userAgent directly, etc.

  13. honeyryderchuck on said:

    ahaha, very funny to see all the rollover over $.browser not being supported. I don’t understand all the fuss because: it’s an extensible framework, so you can just rewrite, overwrite or move features to subplugins (and use Adele’s link); jQuery is quite old in internet years and quite fat, does some things very well, some things so-so and some things which other frameworks are better at (like the already cited Modernizr), so it’s actually a wise decision to lose that fat; if you are using plugins relying on $.browser, then it probably means you are using the wrong plugin for the job developed by someone who’s either not developing it actively anymore, doesn’t pay attention to deprecation warnings or doesn’t update himself on framework changes.

    jQuery handles the document and provides a very simple API for XHR requests; it is not very good at browser sniffing and browser feature detection, or for basic element feature enhancing (underscore.js). jQuery needs to be trimmed because it’s not 2007 anymore and there are other libraries that are accomplishing many tasks jQuery doesn’t need to.

  14. Christian on said:

    “if you are using plugins relying on $.browser, then it probably means you are using the wrong plugin for the job developed by someone who’s either not developing it actively anymore, doesn’t pay attention to deprecation warnings or doesn’t update himself on framework changes.”

    But it doesn’t necessarily mean that. My reason for mentioning that they should still include it is based on theirs and others’ false belief that $.browser is 100% equal to “feature detecting.”

  15. SeaGull on said:

    Please, return $.browser back.
    It’s the only part of “jquery-migrate” all my projects need.

  16. I’d guess most people here complaining about $.browser being removed would be happy with just booleans like $.IE, $.IE6, $.IE7, $.IE8, $.IE9 :D Or simply $.IE(version) where all versions would return true if version is not passed in… :)

  17. Joshua Tenner on said:

    Thanks for the updates! I won’t complain about the $.browser removal.

    I needed an excuse to learn how to use modernizr.

  18. aikeru on said:

    Thank you for continuing to trim the fat on this awesome JavaScript library! Please don’t add ‘browser’ back. There are many options to get it back and it IS a poor way to do what most people use it for. I HATE it when a website “doesn’t support my browser” when my browser may work just fine.

  19. Why it’s not available on Google CDN?

    I don’t understand the jQuery’s homepage: at the top there is “Download jQuery 1.9.1” and at the bottom you see “Download jQuery 1.9.0″…
    If they can’t even be consistent/coherent on their own homepage, I can’t imagine what it actually is in the jQuery lib itself!!!

  20. FeedFixer on said:

    FYI The RSS feed for the jQuery blog appears to be broken. It just loads the blog default page rather than an RSS/XML file.

  21. “$.browser”

    Some versions of chrome that have the transitionend event it is unreliably implemented i.e. it didn’t always fire after the css transition had finished.

    With so many new features making their way into browsers (along with a couple of bugs) like the above example, i am not sure how you would feature detect this inadequacies.

    To detect the bug found by @Christian might also be similar and unreliable or will involve triggering events and possibly replicating human behaviour to find the bug. Is this overkill (and hit website performance) if the browser and version number are known?

  22. thedavidmeister on said:

    Please put $.browser back in. Regardless of whether it’s “bad practise” to use it or not as an end user, API breaks across minor versions of a library is far worse “bad practise”!

  23. I *just* had to include the following in the same project I mentioned above):

    if ($.browser.mozilla) {
    $(‘.jHtmlArea IFRAME’).attr(‘onload’, ‘this.contentWindow.focus()’);

    This was because an element was not getting focus in Firefox on page load when it was in other browsers. I don’t know a way to feature detect for whether or not a form element will get focus in every browser except Firefox. But even if there is a way the point here is that I am not doing a “browser sniff” before any other JavaScript is loaded and then serving a couple thousand unique lines of JavaScript/jQuery to Firefox and not to other browsers and then serving different sets of unique code to those other browsers. I am doing a “browser detect” and serving *one line* of reparative code to Firefox. This is one example of the need to retain “$.browser.” Additionally, the plugin this line of code relates to has to itself detect if the browser is IE or Safari (note: *not* “webkit”) and do the following quick maneuvers:

    increaseFontSize: function () {
    if ($.browser.msie) {
    this.ec(“fontSize”, false, this.qc(“fontSize”) + 1);
    } else if ($.browser.safari) {
    this.getRange().surroundContents($(this.iframe[0].contentWindow.document.createElement(“span”)).css(“font-size”, “larger”)[0]);
    } else {
    this.ec(“increaseFontSize”, false, “big”);

  24. Ilia on said:

    I have no problem with removal of $.browser but the reality is that browser sniffing is sometimes necessary. This is especially true for mobile development where feature detection is often just not enough. (check out Smashing Mag’s The Mobile Book if you don’t believe me.)

    In any case, for those needing $.browser functionality check out http://conditionizr.com/
    Conditionizr works like Modernizr but for browser detection, and even more. It will also detect retina-like displays, touch events and even OS version. On top of that it has built in (but optional) functionality of loading scripts (e.g. html5 shim) or CSS (e.g. ie7.css) based on what you detected. So it’s really like a better version of $.browser plugin. (Note, I’m in no way associated with Conditionizr, I just started using it recently and find it extremely helpful.)

  25. Douglas on said:

    i can’t tell you how impressed i am with the work you guyz have done for the community! It takes a lot to write something so robust and yet give it away for free! Hands down you guys are the best may God bless you more!

  26. Nat Darke on said:

    @ people complaining about $.browser being removed. There is a version of jQuery available that supports all your needs. It is called jQuery 1.8. You will love it. Or write your own library and give it away for free….oh, I thought not.