Closed Bug 424212 Opened 17 years ago Closed 17 years ago

[FIX]xmlhttprequest abort method should set status to 0 when it changes readystate to 4

Categories

(Core :: DOM: Core & HTML, defect)

defect
Not set
major

Tracking

()

RESOLVED FIXED

People

(Reporter: fotemac, Assigned: bzbarsky)

References

()

Details

Attachments

(1 file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b5pre) Gecko/2008032005 Minefield/3.0b5pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b5pre) Gecko/2008032005 Minefield/3.0b5pre

The fix for https://bugzilla.mozilla.org/show_bug.cgi?id=379824 does not set .status when Fx3b4 and Fx3b5pre (and presumably the earlier betas) handle the abort method by changing readystate to 4, so that the .status value ends up as 2147746065 (NS_ERROR_NOT_AVAILABLE).  IE's ActiveX implementation and IE7's XMLHttpRequest object sets .status to 0 in that case, and so it is typical to check for both 200 and 0 in the .onreadystatechange handler as an indication that an error has not occurred.  The 0 value similarly could be used for Fx.

The demonstration URL is equivalent to the minimal test case from Bug 379824.


Reproducible: Always

Steps to Reproduce:
1.Access the demonstration URL with Fx3 versus Fx2 or Fx1.5 versions (and other browsers).
2.
3.



This matter is discussed in the m.d.a.f thread starting with:

http://groups.google.com/group/mozilla.dev.apps.firefox/browse_thread/thread/40e0918f5161e7e6/e790d64c5409f05b?hl=en#e790d64c5409f05b
Flags: blocking-firefox3?
Version: unspecified → Trunk
Status: UNCONFIRMED → NEW
Component: General → DOM: Mozilla Extensions
Ever confirmed: true
Flags: blocking-firefox3?
Product: Firefox → Core
QA Contact: general → general
restoring flags
Flags: blocking1.9?
Summary: xmlhttprequest abort method should set status to 0 when it changes readystate to 4 → [FIX]xmlhttprequest abort method should set status to 0 when it changes readystate to 4
Attached patch Could do thisSplinter Review
Jonas, what do you think?  Should we be doing this?  Should we do this for 1.9?
Assignee: nobody → bzbarsky
Status: NEW → ASSIGNED
Attachment #310843 - Flags: superreview?(jonas)
Attachment #310843 - Flags: review?(jonas)
Does the spec say anything here?
Attachment #310843 - Flags: superreview?(jonas)
Attachment #310843 - Flags: superreview+
Attachment #310843 - Flags: review?(jonas)
Attachment #310843 - Flags: review+
-'ing.  Will take a patch.  Not a regression.
Flags: blocking1.9? → blocking1.9-
Comment on attachment 310843 [details] [diff] [review]
Could do this

Looking for approval.  Simple change that gives us IE compat.  Affects web compat, so probably best to get into the beta.
Attachment #310843 - Flags: approval1.9b5?
Attachment #310843 - Flags: approval1.9?
Comment on attachment 310843 [details] [diff] [review]
Could do this

a=beltzner
Attachment #310843 - Flags: approval1.9b5?
Attachment #310843 - Flags: approval1.9b5+
Attachment #310843 - Flags: approval1.9?
Attachment #310843 - Flags: approval1.9+
Checked in, with test.
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Changing file name in the demonstration URL to indicate the current bug number.
Component: DOM: Mozilla Extensions → DOM
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: