Closed
Bug 705495
Opened 14 years ago
Closed 12 years ago
XMLHTTPrequest onreadystate fails 3->4
Categories
(Firefox :: Extension Compatibility, defect)
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
Updated•14 years ago
|
Component: DOM → DOM: Mozilla Extensions
Comment 2•14 years ago
|
||
But DOM:ME is the correct component for XHR bugs. Call it silly, but that's the way it happens to be.
Comment 3•14 years ago
|
||
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.
Comment 4•14 years ago
|
||
Meh. I think there's more value to have them all in one component than to argue about which name makes the most sense...
Comment 5•14 years ago
|
||
I have always filed XHR bugs under DOM Core & HTML. It's a bit bikeshedding argument.
Comment 6•14 years ago
|
||
Indeed, since what's needed here is a testcase actually showing the problem. Comment 0 doesn't exactly give enough information to reproduce...
| Reporter | ||
Comment 7•14 years ago
|
||
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.
Comment 8•14 years ago
|
||
I only see login screen on both pages. How can I reproduce the bug? Do I have to create an account?
Comment 9•14 years ago
|
||
I couldn't reproduce the bug with invalid username & password.
login-fails.html:
[16:20:55.728] 1 @ http://www.digitalelephant.org/test/xmlhttp/xml-http-old.js:94
[16:20:55.755] GET http://www.digitalelephant.org/test/xmlhttp/logCheck.php?user=a&step=1 [HTTP/1.0 200 OK 547ms]
[16:20:56.303] 2 @ http://www.digitalelephant.org/test/xmlhttp/xml-http-old.js:94
[16:20:56.307] 3 @ http://www.digitalelephant.org/test/xmlhttp/xml-http-old.js:94
[16:20:56.310] 4 @ http://www.digitalelephant.org/test/xmlhttp/xml-http-old.js:94
[16:20:56.317] 1 @ http://www.digitalelephant.org/test/xmlhttp/xml-http-old.js:94
[16:20:56.338] GET http://www.digitalelephant.org/test/xmlhttp/logCheck.php?md5=02e232e1810b837c7a2e4c6e24a34501&step=2 [HTTP/1.0 200 OK 531ms]
[16:20:56.877] 2 @ http://www.digitalelephant.org/test/xmlhttp/xml-http-old.js:94
[16:20:56.881] 3 @ http://www.digitalelephant.org/test/xmlhttp/xml-http-old.js:94
[16:20:56.884] 4 @ http://www.digitalelephant.org/test/xmlhttp/xml-http-old.js:94
login.html:
[16:22:27.298] GET http://www.digitalelephant.org/test/xmlhttp/logCheck.php?user=a&step=1 [HTTP/1.0 200 OK 359ms]
[16:22:27.663] 4 @ http://www.digitalelephant.org/test/xmlhttp/xml-http.js:92
[16:22:27.683] GET http://www.digitalelephant.org/test/xmlhttp/logCheck.php?md5=326e65c176554aeb855dc960ef525cb6&step=2 [HTTP/1.0 200 OK 985ms]
[16:22:28.669] 4 @ http://www.digitalelephant.org/test/xmlhttp/xml-http.js:92
| Reporter | ||
Comment 10•14 years ago
|
||
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
Comment 11•14 years ago
|
||
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)?
| Reporter | ||
Comment 12•14 years ago
|
||
***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.
Comment 13•14 years ago
|
||
You can see the "console.log(...)" output on Web Console (press Ctrl+Shift+K).
Comment 14•14 years ago
|
||
OK, this sounds like Firebug is just screwing something up... Honza?
Component: DOM → Extension Compatibility
Product: Core → Firefox
QA Contact: general → extension.compatibility
Comment 15•14 years ago
|
||
What version of Firebug do you use?
Honza
| Reporter | ||
Comment 16•14 years ago
|
||
I have automatic update set, so I am using 1.9.0b2
Comment 17•12 years ago
|
||
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.
Comment 18•12 years ago
|
||
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.
Comment 19•12 years ago
|
||
(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
| Reporter | ||
Comment 20•12 years ago
|
||
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.
Comment 21•12 years ago
|
||
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.
Description
•