Odd handling of 'onreadystatechange' event in jqXHR when readyState > 1

[anonymous]

The doc at  http://api.jquery.com/jQuery.ajaxPrefilter/ notes that prefilters give access to the jqXHR object (through which the native XHR should be accessible), but it seems like handlers attached to the XHR's onreadystatechange event act unexpectedly when readyState is > 1. http://bugs.jquery.com/ticket/8327 notes a jsfiddle providing a workaround to access some properties of the native XHR before readyState == 4, but the proposed solution seems inefficient: updates to the XHR's responseText are detected by polling that attribute every millisecond.

Instead, I think it would be better to simply add an event handler to the onreadystatechange event, and detect when readyState==3. I've tried doing that at  http://jsfiddle.net/Rdx6f/, but the onreadystatechange event seems to only fire when readyState==1. (I'm using Firefox 4.0.1.) Oddly, when I alert the readyState upon onreadystatechange, things behave differently:  http://jsfiddle.net/Rdx6f/1/.

A native JavaScript implementation of onreadystatechange tracking works as expected ( http://jsfiddle.net/d7vaH/), making me think this is not a problem in Firefox 4.0.1.

A fix for this seeming bug would be useful -- e.g. for efficiently implementing XHR streaming.

[jaubourg]

onreadystatechange is used internally by the xhr transport, what you can do is something like this:  http://jsfiddle.net/7JsUR/ using addEventListener.

Dunno how IE handles the situation though. Does attachEvent work on the xhr?

[jaubourg]

OK, that's the best cross-browser solution I can come up with that works in older IEs (8 and below):  http://jsfiddle.net/tBTW2/

attachEvent doesn't work on the xhr which means that: 1) we cannot use it in the xhr transport (we have to use onreadystatechange) 2) we cannot use it in the prefilter

Note the use of "cache: false" in the options because IE is too quick to get the response (but in that case, do you need the progress info?)

[jaubourg]

Duplicate of #9883.