## Official jQuery Blog

# jQuery 1.9.1 Released

Posted on February 4, 2013 by dmethvin

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

## Ajax

- #13276: In IE 9/10 $.parseXML() returning document object instead of XMLDOMDocument
- #13292: $.ajax with 1.9.0 doesn’t call anymore success function in case of 204
- #13306: File input added to serialized forms caused a change in behavior and only halfway follows spec

## Build

- #12656: Make event shorthands an excludable module
- #13274: IE < 9: “‘jquery’ is undefined” w/ sourceMappingURL comment
- #13316: Check against jquery.min.js with TestSwarm
- #13335: “use strict”; break asp.net ajax postacks in FF

## Deferred

- #13150: Be able to determine if $.Callback() has functions

## Effects

- #12846: overflow:hidden is not removed when .stop() is called
- #13183: Wrong animation initial value calculation (1.9.0rc1)

## Event

- #13208: JS error trying to get the id of the document in IE8
- #13360: Creating String.prototype.namespace can cause an exception in jQuery.Event

## Manipulation

- #13282: QtWebKit — TypeError: ‘[object Object]‘ is not a valid argument for ‘Function.prototype.apply’ (evaluating ‘elem.nodeType’)
- #13315: minified manipulation methods fail on oldIE with XML
- #13233: Unexpected behavior when iterating over and manipulating detached nodes in jquery 1.9

## Selector

- #13182: nested has selectors broken in IE7 & IE8 in versions 1.8.2+
- #13281: Wrong order when using .find() in IE7/8
- #13331: jQuery.fn.add returns incorrect order in Chrome and Safari

## Support

- #13089: support adds zoom style to body in Chrome/Safari

## Traversing

- #13349: find function slower since 1.9.0, especially in chrome

## 31 thoughts on “jQuery 1.9.1 Released”

1. mitchell zhu on February 5, 2013 at 1:32 am 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. Skoua on February 5, 2013 at 6:01 am said:

   Thanks!

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

3. River on February 5, 2013 at 6:54 am said:

   $.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. Adeel on February 5, 2013 at 7:05 am said:

   I’ve extracted the $.browser code into a separate file in case someone else needs it:
   https://gist.github.com/adeelejaz/4714079

5. Lee on February 5, 2013 at 7:37 am said:

   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));
   }

6. Stifu on February 5, 2013 at 8:04 am said:

   @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”.

7. Anahkiasen on February 5, 2013 at 9:07 am said:

   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.

8. noname on February 5, 2013 at 9:08 am said:

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

9. Christian on February 5, 2013 at 3:24 pm said:

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

10. Johannes on February 5, 2013 at 3:51 pm said:

    @Christian, See the link Adeel provided above.

11. Christian on February 5, 2013 at 7:10 pm said:

    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.

12. galin on February 6, 2013 at 3:09 am said:

    $.browser is still needed for some cases.
    so reinclude it in future versions of jQuery.

13. Martijn on February 6, 2013 at 4:25 am 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.

14. Stifu on February 6, 2013 at 8:25 am said:

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

15. dmethvin on February 6, 2013 at 8:27 am said:

    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.

16. honeyryderchuck on February 6, 2013 at 10:55 am 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.

17. Jason Crow on February 6, 2013 at 12:59 pm said:

    Some code for those asking for $.browser, hope it helps..

    http://greatwebguy.com/jquery-2/browser-detection-shim-for-jquery-1-9/

18. Christian on February 6, 2013 at 3:14 pm 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.”

19. SeaGull on February 7, 2013 at 10:42 pm said:

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

20. dan on February 8, 2013 at 4:53 am said:

    where to download jquery without excludable modules?

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

21. Rodrigo Rosenfeld Rosas on February 8, 2013 at 7:03 am said:

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

22. Joshua Tenner on February 8, 2013 at 8:33 am said:

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

    I needed an excuse to learn how to use modernizr.

23. aikeru on February 9, 2013 at 2:12 pm 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.

24. jeff on February 11, 2013 at 8:55 am said:

    it is not on googles CDN yet. any reason for that?

25. Longjie Xu on February 11, 2013 at 10:04 am said:

    Yeah, zoom:1 is not necessary for some webkit browsers. Thanks for the fine tune.

26. KOnnark on February 11, 2013 at 10:45 am said:

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

27. FeedFixer on February 13, 2013 at 6:11 am 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.

28. qlwik on February 14, 2013 at 8:12 am said:

    Thanks for update, think again about adding $.browser :P

29. Peter Mouland on February 17, 2013 at 8:49 am said:

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

30. thedavidmeister on February 18, 2013 at 6:13 pm 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”!

31. Christian on February 20, 2013 at 9:37 pm said:

    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”);
    }
    }

### Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Name *

Email *

Website

Comment

You may use these HTML tags and attributes: `<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>`