XMLHttpRequest and garbage collection

[Henri Sivonen]

I got the following error:

Error: [Exception... "Component returned failure code: 0x80040111
(NS_ERROR_NOT_AVAILABLE) [nsIXMLHttpRequest.status]" nsresult:
"0x80040111 (NS_ERROR_NOT_AVAILABLE)"

.... with Firefox when using XMLHttpRequest. What's happenening? Is the
object being garbage collected before the network operation finishes?

My usage pattern is:

function modelChanged() {
var req = new XMLHttpRequest()
req.open('PUT', ... , true)
req.onreadystatechange = function() {
if(req.readyState == 4) {
// do stuff
}
}
req.send(documentToSend)
}


I am not holding a reference to the req object from the global scope.
Should I? I don't know how many HTTP operations I have going at a given
moment. What kind of stretchable data structure should I use for holding
the references to the request objects? Or should I attempt to cancel the
unfinished connection if another one needs to start before the preceding
one has finished?

 

[Martin Honnen]

I got the following error:

Error: [Exception... "Component returned failure code: 0x80040111
(NS_ERROR_NOT_AVAILABLE) [nsIXMLHttpRequest.status]" nsresult:
"0x80040111 (NS_ERROR_NOT_AVAILABLE)"

... with Firefox when using XMLHttpRequest. What's happenening? Is the
object being garbage collected before the network operation finishes?

Are you trying to read the status property at all? Your code below
doesn't show any access to status.

function modelChanged() {
var req = new XMLHttpRequest()
req.open('PUT', ... , true)
req.onreadystatechange = function() {
if(req.readyState == 4) {
// do stuff
}
}
req.send(documentToSend)
}


I am not holding a reference to the req object from the global scope.
Should I? I don't know how many HTTP operations I have going at a given
moment. What kind of stretchable data structure should I use for holding
the references to the request objects? Or should I attempt to cancel the
unfinished connection if another one needs to start before the preceding
one has finished?

There is a method called abort to do that
<http://www.xulplanet.com/references/objref/XMLHttpRequest.html>
so perhaps calling that improves things.

As for the error you get, are you able to use some HTTP sniffer to check
the HTTP request headers and the HTTP response headers that are occuring
when Firefox displays the error?
You could for instance install the extension
<http://livehttpheaders.mozdev.org/>
Then it might be easier to say/see why Firefox gives that error and
whether there is a bug in Mozilla or something else goes wrong.

But a search on Google groups
<http://groups-beta.google.com/group..._doneTitle=Back+to+Search&&d#54be6a36b56d276f>
shows that others have run into the problem before and it seems there
are bugs open on bugzilla.