Last Comment Bug 301705 - XMLHttpRequest: 0x80040111 (NS_ERROR_NOT_AVAILABLE) [nsIXMLHttpRequest.status]
: XMLHttpRequest: 0x80040111 (NS_ERROR_NOT_AVAILABLE) [nsIXMLHttpRequest.status]
Status: RESOLVED FIXED
: qawanted
Product: Core
Classification: Components
Component: DOM (show other bugs)
: Trunk
: All All
: -- major with 3 votes (vote)
: mozilla14
Assigned To: Jonas Sicking (:sicking) No longer reading bugmail consistently
:
:
Mentors:
http://www.friesoft.nl/xmlhttpreq-tes...
: 317600 (view as bug list)
Depends on: 1167111
Blocks: 726433
  Show dependency treegraph
 
Reported: 2005-07-22 05:47 PDT by Alex Jones
Modified: 2015-05-21 08:51 PDT (History)
18 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Patch to fix (7.22 KB, patch)
2012-02-17 14:47 PST, Jonas Sicking (:sicking) No longer reading bugmail consistently
bzbarsky: review+
Details | Diff | Splinter Review
Patch -w (6.60 KB, patch)
2012-02-17 14:48 PST, Jonas Sicking (:sicking) No longer reading bugmail consistently
no flags Details | Diff | Splinter Review

Description Alex Jones 2005-07-22 05:47:53 PDT
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.9) Gecko/20050711 Firefox/1.0.5
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.9) Gecko/20050711 Firefox/1.0.5

I am frankly at a loss as to what to do to overcome this error message. This
test case is another person's work but I am experiencing it intermittently on my
own sites also. This is a non-issue in IE but I am unable to test it in Safari.

Try clicking the calendar icon and then selecting a date. Then notice the error
that is thrown. This is exactly the same error that I get intermittently on a
site  where I launch several XMLHttpRequests at once.

Reproducible: Always
Comment 1 shadytrees 2005-08-02 09:50:54 PDT
Can confirm on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4)
Gecko/20050729 Firefox/1.0+. Also, somebody on IRC also was experiencing this
problem on his page.
Comment 2 Frank Wein [:mcsmurf] 2005-08-21 03:35:14 PDT
I found Bug 238559 about this, here the testcase misses the file update.php. I'm
not sure if this is the same bug so since here a HTTP 404 error occours which
according to Bug 238559 Comment 0 it should be able to handle.
Comment 3 Alex Jones 2005-09-26 12:23:25 PDT
I am finding this is happening on www.dontstayin.com with the live chat.
Unfortunately you have to be logged in to use it but I have done my best to
debug it and it seems it is coinciding with when the server returns a 100
Continue. readyState changes to 4 too early I think, though I may be wrong.

Any devs want to take a look at this some time soon? This just doesn't happen in
IE and Opera. And in any event the error message is non-descriptive and seems to
indicate a problem in the Mozilla code.

Cheers
Comment 4 Bob Walter 2006-01-18 06:12:20 PST
We are currently developing an AJAX app, Windows XP SP2, FireFox 1.5. We are bumping into the error: "Component returned failure code: 0x80040111 (NS_ERROR_NOT_AVAILABLE) [nsIXMLHttpRequest.status]"

Here is a summary of what we are experiencing:
The app is started on a main page. That main page then opens a popup window that has an AJAX embedded frame which updates every 10 seconds. This part works great. The problem is when I want to force that frame to refresh by forcing the AJAX frame to reload. This is where the error happens. 

If I remove the line that calls for the reload and just wait 1-10 seconds for the page to refresh on its own, everything works great. It is the second call from the second popup window that is causing the problem.

The workaround I have come up with is to reload the entire page. There is about a 100ms "flash" also while the page is being reloaded, but it's really not noticeable. This 100ms flash can be much larger if there is any network anomolies and the larger delay will degrade our applicaiton.

This error is repeatable and consitent.

I hope this information helps. Please contact me directly for additonal details or code to help reproduce the problem.

  - Bob -
Comment 5 Mike Caines 2006-01-31 05:03:44 PST
This seems to be a dupliclate of bug 317600. There is a workaround posted on the other bug for those who are interested.
Comment 6 Alex Jones 2006-01-31 06:28:43 PST
I'm getting this problem intermittently without any popups/frames - just a single page.

The only other place I've seen this sort of behaviour is on www.dontstayin.com's live chat. Unfortunately you'll have to sign up to test it, but occasionally, messages you post will just get gobbled up and that exception is thrown (you can see it in the debug window just below the live chat.)

The JS they use has been processed, so it's really not that easy to debug. :(
Comment 7 Henrik Gemal 2006-05-24 06:10:42 PDT
I'm getting this problem in a extension. But weird enough only on Linux
Comment 8 timeless 2006-08-17 09:08:51 PDT
steps:
(use a trunk firefox)
1. visit live.com
2. search for: not working
3. <enter>

per doron we should return 0 not throw an exception 
Comment 9 Doron Rosenberg (IBM) 2006-08-17 10:01:12 PDT
(In reply to comment #8)
> steps:
> (use a trunk firefox)
> 1. visit live.com
> 2. search for: not working
> 3. <enter>
> 
> per doron we should return 0 not throw an exception 
> 

That is just an suggestion, probably needs some testing to see what IE does.
Comment 10 Jerry Tseng 2006-08-31 13:05:59 PDT
I got this error from a page with a <form> without a submit button. When I issued an XMLHTTPRequest, the page seemed to submit itself before the JavaScript hit the line of "XMLHTTPRequest.status==200". It makes sense of the error for the original page has then been reloaded. I solved my problem by putting "onSubmit='return false;'" in the <form> tag.
Comment 11 Danny Thorpe 2006-10-04 11:59:38 PDT
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.7) Gecko/20060909 Firefox/1.5.0.7

I'm seeing this error consistently when using xmlhttprequest within a hidden iframe and accessing the xhr.status property inside the onreadystatechanged event, when readyState goes to 4.  The xhr instance was used successfully for one download, but fails for subsequent requests.  Abort() does not clear the situation.  Releasing the instance and constructing a new xhr instance for the second request does not avoid the failure.

It's interesting to note that the readyState sequence that precedes this failure are 1, 2, 4 (failure).  No 3.  The volume of data is typically 30k or more, so in a normal transfer we see several readyState 3 events.

If touching the xhr.status or other response fields is deferred with a setTimeout of 500 ms after the readyState 4, the xhr fields are zero / empty strings.  It feels like the request was aborted, but it wasn't aborted by me.

The only workaround I've found is to force the iframe to reload when the exception occurs.  The iframe starts a new XHR connection on page load.

I can't post a link to my example quite yet.  I'll add another comment when the files go live.
Comment 12 Danny Thorpe 2007-01-19 11:44:51 PST
Here's our example app that experiences this problem:  
http://dev.live.com/mashups/trycontactscontrol

Requires a LiveID login.

Steps:  
1. sign into the control with a LiveID login
2. after signin, the control will attempt to access contacts.msn.com via XHR.  The request will succeed and the response text will be received over the wire (according to Fiddler packet sniffing), but in the xhr.readystatechange event when readyState == 4, any attempt to access xhr.status will result in the "ERROR_NOT_AVAILABLE" exception.  The xhr code is located in proxy.js, in the "v0.2" branch of the code.  The xmlHttpRequestProxy object was necessary to get Firefox to allow us to use xhr across lowered domains;  IE doesn't care.

The control currently reuses the same xmlhttprequest instance across several open/send cycles, but this does not appear to be related to the problem because switching the code to open a new xhr session for each request produces the same problem.
Comment 13 Danny Thorpe 2007-08-24 14:11:22 PDT
More info about this bug:

If the XMLHttpRequest is executed (open + send) in the context of a JavaScript call chain that originates in a window or iframe which is closing or navigating to a different domain context (like, naving to about:blank), then the XMLHttpRequest object instance will be hosed by the time it reaches readyState 4.
Comment 14 Danny Thorpe 2007-08-24 14:11:42 PDT
Still reproducible in FF 2.0.0.6
Comment 15 Luca Giachino 2008-07-20 14:52:29 PDT
I run into this issue when I log on my Windows Live Favorites (favorites.live.com)account using Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.1) Gecko/2008070206 Firefox/3.0.1. It was not happening with previous versions of Firefox. The error I get is:

Error: [Exception... "Component returned failure code: 0x80040111 (NS_ERROR_NOT_AVAILABLE) [nsIXMLHttpRequest.status]"  nsresult: "0x80040111 (NS_ERROR_NOT_AVAILABLE)"  location: "JS frame :: http://js.shared.live.com/xugouxKQdlbopFQsKLF0!Q/B/AtlasCompat.js :: anonymous :: line 61"  data: no]
Source File: http://js.shared.live.com/xugouxKQdlbopFQsKLF0!Q/B/AtlasCompat.js
Line: 61

The source line in question is:

Web.Browser._Private.cleanupFirefox = function(el,obj)
{
	var newXML;
	if (el.status==200)
	{

where I guess el is of type nsIXMLHttpRequest.
Do not know of any workaround for users facing this issue against 3rd party web sites.
Comment 16 Cees T. 2010-11-22 02:10:29 PST
http://www.bugaboodev.com/test-cameleon-interviews
throws 16 (the number of content items) of these when reloading from network:

Error: uncaught exception: [Exception... "Component returned failure code: 0x80040111 (NS_ERROR_NOT_AVAILABLE) [nsIDOMCanvasRenderingContext2D.drawImage]"  nsresult: "0x80040111 (NS_ERROR_NOT_AVAILABLE)"  location: "JS frame :: http://www.bugaboodev.com/static-portlet/ContentFlow/contentflow.js :: anonymous :: line 2"  data: no]

http://www.bugaboodev.com/static-portlet/ContentFlow/contentflow_src.js is the readable version that i "fixed" with a try...catch in the foobar function of this.content.onload = window.setTimeout(foobar, 100);
Comment 17 Cees T. 2010-11-22 02:13:13 PST
(In reply to comment #16) Sorry, that was meant for bug 574330.
Comment 18 Phil 2012-02-16 23:50:44 PST
I reproduced the error using FF10.0.2, and created a minimal test case to show it.
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Error NS_ERROR_NOT_AVAILABLE</title>
</head>
<body>
<h1>Demonstrate simple case for NS_ERROR_NOT_AVAILABLE error</h1>
<script type="text/javascript">
var x, dbg, msg;
x = new window.XMLHttpRequest(); //[Instance of] the standard built in object
dbg = typeof x.status; //works here
document.write(dbg + '<br />');
x.open("GET", "AJAX/Items.xml", true);//file exists, is accessible, is valid
dbg = 'N/A';
//dbg = typeof x.status; //fail here
msg = 'N/A';
try {
    dbg = typeof x.status; //fail here
} catch (e) {
    msg = e.message;
}
document.write(dbg + '<br />');
document.write(msg + '<br />');
</script>
</body>
</html>
Comment 19 Boris Zbarsky [:bz] (still a bit busy) 2012-02-17 07:11:45 PST
The spec used to require that behavior.  Looks like it's changed since.

Jonas, should we just remove the readyState >= LOADING check in GetStatus?
Comment 20 Jonas Sicking (:sicking) No longer reading bugmail consistently 2012-02-17 08:41:10 PST
Note that we fairly recently changed our behavior to return 0 rather than throw when .status is accessed for "early" readyStates.

So we now follow the currently specified behavior.

In other words. I think this bug is WORKSFORME.

Can someone check if behavior is correct if you download a build from http://nightly.mozilla.org
Comment 21 Boris Zbarsky [:bz] (still a bit busy) 2012-02-17 08:48:37 PST
No, this is still a problem.  We throw, on tip, NS_ERROR_NOT_AVAILABLE is state is < LOADING.
Comment 22 Jonas Sicking (:sicking) No longer reading bugmail consistently 2012-02-17 14:47:55 PST
Created attachment 598387 [details] [diff] [review]
Patch to fix
Comment 23 Jonas Sicking (:sicking) No longer reading bugmail consistently 2012-02-17 14:48:21 PST
Created attachment 598388 [details] [diff] [review]
Patch -w
Comment 24 Boris Zbarsky [:bz] (still a bit busy) 2012-02-17 19:29:57 PST
Comment on attachment 598387 [details] [diff] [review]
Patch to fix

r=me
Comment 25 Anne (:annevk) 2012-03-26 01:19:57 PDT
This never landed...
Comment 26 Jonas Sicking (:sicking) No longer reading bugmail consistently 2012-03-26 01:40:55 PDT
Thanks for the reminder. Checked in to inbound:

https://hg.mozilla.org/integration/mozilla-inbound/rev/ddb88db53379
Comment 27 Matt Brubeck (:mbrubeck) 2012-03-26 11:30:13 PDT
https://hg.mozilla.org/mozilla-central/rev/ddb88db53379
Comment 28 rahul_singhai 2013-11-21 02:15:57 PST
Hi,
Could anyone please let me know if this bug is specific to any particular version of Firefox? I'm encountering this issue on Firefox 11 and I'd like to understand if it is a known issue in this version.

Quicker response is greatly appreciated.

Thanks & Regards,
Rahul
Comment 29 Kyle Huey [:khuey] (Exited; not receiving bugmail, email if necessary) 2013-11-21 02:17:46 PST
As you can see from the Target Milestone field, this bug affects versions of Firefox before version 14.

Firefox 11 is over a year out of date and there are many known exploits that allow attackers to pwn machines running it.  You really should upgrade to a supported release.
Comment 30 rahul_singhai 2013-11-21 02:45:31 PST
Thanks Kyle,

Some of the comments indicate that this issue is same as reported by Bug 317600. However #317600 doesn't seem to be resolved yet. Could you please confirm. 

Thanks.
Comment 31 Kyle Huey [:khuey] (Exited; not receiving bugmail, email if necessary) 2013-12-02 06:41:42 PST
*** Bug 317600 has been marked as a duplicate of this bug. ***
Comment 32 Kyle Huey [:khuey] (Exited; not receiving bugmail, email if necessary) 2013-12-02 06:42:22 PST
It certainly appears to be the same problem!

Note You need to log in before you can comment on or make changes to this bug.