Closed Bug 705495 Opened 14 years ago Closed 12 years ago

XMLHTTPrequest onreadystate fails 3->4

Categories

(Firefox :: Extension Compatibility, defect)

8 Branch
x86
Windows XP
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: means, Unassigned)

Details

User Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20100101 Firefox/8.0 Build ID: 20111104165243 Steps to reproduce: I've built a library of javascript that allows me to supply JS initialization of HTML page fragments as part of the XML response from the server. When one response initiates a second XMLHTTPrequest, bug appears. Actual results: onreadystatechange handler indicated changes 1->2->3->4 for first request; for second request, 1->2->3 and no more. A handler attached to onload event correctly fired to indicate transition to readyState = 4. Expected results: onreadystatechange event should fire, but does not.
Component: General → DOM
Product: Firefox → Core
QA Contact: general → general
Component: DOM → DOM: Mozilla Extensions
XHR is not a Mozilla extension.
Component: DOM: Mozilla Extensions → DOM
But DOM:ME is the correct component for XHR bugs. Call it silly, but that's the way it happens to be.
Probably because XHR *was* a Mozilla extension. It is not anymore. So it is meaningless (and even wrong) filing new XHR bugs under DOM:ME.
Meh. I think there's more value to have them all in one component than to argue about which name makes the most sense...
I have always filed XHR bugs under DOM Core & HTML. It's a bit bikeshedding argument.
Indeed, since what's needed here is a testcase actually showing the problem. Comment 0 doesn't exactly give enough information to reproduce...
Sorry that it has taken me a couple of days to create a publishable test of this problem. The relevant URLs are http://www.digitalelephant.org/test/xmlhttp/login.html and http://www.digitalelephant.org/test/xmlhttp/login-fails.html These two HTML files are identical except that one specifies xml-http.js and the other xml-http-old.js. The old version depends on correct firing of readystatechange; the newer version adds a listener to the load event. Reporting of the ready state is through the Firebug console.log() facility.
I only see login screen on both pages. How can I reproduce the bug? Do I have to create an account?
As Masatoshi Kimura figured out, to exercise this bug, one needs to fill in (any) username and password, then click login I was afraid this might not happen on all systems, or the bug would have been reported sooner. On my hardware, the results for login.html are identical to those above, except that the times are 32ms and 84 ms. My results for login-fails.html are: 1 @ http://www.digitalelephant.org/test/xmlhttp/xml-http-old.js:94 GET http://www.digitalelephant.org/test/xmlhttp/logCheck.php?user=a&step=1 HTTP/1.0 200 OK 62ms] 1 @ http://www.digitalelephant.org/test/xmlhttp/xml-http-old.js:94 2 @ http://www.digitalelephant.org/test/xmlhttp/xml-http-old.js:94 3 @ http://www.digitalelephant.org/test/xmlhttp/xml-http-old.js:94 4 @ http://www.digitalelephant.org/test/xmlhttp/xml-http-old.js:94 1 @ http://www.digitalelephant.org/test/xmlhttp/xml-http-old.js:94 GET http://www.digitalelephant.org/test/xmlhttp/logCheck.php?md5=02e232e1810b837c7a2e4c6e24a34501&step=2 1 @ http://www.digitalelephant.org/test/xmlhttp/xml-http-old.js:94
I see what Masatoshi Kimura sees over here.... David, can you try in safe mode (or even just with Firebug disabled in the addons manager)?
***Interesting approach*** I *disabled all panels* using the Firebug buttons in the upper right corner, which of course makes the "console.log(...)" javascript pretty useless. But, it appears that the second XMLHttp request completes for the case login-fails.html (because the two INPUT boxes turn yellow, indicating that the completion code received a "No" response. If I then re-enable Firebug, refresh the page and re-run the test, the boxes *do not* turn yellow, indicating that the second XMLHttp request did not complete.
You can see the "console.log(...)" output on Web Console (press Ctrl+Shift+K).
OK, this sounds like Firebug is just screwing something up... Honza?
Component: DOM → Extension Compatibility
Product: Core → Firefox
QA Contact: general → extension.compatibility
What version of Firebug do you use? Honza
I have automatic update set, so I am using 1.9.0b2
I have very similar problem with readyState of a document in an iframe. The state of main document is expected (complete) but the state of second document (in iframe) is "interactive". The state of iframe document ends in state "interactive" and it is never changed to "complete". Tested on Firefox 14 and 21.
That's a completely unrelated problem, since XHR readystate and document readystate have nothing to do with each other. Please file a separate bug, with a testcase.
(In reply to David Means from comment #16) > I have automatic update set, so I am using 1.9.0b2 Do you still see the problem with Firebug 1.11.4 and Firefox 21? Firebug 1.11.4 is the current version on AMO: https://addons.mozilla.org/en-US/firefox/addon/firebug/ Honza
I had to restart my Firefox to get it up to version 21.0 :-) since I moved to Windoze 7, and have not had to restart my desktop machine every morning. The two tests I posted (Comment #7) behave identically under Firefox 21.0 with Firebug 1.11.4 installed. Thanks for checking in about this. It appears that this bug is now crushed.
Marking WORKSFORME per comment #20.
Status: UNCONFIRMED → RESOLVED
Closed: 12 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.