0x80004005 (NS ERROR FAILURE) and other firefox errors
From Helpful
| These are primarily notes This is probably not going to be complete in any real sense, and exists to contain bits of useful information. |
Contents |
0x80040111 (NS ERROR NOT AVAILABLE)
Reason
The direct reason is often that you have a XMLHttpRequest onerror handler in which you tried to read the result's status (or statusText) when that value is not available (usually meaning it was broken off, or it failed in a specific way).
The W3 specs tell you that you shouldn't try to read status in the onerror handler because for some problems it may not be set, and that in this case an error must (!) be raised when you read it.
This error is mostly specific to Gecko (Firefox, Mozilla) because it adheres to those specs closer than most other browsers. The Gecko specs also tell you not to do this (...as I recall, I can't actually find it right now).
The underlying cause is often that the browser never got a response with a HTTP status to parse out, for example because:
- a connection broke because of some connectivity problem
- a requests was broken off on the client (possibly specifically because...)
- an ongoing AJAX call is canceled by page unload
- (one somewhat common form of this is when you trigger AJAX from an input form that also causes a page-reload-style submission of the calling page (often a form with a submit-type button))
- or sometimes a (seriously) malformed server response, such as
- deformed data made by a dynamic script
- no data at all (no HTTP headers, no body)
Fix
If this happens in your own handler code, the simplest fix is often wrapping the status read in a try-catch, since the error case should often go to "oh well then, forget it" code anyway.
If you use AJAX from some library (and implicitly its error handler), it's a bug in that library that has not yet been fixed, so google around for a fix, and bug its creator. If such a library it lets you write your own callbacks and its documentation didn't warn you about this, bug them about it too.
When caused by the form submission problem, you can usually avoid it fairly easily. One solution is to use only a <button>, <input type="button">, or anything else that looks clickable enough but does not submit the form (like a submit button would), so that the only event is the AJAXing.
(A somewhat more hackish solution is to omit the <form>, so that a submit-type button wouldn't know where to go, so won't do anything -- but this may not work so predictably across all browsers.)
See also
- http://www.w3.org/TR/XMLHttpRequest/ (the "The XMLHttpRequest Object" section)
- https://bugzilla.mozilla.org/show_bug.cgi?id=238559
0x80004005 (NS ERROR FAILURE)
A general-purpose mozilla error, but if your own Javascript causes it it usually points to one of relatively few problems.
Figuring out what failed
The error will mention a function after the error, which gives a decent hint of the problem.
For example:
[Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIDOMHTMLSelectElement.selectedIndex]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame ::
...and so on mentions nsIDOMHTMLSelectElement.selectedIndex. This particular error was caused by trying to set an out-of-bounds selectedIndex on a SELECT (drop-down) (and is an example from [1]).
XMLHttpRequest
Common types of XmlHTTPRequest bugs/abuse will usually mention either nsIXMLHttpRequest.open or nsIXMLHttpRequest.send.
Errors are specific to each function, but usually your problem is one of:
- stale references, often between documents (think (popup) windows, frames, iframes, and embeds), or the browser got confused about when it should clean up. For example, the document the XHR was created in does not exist anymore, or using an old reference to a new embedded plugin object (e.g. video)
- Use of firebug:
- If you are using firebug, you should be aware that there are older versions that did not handle XHR in frames well. Firebug would be the sole cause of the last mentioned error.
- triggering ajax from the firebug command line is sandboxed may cause this in certain cases
- trying cross-domain XHR, or using an absolute URL (verify)
- that you violated the specs or did something nonsensical, e.g. trying to send() more than once(verify) or trying to set headers after sending data (verify)
You can even look at the firefox XHR source code e.g. for send() to see what cases trigger this error.
TODO: Read:
Unsorted
Categories: Error | Internet | Webdev
