Beginning on October 25th, 2016, Persona will no longer be an option for authentication on BMO. For more details see Persona Deprecated.
Last Comment Bug 501962 - xmlhttprequest not firing all onstatechange events
: xmlhttprequest not firing all onstatechange events
Product: Core
Classification: Components
Component: DOM (show other bugs)
: unspecified
: x86 Windows XP
: -- normal with 6 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
: Andrew Overholt [:overholt]
Depends on: 502959
  Show dependency treegraph
Reported: 2009-07-02 08:16 PDT by tiberius.xxvii
Modified: 2009-07-28 10:57 PDT (History)
12 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

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. (981 bytes, application/octet-stream)
2009-07-02 08:19 PDT, tiberius.xxvii
no flags Details

Description tiberius.xxvii 2009-07-02 08:16:08 PDT
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 2009-07-02 08:19:26 PDT
Created attachment 386516 [details]
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 2009-07-02 21:38:30 PDT
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 2009-07-03 02:05:29 PDT
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:
Comment 4 Kyle Huey [:khuey] (Exited; not receiving bugmail, email if necessary) 2009-07-03 08:14:08 PDT
I can't seem to reproduce this with or without firebug, but I've put the testcase up at if anyone else can.
Comment 5 Pavel Golubeff 2009-07-03 08:44:02 PDT
The testcase attached does not work for me.
Bug occurs when performing long-polling requests.
You can go to 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 2009-07-03 09:00:31 PDT
Test case only worked for me when I had the firebug window opened (stopped at readyState 1)
Comment 7 John J. Barton 2009-07-07 16:59:03 PDT
Regarding Firebug in all of this, please give the version. Please test with 1.5a10 or 1.4a7.
Comment 8 Rob Campbell [:rc] (:robcee) 2009-07-07 20:38:49 PDT
*** Bug 502959 has been marked as a duplicate of this bug. ***
Comment 9 Rob Campbell [:rc] (:robcee) 2009-07-08 07:52:50 PDT
John J. wrote in bug 502959:

"The subject message typically means that script running with the permissions of 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) 2009-07-08 07:58:23 PDT
this also probably needs to be reclassified as Core::Networking or ::HTTP.
Comment 11 Jerome WAGNER 2009-07-09 16:58:30 PDT
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

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 2009-07-28 10:57:56 PDT
Firebug 1.4.1 has been released with a satisfactory workaround for this issue.

Note You need to log in before you can comment on or make changes to this bug.