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)

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.

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.

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

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.

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.

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

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

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.

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

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.

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

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