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










46 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. “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. where to download jquery without excludable modules?

    why not make “browser” an “excludable module” so people that needs it download it with custom jquery

  17. 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… :)

  18. 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.

  19. 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.

  20. 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!!!

  21. 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.

  22. “$.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?

  23. 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”!

  24. 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”);

  25. ethan on said:


    function uncheck(){
    function select2(){

    interative click.it will wrong!!!use 1.8.3 version is true.this is a bug…

  26. @ethan, the jQuery 1.9 Upgrade Guide addresses that very case. The jQuery Migrate plugin warns about it. Did you read the guide or use the plugin? If not, why?

  27. 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.)

  28. 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!

  29. 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.

  30. Detecting a browser and adapting to it’s capatiblities should be provided via something like $.browser or inspection of ua. If developers are to use the capabilities that only jquery thinks of or supports, then we won’t be able to develop easily beyond those. Even browsers with capabilities on occasion you don’t want to use them because of the platform – or due to the lack of processing power on a particular platform. To try impose restrictions because bad practice ‘views’ isn’t itself good practice. Let good developers code well and bad developers code bad and learn over time.

  31. Kathy J. Lowrey on said:

    Great Update.

    I wonder when jQuery will provide us functionality to download specific widget i.e ajax, selector…. like Modernizr

  32. Johar on said:

    The method “toggle” in 1.9.1 version don’t work. It collapsed element. The older version hasn’t this bug.

  33. mahuang on said:

    When I use jquery coolfieldset plugin and import jquery-1.9.1.js, it seems there are conflict between them which collapse don’t work, as a result coolfieldset does not work.

  34. Christopher Florencia on said:

    Hello guys, tks gor your code, could you release 1.9.2?, I noticed it’s completed and I really need that version due the error in chrome


  35. Hello,

    i am tring to run javascript code and that is correct.. but it shows error because another file has error which is included in same page.. how to avoid that,,


  36. TimV on said:

    There is a VERY valid reason to be able to tell what browser is hitting your webpage!! Microsoft has announced that because they have lost so much market share in the browser world, it is unfair that Webkit gets all the cool websites, so they are going to add the -webkit- prefix to their Triton engine for CSS rendering!

    We are going back to Browser Hell all over again (for those old enough to remember.) And MS also removed conditional comments for the same reason. In their egotism of thinking their code is perfect, MS fails to see that their bugs are now an order of magnitude more difficult for developers to work around, since we cannot see that it is the crappy Triton engine on our page, and thus we cannot shim a fix for their bad code!

    Doesn’t anyone see this? None of the “big boys” seem to care on any blogs or extension websites like this one. :(

  37. saurus on said:

    Hello guys, and with no regrets at all, i plan to long-term squeeze and remove jquery’s fame.

    Some people have very different approaches of what web should do.
    Once they have a great community behind, they spit on them all forcing their narrowest vision of JS’ future, just to copy adobe, apple and other’s state of mind, not even fearing telling them all if they’re stupid enough to have followed and used their project, now the’re good to start again, and loose huge amount of time, which is the opposite of the project’s base goal.

    Thank you again, to be first-class usurpators,
    – copying Shiny Classy Fancy new patterns (Promise, which Node itself don’t ensure the livibility) which real JS scripters already know how to handle properly,
    – thinking browserify is the only node front implemetation, and messing with module exports, beeing too browserify-specific for no reason,
    – or even showing how proper and aware they are, in mobile frameworks that just are unusable in terms of how much div imbrications and events are, trying again to pretend solving everything and pulling coders to the bottom.
    And then slap them in the face because they think condescendantly towards their comminuty of users.

    Just know some are planning your definitive deprecation…. ironic?

  38. Kumar RM on said:


    1.9.0 and the above version For check box check / un check is not been reflecting properly in the UI.
    its working on 1.8.3.

    Above the version none of the version is not working.

    Note for the team to fix the same in all the version above the 1.8.3