jQuery 1.6.3 RC1 Released

Posted on August 29, 2011 by Dave Methvin

jQuery 1.6.3 is almost ready to roll! We need your help with this release candidate to be sure we’ve got everything right.

Feel free to do your testing by including either one of these files (one minified and one uncompressed). Our preferred venue for test cases is jsFiddle; you can just use the “jQuery (edge)” selection there. If you need to report a bug and cannot use jsFiddle, please use the uncompressed version with your test case.

Please test this release with your most treasured code. If you find any important differences from 1.6.2, please file a bug as soon as possible and be sure to mention that you’re testing against jQuery 1.6.3 RC1.

If you’re making a quantum leap from a much older version of jQuery, it’s possible that the differences you find are due to documented behavior changes introduced in a major-point release. Check your code with the released 1.6.2 version first to be sure the problem only exists in 1.6.3 RC1.

Highlights

Fix an XSS attack vector: User ma.la reported a common pattern that many sites are using to select elements using location.hash that allows someone to inject script into the page. This practice seemed widespread enough that we decided to modify the selector recognition to prevent script injection for the most common case. Any string passed to $() cannot contain HTML tags (and thus no script) if it has a “#” character preceding them. See the ticket linked above for more information and a test case.

No more animation “worm holes”: We had high hopes for the browser’s requestAnimationFrame API when we added support into version 1.6. However, one of the highest-volume complaints we’ve received since then relates to the way requestAnimationFrame acts when a tab is not visible. All the animations initiated when the tab is invisible “stack” and are not executed until the tab is brought back into focus. Then they all animate at warp speed! We’ve removed support for this API (which has no impact on the way you call jQuery’s animation features) and plan to incorporate it into a future version of jQuery.

Better handling of HTML5 data attribute names: The $().data() API serves double-duty, handling data for the internal use of jQuery and plugins in addition to reading initial values of HTML5 data- attributes. We’ve improved the ability to use HTML5 conventions such as converting camel-case to camelCase when needed. Remember, however, that the $().data() API only reads the HTML5 data- attributes initially, and does not keep subsequent data changes in sync with attributes for performance reasons. To update the actual attributes in the HTML markup, use .attr().

jQuery 1.6.3 Change Log

The current change log of the 1.6.3 release:

Ajax

#9255: jQuery.parseXML error handling does not work in webkit browsers
#9854: Pass statusText through instead of “normalizing” it
#9887: jQuery.ajaxSetup may cause unnecessary memory usage
#9970: Typo in ajax.js: status should be jqXHR.status?
#10098: Encode comment-like Accept headers to avoid mobile carrier mangling

Attributes

#9630: foo.contents().hasClass() returns incorrect value
#9699: removeAttr(‘style’) does not consistently remove the style attribute in webkit
#9719: removeAttr(‘disabled’) doesn’t change input’s color on IE6
#9979: .prop(‘tabIndex’) returns inconsistent results for elements that have not yet set tabIndex
#9980: Simplify the attr code by using getAttributeNode for everything in IE6/7

Build

#9988: Minimal License Header in compressed jQuery

Core

#9521: XSS with $(location.hash) and $(#) is needed?
#9897: try-catch isPlainObject detection
#10076: $.inArray crashes IE6 and Chrome if second argument is `null` or `undefined`

CSS

#6652: Remove filter:alpha(opacity=100) after animation
#9572: Support -ms-transform in .css() method
#10021: Can’t add negative numbers using the relative-value syntax with .css() and .animate()

Data

#8235: jQuery.data throws a script error in certain circumstances
#9318: HTML5 data attributes has strange behaviour with if attribute names contain numbers
#9413: $.fn.removeData does not remove data with a dash in a name
#9779: Allow non-null|undefined evaluation of data property values
#9794: jQuery.fn.data() correctly handle access to arbitrary data property values
#10016: Cannot retrieve “false-y” values under key names with dashes using jQuery.data method
#10080: unload from frame’s window breaks in IE8

Dimensions

#10123: .width() can return a float in Firefox 6

Effects

#9381: Animations halt when the browser is out of focus due to requestAnimationFrame
#9678: setInterval cleared by animation

Event

#7071: Accessing the ‘type’ property on VML elements fails on IE during submit special handler

Manipulation

#9587: Cloning a div with an object causes error in IE8

Support

#9634: Visible “t” character in upper left corner during support.js init
#9823: IE 8 crashes when using background-image on BODY in css
#9964: test/support.js module strictEqual typo
#10029: $.support.scriptEval removed, but still included in documentation

Please do file a bug report with a test case as soon as possible if you find problems, as described above. Blog comments or Twitter aren’t helpful bug reports!

7 thoughts on “jQuery 1.6.3 RC1 Released”

Manuel Ricci on August 29, 2011 at 1:53 pm said:

I had tested the release with my works and all is perfect. but in this is simple script:

$(‘document’).ready(function(){
$(‘.ani’).animate({padding: ’20px’, borderBottom: ‘3px solid #8f8f8f’,borderRight: ‘3px solid #bfbfbf’},2000);
});

the class is animated only with padding but the border don’t appear.
Blaise Kal on August 29, 2011 at 2:33 pm said:

I had that womhole thing in Chrome in an image carousel. Went completely berserk after you left and then later returned to your tab and I just couldn’t figure out what caused it!

I even added some code that paused the carousel on window blur and resumed after focus. I’m very glad I read this post so can I can remove that code :)
Salman Abbas on August 29, 2011 at 8:00 pm said:

@Blaise even though the documentation page for jQuery.animate clearly mentions that:-
“Because of the nature of requestAnimationFrame(), you should never queue animations using a setInterval or setTimeout loop. In order to preserve CPU resources, browsers that support requestAnimationFrame will not update animations when the window/tab is not displayed. If you continue to queue animations via setInterval or setTimeout while animation is paused, all of the queued animations will begin playing when the window/tab regains focus. To avoid this potential problem, use the callback of your last animation in the loop, or append a function to the elements .queue() to set the timeout to start the next animation.”

Removed such an excellent feature because of some newbies. c’mon :(
Ron Otten on August 30, 2011 at 2:04 am said:

Agree with Salman.

Feature shouldn’t have been removed because of beginning developers mis-using it. Would’ve been far better to just have an opt-in switch. That way everything would keep working for the lesser skilled developer relying on busted image carousels and the like, while the more informed developer can flip the switch and use the better API (if available) for smoother animations, less resource consumption, etc.

So… how feasible would it be to write a monkey patch to force the requestAnimationFrame behaviour back into 1.6.3 as a ‘plugin’?
Theodor on August 30, 2011 at 2:55 am said:

Thanks for fixing #6652. Now i can remove the monkey patch from all the projects :)
shawn on August 30, 2011 at 5:54 pm said:

Would it be possible to use the page visibility api to check for document.hidden in jQuery.animate to avoid the requestAnimationFrame issue?
Blaise Kal on September 2, 2011 at 4:59 am said:

@Salman Abbas “even though the documentation page for jQuery.animate clearly mentions that:”

When I use a new jQuery version, I don’t read the documentation again.

I do read the blog post when a new version of jQuery is released and check what has changed and if it affects me. The release where requestAnimationFrame talked about smoother animations. I thought “good, nice, thanks”. The blog post should’ve come with a big warning, but I guess the developers didn’t foresee this issue.

Sure, queue() would’ve been the jQuery way of queueing animations and it would’ve prevented the issue from occurring, but everyone uses jQuery in a different way, for different things, and it should never be assumed otherwise. setInterval is a perfectly fine way of doing intervals. Just not with requestAnimationFrame.

Official jQuery Blog