0x80004005 (NS ERROR FAILURE) and other firefox errors

This article is protected, probably because it was spammed repeatedly. To edit protected pages, bug me to try to make the spam protection better, or register and contact me.

📃 These are primarily notes, intended to be a collection of useful fragments, that will probably never be complete in any sense.

0x80004005 (NS ERROR FAILURE)

...is a very general-purpose error (not even just in mozilla)

When scripting triggers it, then the error also usually points to a more specific problem. To figure out what failed, look for the origination function.

For example, in:

[Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE)
[nsIDOMHTMLSelectElement.selectedIndex]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" 
location: "JS frame ::

...it's nsIDOMHTMLSelectElement.selectedIndex, a good thing to search for.

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]).

nsIXMLHttpRequest.*

XmlHTTPRequest-related errors will usually occur in either nsIXMLHttpRequest.open or nsIXMLHttpRequest.send

The specific error is often the best indication of the problem.

The actual problem to fix (often in the scripting logic) is regularly 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, if the document an XHR was created in does not exist anymore, or using an old reference to a new embedded plugin object (e.g. video)

• 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)

• 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 XHR from the firebug command line is sandboxed, and may cause this in certain cases

• trying cross-domain XHR, or using an absolute URL (verify)

You could even look at the Firefox XHR source code, e.f. for send(), to see what cases trigger this error.

TODO: Read:

• http://www.fleegix.org/articles/2006/10/21/xmlhttprequest-and-0x80004005-ns_error_failure-error

0x80040111 (NS ERROR NOT AVAILABLE)

Reason

The direct reason is a missing object attribute - you are probably expecting an attribute to be present on an object when it is not always.

When this happens around an XMLHttpRequest, one of the likeliest causes around is an onerror handler that tries to read the result's status (or statusText).

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 accessing it must (!) then lead to an exception raise.

In other words, this error is then correct behaviour.

This error is more specific to Gecko (Firefox, Mozilla) because it adheres to those specs closer to the letter in this regard. So for portable code you want to adhere to that always.

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 before receiving a response at all, e.g. because of some connectivity problem

• a request was broken off on the client (possibly specifically because of the next reason:)

• an ongoing AJAX call is canceled by page unload
  • (another 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, and you can't or don't want to remove the status check, the simplest workaround is usually to wrap this read in a try-catch, since the error handling would often be "oh well, forget it then" code anyway.

If you use XHR from some library (and implicitly its error handler), it's a bug in that library that has not yet been fixed, so search around for a newer version, bother its creator, and/or fix it yourself.

If such a library it lets you write your own callbacks and its documentation didn't warn you about this, you might wish to bother them about that - it's nice to be able to have code that can react to this if and when it chooses to.

When caused by the form submission problem, you can usually avoid it. 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