XMLHttpRequest.abort() error
Foteos Macrides
messages on XMLHttpRequest aborts, under circumstances for which Fx2.0.0.12,
IE7, Opera and Safari do not.
This appears to be:
https://bugzilla.mozilla.org/show_bug.cgi?id=379824
and a number of subsequent bugs which have been marked as DUPLICATEs of it.
Bug 379824 has been designated as RESOLVED FIXED, but given that neither Fx2
nor any of the other browsers behave that way, it seems likely that if it
stays that way, many users of Fx3 will not agree with that designation. :-)
Fote
--
Mike Beltzner
If not, could you please do so?
cheers,
mike
This appears to be:
https://bugzilla.mozilla.org/show_bug.cgi?id=379824
Fote
--
_______________________________________________
dev-apps-firefox mailing list
dev-apps...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-apps-firefox
Mike Shaver
> The current Minefield is yielding 2147746065 (NS_ERROR_NOT_AVAILABLE) error
> messages on XMLHttpRequest aborts, under circumstances for which Fx2.0.0.12,
> IE7, Opera and Safari do not.
>
> This appears to be:
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=379824
>
I don't think it's the same bug, as summarized. You should file a bug
with a testcase about it, since that one is FIXED and therefore not
likely to be on people's radars; I would nominate it for blocking 1.9,
since it sounds like a content regression we should look at pretty
seriously. (Don't REOPEN unless the patch gets backed out, or the
original problem addressed by the bug -- in this case the readystate
protocol -- resurfaces otherwise.)
Mike
Boris Zbarsky
> The current Minefield is yielding 2147746065 (NS_ERROR_NOT_AVAILABLE) error
> messages on XMLHttpRequest aborts, under circumstances for which Fx2.0.0.12,
> IE7, Opera and Safari do not.
Please file a bug with a testcase. What exactly are you doingto get the
NS_ERROR_NOT_AVAILABLE?
> This appears to be:
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=379824
It doesn't to me. For one thing, that bug was present in Firefox 2, whereas the
problem you're talking about is a regression, right?
-Boris
Foteos Macrides
I tried the minimal test case for
https://bugzilla.mozilla.org/show_bug.cgi?id=379824
and both Minefield and Fx3.0b4 (I don't have earlier betas to test) issue
the alert with 2137746065 status (indicating that a readystatechange with
r.readyState==4 occurred). In contrast, Fx2, Fx1.5, Opera and Safari do
not issue that inappropriate alert. IE7 issues the alert with a 0 status,
but AJAX utilities typically take such IE7 behavior into account and issue
an error message only if the status is neither 200 nor 0.
If the Minefield and Fx3.0b4 behavior is a regression, I may not
understand what is going on well enough to file a bug. Perhaps someone
who was involved in dealing with the bug should assess the current
situation (using that bug's testcase) and either REOPEN it or file a new
bug with an accurate description of the problem.
Fote
--
Boris Zbarsky
> I tried the minimal test case for
> https://bugzilla.mozilla.org/show_bug.cgi?id=379824
> and both Minefield and Fx3.0b4 (I don't have earlier betas to test) issue
> the alert with 2137746065 status
Aha! So your real issue is that GetStatus() now returns the same thing it
always returns when there is no status information. And what you want to happen
is that this returns 0. We should do that. Is a bug filed?
> (indicating that a readystatechange with
> r.readyState==4 occurred).
No, a change with r.readyState == 0 occurred. If it were 4, you'd get the
status code.
> In contrast, Fx2, Fx1.5, Opera and Safari do
> not issue that inappropriate alert.
Well, Fx2/Fx1.5 put us in readyState == 4, so they return the channel status.
That's the wrong thing to be doing.
> IE7 issues the alert with a 0 status
Right, that's what the XMLHttpRequest spec says as well. We should do that,
esp. if it helps with site compat. Again, is a bug filed?
-Boris
Foteos Macrides
I don't see on what basis you are making these claims. Did you look at the
minimal test case for https://bugzilla.mozilla.org/show_bug.cgi?id=379824
Here's what I used:
http://www.macridesweb.com/oltest/Bug379824.html
Which is functionally the original test case, but with the file names
changed for my server:
Bug379824.html
================
<script type="text/javascript">
r=new XMLHttpRequest()
r.onreadystatechange=function(){
if(r.readyState==4)alert('r.status = '+r.status)
}
r.open('POST','Bug379824.php5?'+Math.random(),1)
r.send('')
setTimeout(function(){r.abort()},1000)
</script>
Bug379824.php5
================
<?
sleep(4);
print('ok');
?>
The alert is triggered if readyState==4 (not 0). AJAX utilities then
typically check whether the status is neither 200 nor 0 for issuing
an alert, instead of just showing the status as in the minimal test
case.
I haven't filed a bug. Perhaps you should, with either the original test
case or with a URL for the equivalent one on my server.
Fote
--
Boris Zbarsky
> I don't see on what basis you are making these claims.
On the basis of what the XMLHttpRequest spec says?
> Did you look at the
> minimal test case for https://bugzilla.mozilla.org/show_bug.cgi?id=379824
I actually had not. Mea culpa. I've looked now, at your testcase. Thank you
for posting the server-side source.
> The alert is triggered if readyState==4 (not 0). AJAX utilities then
> typically check whether the status is neither 200 nor 0 for issuing
> an alert, instead of just showing the status as in the minimal test
> case.
See <http://www.w3.org/TR/XMLHttpRequest/#abort>. In your case, you're calling
abort() when the state is OPENED and the send() flag is true, so the readyState
gets changed to 4, per step 3 of that algorithm.
So again, the only issue is the value returned by .status. The readyState
change is correct.
-Boris
Foteos Macrides
> See <http://www.w3.org/TR/XMLHttpRequest/#abort>. In your case, you're
> calling abort() when the state is OPENED and the send() flag is true, so
> the readyState gets changed to 4, per step 3 of that algorithm.
Is there an existing bug associated with the implementation of that?
> So again, the only issue is the value returned by .status. The readyState
> change is correct.
Is that a new bug or a loose end from an existing bug for implementing the
above?
Again, perhaps you should file whatever is needed, and then post the bug's
URL to this thread. As I indicated, if you end up with .readyState==4 and
a status of 0 for the function assigned to .onreadystatechange then Fx3
should remain backward compatible with Fx2 and Fx1.5 for typical AJAX
utilities (definitely my own :-).
Fote
--
Foteos Macrides
I've been plowing through http://www.w3.org/TR/XMLHttpRequest/ and
http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html but still haven't
found a clear explanation for why the status should be set to 0, i.e., that
still seems to me as just a kludge to deal with IE's behavior with its
original, ActiveX-based implementation, and IE7's retention of that
behavior for its XMLHttpRequest object. Even though it would work
out OK if Fx3 behaved that way too, might it be better to set .status to
200 in conjunction with the bumping of .readyState to 4. In other words,
"OK 200 The request was fulfilled" meaning that it was aborted cleanly.
After all, http://www.w3.org/TR/XMLHttpRequest/ is still only a
Working Draft and not yet an approved Recommendation. Perhaps
you know about intentions which might not be in the current draft,
but if you can help me to understand why you like the idea of setting
.status to 0 in that case, I would appreciate it.
Fote
--
Boris Zbarsky
>> See <http://www.w3.org/TR/XMLHttpRequest/#abort>. In your case, you're
>> calling abort() when the state is OPENED and the send() flag is true, so
>> the readyState gets changed to 4, per step 3 of that algorithm.
>
> Is there an existing bug associated with the implementation of that?
<https://bugzilla.mozilla.org/show_bug.cgi?id=379824>. And it's fixed. That
is, we implement it.
>> So again, the only issue is the value returned by .status. The readyState
>> change is correct.
>
> Is that a new bug or a loose end from an existing bug for implementing the
> above?
That's a new bug which needs to be filed.
Note that in Firefox 2, we also go into readyState == 4. But when you get
.status, we throw, which is why your testcase doesn't alert in Firefox 2. We
fixed the throwing because it was breaking sites.
> Again, perhaps you should file whatever is needed
If I can find the time, I will. But this is a very low priority for me, to be
honest, so it's likely to take a while if you leave it to me to do. If the bug
does get filed, I can probably get a patch up, but I just don't have time to go
through the bug-filing rigmarole for this.
Unless you want to fix some security bugs while I do that?
> As I indicated, if you end up with .readyState==4 and
> a status of 0 for the function assigned to .onreadystatechange then Fx3
> should remain backward compatible with Fx2 and Fx1.5
Not at all. And as I said above, being compatible with them here would be a bad
idea anyway.
Of course a status of 0 would be compatible with IE, which is why we should do it.
-Boris
Boris Zbarsky
> I've been plowing through http://www.w3.org/TR/XMLHttpRequest/ and
> http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html but still haven't
> found a clear explanation for why the status should be set to 0
Because IE does it. You're right that the published draft doesn't say it should
be 0. But that draft's editor does, sorta, in
<https://bugzilla.mozilla.org/show_bug.cgi?id=304980&mark=28#c28>. That's over
a year ago, so maybe they changed it again. You might want to ask on the
relevant W3C list to make sure.
> i.e., that
> still seems to me as just a kludge to deal with IE's behavior
Yes, of course. So is all the rest of XMLHttpRequest.
> might it be better to set .status to
> 200 in conjunction with the bumping of .readyState to 4.
No, because that would be mis-informing the caller (e.g. make them think it's OK
to look at the responseText/responseXML).
> After all, http://www.w3.org/TR/XMLHttpRequest/ is still only a
> Working Draft and not yet an approved Recommendation.
Indeed. That's why they keep mutating it and why trying to follow it is such a
pain.
> Perhaps you know about intentions which might not be in the current draft
At this point you know as much as I do. ;)
> but if you can help me to understand why you like the idea of setting
> .status to 0 in that case, I would appreciate it.
Because it gives maximal compat with IE and doesn't seem to have any downsides...
If we don't do 0, we should do exactly what we're doing now. We definitely
shouldn't do what Fx 1.5 and Fx 2 did.
-Boris
Foteos Macrides
> That's a new bug which needs to be filed.
It's filed as: https://bugzilla.mozilla.org/show_bug.cgi?id=424212
Fote
--