Note: There are a few cases of duplicates in user autocompletion which are being worked on.

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

RESOLVED FIXED in mozilla14

Status

()

Core
DOM
--
major
RESOLVED FIXED
12 years ago
2 years ago

People

(Reporter: Alex Jones, Assigned: sicking)

Tracking

(Depends on: 1 bug, Blocks: 1 bug, {qawanted})

Trunk
mozilla14
qawanted
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(2 attachments)

(Reporter)

Description

12 years ago
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

12 years ago
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.

Updated

12 years ago
Assignee: nobody → xml
Component: General → XML
Product: Firefox → Core
QA Contact: general → ashshbhatt
Version: unspecified → Trunk

Comment 2

12 years ago
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.
(Reporter)

Comment 3

12 years ago
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

Updated

12 years ago
Keywords: qawanted

Comment 4

12 years ago
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

12 years ago
This seems to be a dupliclate of bug 317600. There is a workaround posted on the other bug for those who are interested.
(Reporter)

Comment 6

12 years ago
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

11 years ago
I'm getting this problem in a extension. But weird enough only on Linux
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 8

11 years ago
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 
Assignee: xml → timeless

Comment 9

11 years ago
(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

11 years ago
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

11 years ago
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

11 years ago
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

10 years ago
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

10 years ago
Still reproducible in FF 2.0.0.6

Comment 15

9 years ago
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.
QA Contact: ashshbhatt → xml

Comment 16

7 years ago
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

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

Comment 18

6 years ago
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

6 years ago
The spec used to require that behavior.  Looks like it's changed since.

Jonas, should we just remove the readyState >= LOADING check in GetStatus?
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

6 years ago
No, this is still a problem.  We throw, on tip, NS_ERROR_NOT_AVAILABLE is state is < LOADING.
Created attachment 598387 [details] [diff] [review]
Patch to fix
Assignee: timeless → jonas
Status: NEW → ASSIGNED
Attachment #598387 - Flags: review?(bzbarsky)
Created attachment 598388 [details] [diff] [review]
Patch -w

Comment 24

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

r=me
Attachment #598387 - Flags: review?(bzbarsky) → review+

Comment 25

5 years ago
This never landed...
Thanks for the reminder. Checked in to inbound:

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

Updated

5 years ago
Blocks: 726433
Component: XML → DOM: Mozilla Extensions
QA Contact: xml → general
Target Milestone: --- → mozilla14
https://hg.mozilla.org/mozilla-central/rev/ddb88db53379
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Component: DOM: Mozilla Extensions → DOM
Product: Core → Core

Comment 28

4 years ago
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
Flags: needinfo?
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.
Flags: needinfo?

Comment 30

4 years ago
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.
Flags: needinfo?(khuey)
Duplicate of this bug: 317600
It certainly appears to be the same problem!
Flags: needinfo?(khuey)

Updated

2 years ago
Depends on: 1167111
You need to log in before you can comment on or make changes to this bug.