301705 - XMLHttpRequest: 0x80040111 (NS_ERROR_NOT_AVAILABLE) [nsIXMLHttpRequest.status]

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[Alex Jones]

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]

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

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]

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]

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]

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]

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]

I'm getting this problem in a extension. But weird enough only on Linux

Comment 8

[timeless]

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

(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]

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]

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]

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]

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]

Still reproducible in FF 2.0.0.6

Comment 15

[Luca Giachino]

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

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

(In reply to comment #16) Sorry, that was meant for bug 574330.

Comment 18

[Phil]

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 [:bzbarsky]]

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]

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 [:bzbarsky]]

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]

Attachment: Patch to fix

Comment 23

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Attachment: Patch -w

Comment 24

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 598387 [details] [diff] [review]
Patch to fix

r=me

Comment 25

[Anne (:annevk)]

This never landed...

Comment 26

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Thanks for the reminder. Checked in to inbound:

https://hg.mozilla.org/integration/mozilla-inbound/rev/ddb88db53379

Comment 27

[Matt Brubeck (:mbrubeck)]

https://hg.mozilla.org/mozilla-central/rev/ddb88db53379

Comment 28

[rahul_singhai]

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 (Exited; not receiving bugmail, old account, do not use)]

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]

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 32

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

It certainly appears to be the same problem!