Mozilla (both Firefox 1.5.0.1 and a Firefox trunk nightly (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060331 Firefox/1.6a1) behave rather strangely, if you call abort when the readyState is 1, 2, or 3 then as a result of that call the onreadystatechange event handler is fired with readyState 4, then readyState is changed to 0.
Other implementations (Opera 8.5, IE 6 with Microsoft.XMLHTTP) simply abort and set readyState to 0, not firing any onreadystatechange handler, certainly not one with readyState 4.
I can't find any open bugs on XMLHttpRequest and abort.
ChangeState(XML_HTTP_REQUEST_UNINITIALIZED, PR_FALSE); // IE seems to do it
what other implementations do.
For a client script assigned to onreadystatechange it is obviously difficult in Mozilla to distinguish between a normal readyState 4 change and one that is caused by an abort call.
Martin Honnen wrote: > Other implementations (Opera 8.5, IE 6 with Microsoft.XMLHTTP) simply > abort and set readyState to 0, not firing any onreadystatechange > handler, certainly not one with readyState 4.
> > Other implementations (Opera 8.5, IE 6 with Microsoft.XMLHTTP) simply > > abort and set readyState to 0, not firing any onreadystatechange > > handler, certainly not one with readyState 4.
Martijn wrote: > I think you're right. > The xmlhttprequest is a Microsoft thing, so Mozilla should do exactly > like Microsoft in this case (also because it makes sense).
I think in this case, mozilla is doing the same thing as microsoft, but so much that it is actually mirroring a bug that msxml has, for it does go to 4 after abort(), and then to 0, only the documentation states differently.
common coding practices is to remove the onreadystatechange by setting it to an empty function after abort, for using MSXML you cannot simply null out the onreadystatechange
Lucky wrote: > I think in this case, mozilla is doing the same thing as microsoft, but > so much that it is actually mirroring a bug that msxml has, for it does > go to 4 after abort(), and then to 0, only the documentation states > differently.
Martijn wrote: > That code was added with bug 258768.
Actually, no. Bug 258768 touched the code, but didn't add it. The code was added in bug 218236. See in particular https://bugzilla.mozilla.org/show_bug.cgi?id=218236#c11 for comparisons to IE 6.0 behavior. Note the inconsistency in IE behavior depending on the value of readyState when abort() is called (1 and 2 give different behavior).
We could probably emulate this inconsistent behavior....
Has someone raised this with the web apis WG, since they're currently working on specifying XMLHttpRequest?
>> I think in this case, mozilla is doing the same thing as microsoft, >> but so much that it is actually mirroring a bug that msxml has, for it >> does go to 4 after abort(), and then to 0, only the documentation >> states differently.
> show any change to readyState 4 then 0 when calling abort with > readyState 1, 2, or 3? What IE version is that then? > IE 6 here simply aborts and goes to readyState 0.
No, but that testcase is a bit off, for if you call as you get to a 1 readyState, that could be the intial 1 that really hasn't done anything.. eg: the 1, 1, 2, 3, 4 states order, when onreadystatechange is set before the open/send calls.
the better test is to call the abort after a quick timeout.
i have experienced the jump to 4 after doing my own abort code for a timeout, if server is busy. setting a setTimeout(..., 10000) to then call the abort(); and then it went to a readyState 4 in msxml..
you could simply move the timeout down to a sec, or less, and call upon a website that may have a slight latency to achieve another scenario of abort() being called.
will cook up a testcase to show tomorrow if time allows, a bit under weather right now.
On Sun, 02 Apr 2006 19:46:43 +0200, Boris Zbarsky <bzbar...@mit.edu> wrote: > Has someone raised this with the web apis WG, since they're currently > working on specifying XMLHttpRequest?
I did. ISSUE-58. For some reason the current specification specifies what Mozilla does, which doesn't make much sense...
Boris Zbarsky wrote: > See in particular > https://bugzilla.mozilla.org/show_bug.cgi?id=218236#c11 for comparisons > to IE 6.0 behavior. Note the inconsistency in IE behavior depending on > the value of readyState when abort() is called (1 and 2 give different > behavior).
I have played with variations of my test case, this variation <http://home.arcor.de/martin.honnen/mozillaBugs/XMLHttpRequest/abortCh...> which only calls abort using setTimeout with a configurable delay indeed consistently for abort called on readyState 1 program id Microsoft.XMLHTTP, Msxml2.XMLHTTP, Msxml2.XMLHTTP.3.0 delay 10 milliseconds shows readystatechange events as 1 -> 1 -> 4 the abort sets readyState to 0 (and does that twice due to 1 -> 1 transition).
Those program ids above are all bound to MSXML 3 on my system, if I run the same test with program ids for MSXML 4 or MSXML 5 or MSXML 6 however the sequence is simply 1 then abort is called and it sets readyState to 0.
MSXML 3 is what is installed with IE 6, the other MSXML versions are not necessarily around to be used on the client.
Martin Honnen wrote: > Those program ids above are all bound to MSXML 3 on my system, if I run > the same test with program ids for MSXML 4 or MSXML 5 or MSXML 6 however > the sequence is simply > 1 > then abort is called and it sets readyState to 0.
Interesting. Could you post that to the web apis discussion?
>> See in particular >> https://bugzilla.mozilla.org/show_bug.cgi?id=218236#c11 for >> comparisons to IE 6.0 behavior. Note the inconsistency in IE behavior >> depending on the value of readyState when abort() is called (1 and 2 >> give different behavior).
> which only calls abort using setTimeout with a configurable delay indeed > consistently for abort called on > readyState 1 > program id Microsoft.XMLHTTP, Msxml2.XMLHTTP, Msxml2.XMLHTTP.3.0 > delay 10 milliseconds > shows readystatechange events as > 1 -> 1 -> 4 > the abort sets readyState to 0 (and does that twice due to 1 -> 1 > transition).
> Those program ids above are all bound to MSXML 3 on my system, if I run > the same test with program ids for MSXML 4 or MSXML 5 or MSXML 6 however > the sequence is simply > 1 > then abort is called and it sets readyState to 0.
> MSXML 3 is what is installed with IE 6, the other MSXML versions are not > necessarily around to be used on the client.
this may help show the situation? can see the comments in script area per version response.
Lucky wrote: > Martin Honnen wrote: >> Boris Zbarsky wrote:
>>> See in particular >>> https://bugzilla.mozilla.org/show_bug.cgi?id=218236#c11 for >>> comparisons to IE 6.0 behavior. Note the inconsistency in IE >>> behavior depending on the value of readyState when abort() is called >>> (1 and 2 give different behavior).
>> which only calls abort using setTimeout with a configurable delay >> indeed consistently for abort called on >> readyState 1 >> program id Microsoft.XMLHTTP, Msxml2.XMLHTTP, Msxml2.XMLHTTP.3.0 >> delay 10 milliseconds >> shows readystatechange events as >> 1 -> 1 -> 4 >> the abort sets readyState to 0 (and does that twice due to 1 -> 1 >> transition).
>> Those program ids above are all bound to MSXML 3 on my system, if I >> run the same test with program ids for MSXML 4 or MSXML 5 or MSXML 6 >> however the sequence is simply >> 1 >> then abort is called and it sets readyState to 0.
>> MSXML 3 is what is installed with IE 6, the other MSXML versions are >> not necessarily around to be used on the client.
> this may help show the situation? > can see the comments in script area per version response.
i was running this example local, to not get the "permission denied" as it will spawn random domain requests, so they will never really return a response, to simulate network failure, or lack to connect to a server.
>> Those program ids above are all bound to MSXML 3 on my system, if I >> run the same test with program ids for MSXML 4 or MSXML 5 or MSXML 6 >> however the sequence is simply >> 1 >> then abort is called and it sets readyState to 0.
> Interesting. Could you post that to the web apis discussion?
I am currently not subscribed there. According to the web archive of the mailing list Anne van Kesteren has already posted a link to this newsgroup thread on that list.
