501962 - xmlhttprequest not firing all onstatechange events

Status: RESOLVED INVALID

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

Description

[tiberius.xxvii]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1) Gecko/20090624 Firefox/3.5 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1) Gecko/20090624 Firefox/3.5 (.NET CLR 3.5.30729)

I have a page that uses Sajax, but stopped working perfectly upon upgrading to Firefox 3.5. The problem came down to the XMLHttpRequest object not firing every onstatechange event. The readyState starts at 0, fires when it gets to 1 (set up), and stops there. This would be to say the request was never even sent (ready state 2), but according to Firebug, the request was sent and even received a response. I have tried this with a page not using Sajax, just my own simple XMLHttpRequester and it still encounters this issue. The issue does not appear to occur with instant response requests, only if it takes more than a second.

Reproducible: Sometimes

Steps to Reproduce:
1. Create an XMLHttpRequest object to a page that may take some time to load
2. Set the callback function to display the readyState
3. Send the request
Actual Results:  
About 1 in 15 times, the request will stop firing onstatechange events after getting to readyState 1, even though the request was fully processed.

Expected Results:  
Continued firing onstatechange events through readyState 4 (complete)

Comment 1

[tiberius.xxvii]

Attachment: A simple testing script, uses javascript to request the page again but with a wait time. Logs the results. Should cause the error every so often.

Sorry I don't have a server I can put this on and link to, I'm working on an internal one for my network, so you have to test the page on your own server.

Comment 2

[Nicholas C. Zakas]

I've experienced the same issue. It seems to happen most often when the response takes longer than 5 seconds to receive from the server. What I believe happens is that the readyState property does change but the readystatechange event doesn't fire. Luckily, the load event still fires. If I check readyState in onload, it is indeed 4, which is what led me to believe the readystatechange was the culprit rather than readyState being incorrect.

Comment 3

[Christopher Blum]

I doubt that this is a firefox bug. To me it looks more like a firebug problem.
Only happens when firebug is enabled.
Find a related issue here: http://code.google.com/p/fbug/issues/detail?id=1948

Comment 4

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

I can't seem to reproduce this with or without firebug, but I've put the testcase up at http://www.kylehuey.com/moz/testRequest.php if anyone else can.

Comment 5

[Pavel Golubeff]

The testcase attached does not work for me.
Bug occurs when performing long-polling requests.
You can go to facebook.com and look, how their chat works. 
After each message, you send, browser starts new request to server. 
If you open firebug, you can see, that after several requests, you send, new requests does not start. It happens, because script does not know, that previous request finished.
So, go to facebook and try to chat with somebody for 5 minutes.

Comment 6

[Christopher Blum]

Test case only worked for me when I had the firebug window opened (stopped at readyState 1)

Comment 7

[John J. Barton]

Regarding Firebug in all of this, please give the version. Please test with 1.5a10 or 1.4a7.

Comment 9

[Rob Campbell [:rc] (:robcee)]

John J. wrote in bug 502959:

"The subject message typically means that script running with the permissions of
http://sendsome.org attempted to access an object that it's not allowed to
access.  Specifically, the "wrapper" in this case is the JS reflection of the
underlying C++ object.  Permission to create that was denied.  UnnamedClass
means that the C++ object did not indicate what kind of object it is (normal
for objects not meant to be exposed to JavaScript) and that the error reporter
therefore can't tell you what sort of object it was"

also, see Kyle's comment #4 above for a hosted test case that can reproduce this bug. I've been able to do it based on Nicholas Z's instructions of setting the timer to 10 and loading up a dozen or two requests. Eventually, they stop reporting in the text area on the page, but Firebug still shows them coming into the console.

Comment 10

[Rob Campbell [:rc] (:robcee)]

this also probably needs to be reclassified as Core::Networking or ::HTTP.

Comment 11

[Jerome WAGNER]

Hoping this may help :

The only source code where I found what looks like an occurence of the message we get ("Permission denied for <domain> to create wrapper for object of <class>") is

http://mxr.mozilla.org/mozilla1.9.1/source/caps/src/nsScriptSecurityManager.cpp#2858

If we take for granted that this function (nsScriptSecurityManager::CanCreateWrapper) is always called for each onreadystatechange event handling, it could probably mean that 

2880     //--See if the object advertises a non-default level of access
2881     //  using nsISecurityCheckedComponent
2882     nsCOMPtr<nsISecurityCheckedComponent> checkedComponent =
2883         do_QueryInterface(aObj);

not all events=aObj would have the same implementation of this interface, leading to different objectSecurityLevels

The bug would be either in one of the implementations of this interface or in the fact that the call to CheckXPCPermissions (line 2889) has arg2=arg3=null

2889    nsresult rv = CheckXPCPermissions(aObj, nsnull, nsnull, objectSecurityLevel);

since these 2 args seem to be used to understand better who wants access to what, sending nsnull may be insufficient in some cases (?)

I only have a very far understanding of these APIs so do not hesitate to rule out what i am saying here.

Comment 12

[John J. Barton]

Firebug 1.4.1 has been released with a satisfactory workaround for this issue.

Comment 13

[Anne (:annevk)]

Closing due to old age and lack of fresh information. Also haven't seen this problem in the XMLHttpRequest test suite.