calling abort method on XMLHttpRequest instance fires onreadystatechange with readyState 4
Martin Honnen
I was running some tests on how the different implementations of
XMLHttpRequest in different browsers react on calling the abort method.
This test case
<http://home.arcor.de/martin.honnen/mozillaBugs/XMLHttpRequest/abortChangesReadyState4.html>
has a HTML form allowing you to select a readyState when to call abort
on an XMLHttpRequest instance and to run the test by clicking the button.
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.
I am not good at reading C++ but the abort implementation at
<http://lxr.mozilla.org/seamonkey/source/extensions/xmlextras/base/src/nsXMLHttpRequest.cpp#671>
indeed seems to do
ChangeState(XML_HTTP_REQUEST_COMPLETED, PR_TRUE, PR_TRUE);
first and only then does
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.
Should I file a bug on this?
--
Martin Honnen
http://JavaScript.FAQTs.com/
Martin Honnen
> 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.
The documentation of MSXML's IXMLHttpRequest abort method
<http://msdn.microsoft.com/library/default.asp?url=/library/en-us/xmlsdk/html/7b1cfc92-5078-404a-85a2-a907fe1184a2.asp>
also says:
"The request will be returned to the UNINITIALIZED state"
and
<http://msdn.microsoft.com/library/default.asp?url=/library/en-us/xmlsdk/html/0e6a34e4-f90c-489d-acff-cb44242fafc6.asp>
defines UNINITIALIZED as 0.
Why does Mozilla do a 4 to 0 transition with readyState, why does it not
directly go to readyState 0?
Martijn
The xmlhttprequest is a Microsoft thing, so Mozilla should do exactly
like Microsoft in this case (also because it makes sense).
It seems to me that the lxr url you gave is indeed the place in the
code where Mozilla is going wrong.
Looking at bonsai:
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/extensions/xmlextras/base/src/nsXMLHttpRequest.cpp&rev=1.147#684
That code was added with bug 258768.
When reading https://bugzilla.mozilla.org/show_bug.cgi?id=258768#c4 it
seems that was a foreseen side-effect of the patch.
Probably you should file a bug on it, I think.
Regards,
Martijn
> _______________________________________________
> dev-tech-xml mailing list
> dev-te...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-xml
>
Lucky
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
http.onreadystatechange = function() {}
http.abort()
Martin Honnen
> 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.
Does the test case I posted
<http://home.arcor.de/martin.honnen/mozillaBugs/XMLHttpRequest/abortChangesReadyState4.html>
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.
Boris Zbarsky
> 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?
-Boris
Lucky
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.
Anne van Kesteren
> 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...
--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
Martin Honnen
> 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/abortChangesReadyState4ProgramIdDelay.html>
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.
Boris Zbarsky
> 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?
-Boris
Lucky
can see the comments in script area per version response.
<http://www.teamcon.com/pub/concepts/microsoft/msxml-xmlhttp-abortReadyStates.html>
Lucky
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.
Martin Honnen
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.