0x80004005 (NS ERROR FAILURE) and other firefox errors

From Helpful
Revision as of 18:15, 14 January 2011 by Helpful (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search
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
It won't be complete in any sense.
It exists to contain fragments of useful information.

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 the connection 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 docs 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


0x80004005 (NS ERROR FAILURE)

A general-purpose mozilla error, but if your scripting causes it, it usually points to one of a few specific 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

The interesting thing to be seen is 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