Problem with XmlHttpRequest (0x80040111 / nsIXMLHttpRequest.status) on several configurations

I've still got the problem.
I can't find why.

Hi,

I've designed a bookmark in Ajax / PHP that I will put soon on
sourceforge.net.
But I've got an very tricky bug.
I try it on some computers with Internet Explorer/Windows, Firefox
1.07/Linux, Firefox 1.5/Linux, Firefox 1.5/Windows and Firefox 1.5/Mac,
Safari/Mac.
It works perfectly on a lot of configurations but, on some PC with
Firefox 1.5/Windows (not all), the Javascript code with XmlHttpRequest
don't work at all and I've got this message when I refresh the webpage
:
--------------------------------------------------------------------------------------
"Erreur : [Exception... "Component returned failure code: 0x80040111
(NS_ERROR_NOT_AVAILABLE) [nsIXMLHttpRequest.status]" nsresult:
"0x80040111 (NS_ERROR_NOT_AVAILABLE)" location: "JS frame ::
http://someWebServer/BookmarkAjax/js/requestor.js :: anonymous :: line
52" data: no]
Fichier source : http://someWebServer/BookmarkAjax/js/requestor.js
Ligne : 52"
--------------------------------------------------------------------------------------

Here is the source :
--------------------------------------------------------------------------------------
"function getReadyStateHandler(req, responseXmlHandler) {
// Return an anonymous function that listens to the XMLHttpRequest
instance
return function () {
// If the request's status is "complete"
if (req.readyState == 4) {

// Check that a successful server response was received

L.52 >>>> if (req.status == 200) {

// Pass the XML payload of the response to the
// handler function
var debug = document.getElementById("debug");
debug.innerHTML += "<br/>" + req.status + " " + req.statusText;

responseXmlHandler(req.responseXML);

} else { ..."
--------------------------------------------------------------------------------------
This piece of source code comes from an IBM's article :
http://www-128.ibm.com/developerwork...dgr-lnxw01Ajax

It's very strange because it is working on some configurations and not
at all on others, all based on Firefox 1.5/Windows....
There's a lot of message on the web about this kind of error but I
don't find this exactly case !
I would be glad if somebody could help me.
(I can give you an access on the web application by email if you wan't
to reproduce this bug)
Thanks - Greg

Replace:
if (req.status == 200)

to:
if (req.status == 200)||(req.status == 0))

`req.status' will never be 0 (and will never be converted to it implicitly,
see ECMAScript Ed. 3, sections 11.9.1 and 11.9.1)

Thanks for your replies but no one of your suggestions works...

I'm 2 days at my parent's office and they have several PCs with windows
and Firefox 1.5.
It's almost strange because the application works on the server but
doesn't on 2 'office' PCs.

If I print the readyState like this :
-------------------------------------------
try {
document.getElementById("content").innerHTML += req.readyState +
'&nbsp;';
if (req.readyState == 4) {
if (req.status == 200) {
responseXmlHandler(req.responseXML);
} else {
alert("HTTP error: "+req.status);
}
}
} catch(e) {
alert("Exception : " + e);
}
-------------------------------------------
I've got :
- if it's working : 1 1 2 3 3 4
- if not : 1 1

And (on configuration wich it doesn't working), If I refresh the page,
I caught the exception 0x80040111 (NS_ERROR_NOT_AVAILABLE)
[nsIXMLHttpRequest.status]....

I've found the problem !!!
It's because, when I don't have param to send, I'm sending some request
in this way : "req.send(null);"
And this don't work on some configurations !!!

If I use this : "req.send('');" (with space instead of null)
It's always work !!!!

What a stupid bug !

Error: [Exception... "Component returned failure
code: 0x80040111 (NS_ERROR_NOT_AVAILABLE) [nsIXMLHttpRequest.status]"
nsresult: "0x80040111 (NS_ERROR_NOT_AVAILABLE)" location: "JS frame ::
http://www.stepnstomp.co.uk/java/ajax.js :: alertContents :: line 41"
data: no]
Source File: /java/ajax.js
Line: 41

Can someone tell me why Firefox is not working with AJax and ONLY for
one of my scripts.

the error is

Error: [Exception... "Component returned failure
code: 0x80040111 (NS_ERROR_NOT_AVAILABLE) [nsIXMLHttpRequest.status]"
nsresult: "0x80040111 (NS_ERROR_NOT_AVAILABLE)" location: "JS frame ::
http://www.stepnstomp.co.uk/java/ajax.js :: alertContents :: line 41"
data: no]
Source File: /java/ajax.js
Line: 41

the code is

Expand|Select|Wrap|Line Numbers

1.     var http_request = false;
2.      var retvars = "";
4.      function makeRequest(url, parameters, vars) {
5.          http_request = false;
6.          retvars = vars;
8.          if (window.XMLHttpRequest) { // Mozilla, Safari,...
9.              http_request = new XMLHttpRequest();
10.              if (http_request.overrideMimeType) {
11.                  http_request.overrideMimeType('text/xml');
12.                  // See note below about this line
13.              }
14.          } else if (window.ActiveXObject) { // IE
15.              try {
16.                  http_request = new ActiveXObject("Msxml2.XMLHTTP");
17.              } catch (e) {
18.                  try {
19.                      http_request = new
20.  ActiveXObject("Microsoft.XMLHTTP");
21.                  } catch (e) {}
22.              }
23.          }
25.          if (!http_request) {
26.              alert('AJAX - Giving up :( Cannot create an XMLHTTP
27.  instance');
28.              return false;
29.          }
31.        http_request.onreadystatechange = alertContents;
32.        http_request.open('POST', url, true);
33.        http_request.setRequestHeader("Content-type",
34.  "application/x-www-form-urlencoded");
35.        http_request.setRequestHeader("Content-length",
36.  parameters.length);
37.        http_request.setRequestHeader("Connection", "close");
38.        http_request.send(parameters);
40.      }
42.      function alertContents() {
44.          if (http_request.readyState == 4) {
45.              if (xmlHttp.status == 0 || http_request.status == 200) {
46.                  // Call global AJAX function
48.                  AJAX(http_request.responseText,retvars);
50.              } else {
51.                  alert('There is a problem with AJAX, please contact
52.  support.');
53.              }
54.          }
56.      }

the script is this

Expand|Select|Wrap|Line Numbers

1. #!/usr/bin/perl
3.  ######################
4.  # Set Error Trapping #
5.  ######################
7.  use CGI::Carp qw(fatalsToBrowser warningsToBrowser);
8.  use warnings;
9.  use strict;
10.  # use diagnostics;
12.  ##################
13.  # Use SQL module #
14.  ##################
15.  use sql;
17.  # Set File DSN to use
18.  $sql::DSN = "filedsn";
20.  # Read URL & Form data.
21.  my %data = &get_data();
23.  # Get Tune
24.  my @rs = &getSQL("Charts","UserID,Plays","UserID = '$data{'mp3'}'");
26.  # Update Plays
27.  $rs[0]{'Plays'}++;
28.  my $rec = &updSQL("Charts","Plays = $rs[0]{'Plays'}","UserID =
29.  '$data{'mp3'}'");
31.  my $disp = $rs[0]{'Plays'};
33.  # Build Return AJAX data
34.  my $catlist = "Content-type: text/html\n\n
35.  $disp";
37.  # Print AJAX data
38.  print $catlist;
39.  exit();
41.  ########

the script runs ok as the DB gets updated, for some reason FF is
erroring when the data is returned. It works fine in IE and the same JS
is used in other places and works in FF, so why is this script playing
up?

<https://bugzilla.mozilla.org/show_bug.cgi?id=238559>
<quote>
Mozilla calls onload() for all HTTP transactions that succeeded. The
only
time it calls onerror() is when a network error happened. Inside the
onerror
handler, accessing the status attribute results in this exception:

Error: [Exception... "Component returned failure code: 0x80040111
(NS_ERROR_NOT_AVAILABLE) [nsIXMLHttpRequest.status]" nsresult:
"0x80040111
(NS_ERROR_NOT_AVAILABLE)" location: "JS frame ::
</quote>

Moral: for Gecko XMLHttpRequest implementation you seem not allowed to
study Ajax object in onerror handler as any attempt to read its
property raise an error.

Thanks for the reply, i'm not a JS expert and alot didn't make sense to
me, but what really doesn't make sense is, the JS I wrote above is a
global file that ALL my AJAX requests use.

So this line : if (http_request.status == 200) where it is erroring is
called all the time, I'm only getting an error for 1 of my scripts.

This to me is indicating that the returned data is different to other
data returned as those requests don't give me this error.

I could understand if FireFox always errored everytime for that line,
but it doesn't, so there has to be something else going on.

It's not because the network/server is unvailable, as the script called
runs and the database gets updated.

I can't see what is different between the scripts that work and the ONE
that doesn't.

http_request = new XMLHttpRequest();
if (http_request.overrideMimeType) {
http_request.overrideMimeType('text/xml');
This is not related to your problem but you should only use
overrideMimeType and call it with 'text/xml' as the argument if your
server side application sends XML that you want to parsed into
responseXML but for some reasons can't set the HTTP response
Content-Type header itself to 'text/xml'.

Your server side code however does
# Build Return AJAX data
my $catlist = "Content-type: text/html\n\n
$disp";

if (http_request.overrideMimeType) {
http_request.overrideMimeType('text/xml');

I was thinking what does the plays link do that the votes doesn't, the
back end processing and returns are the same, then it dawned on me, aha
the play anchor not only calls the AJAX with the onclick event (as does
vote) but vote's href = "#", but plays is the URL to the MP3 file.

<a href="someFile.mp3"
onclick="scriptDoingHttpRequest();">link</a>
and someone clicks that link? But then the script would start the
request, the browser would load the href URL in the same window and any
script to process a response is gone as the document with the script is
being replaced.

It would seem to me FF has a major bug in dealing with File downloads
or especially Audio files.

I've found not only does it cause the AJAX to error but linking to
audio also breaks the "Back Button" so to speak, not in the browser
itself but in the javascript method history.back(-1).

Thanks for the reply, sorry, I'm used to linking to an audio file with
href and have never had a problem in I.E. , this FF behaviour seems
alien to me.
OK, let's call it "boring correct" or "inconveniently correct" :-)
Indeed while navigating to .mp3 file it is clear that *this content*
will not be displayed in the browser window (unlike say an image file).
Personally I don't like the way it is behaving but am more than happy
to try anything to make my site more cross browser compatible.

So I would appreciate your further assistance is that's ok.

I see you are using the span tag, does this mean I need to add somthing
like span:hover {CSS} , span:active{CSS}, span:link{CSS} etc to my CSS
file... so they behave like my anchor's do via the CSS.
This one, or just override default link behavior by returning false
from click event:
<a href="foo.html" onclick="myFunction('music.mp3');return false">

I like the above lesser than a whole separate tag for psi-links but who
cares what do I like or not? :-)
Also what would "someFunction('someMusic.mp3')" actually do to initiate
the browser to play the audio file.

Thanks for the advice.

would <a href="music.mp3" onclick="myAJAX('vars');return false"> " do
the job? open the mp3 but not add to history due to the return false?
No - because "return false" prevents the link from the default action
(navigation). It is merely equivalent of <span
onclick="myAJAX('vars')">
If i used a hidden iframe, would that still give problems with the
busted history.back(-1); issue?
I don't know about Firefox - but I know the way to know: just try it
;-)
oh and what's a psi-link ?

I suppose PSI-Links are taboo ?
PSI-Links is not really a taboo, but they have some implications on
different browsers. In your case it is really tricky because you want a
link to work as a real link (load mp3 file) and as psi-link (execute
XMLHttpRequest request). It is not a taboo by itself but it seems that
Firefox is not happy with that - so may be some other browser we don't
know yet.
I guess I caould always have <a href="#'" onlclick="doAJAX"> and the
ajax return sub does document.location.href to the mp3 file.

I suppose PSI-Links are taboo ?

I guess I caould always have <a href="#'" onlclick="doAJAX"> and the
ajax return sub does document.location.href to the mp3 file.

then it wouldn't matter as the ajax will have finished processign and
returned. as long as document.location.href to an audio file doesn't
make the page go blank/white.

I'll play with a few methods and see what works best.

bol...@hotmail.com wrote:

I suppose PSI-Links are taboo ?

PSI-Links is not really a taboo, but they have some implications on
different browsers. In your case it is really tricky because you want a
link to work as a real link (load mp3 file) and as psi-link (execute
XMLHttpRequest request). It is not a taboo by itself but it seems that
Firefox is not happy with that - so may be some other browser we don't
know yet.

I guess I caould always have <a href="#'" onlclick="doAJAX"> and the
ajax return sub does document.location.href to the mp3 file.

That would be really risky because document.location.href means that
the current script context is free to be disposed, and you don't want
it.
Also you may do not want to ugly up your solution with frames.

So I would stay with iframe if it works. I just checked it on Firefox
1.5 and it seems doesn't affect history.length. But I did not check it
through:

Personally, and I have no idea whether it is good practice, I use a
timeout function.
For example, if I'm using an XMLHttpRequest, in the
onreadystatechange() handler, when it comes to setting the
document.location.href, I'd wrap it in a timeout callback, rather than
do it directly:

------------- directly -----------
req.onreadystatechange = function {

if (req.readyState == 4) {

if (req.status == 200) {

document.location.href = ...
}
}
}
----------------------------------
------------- timeout -----------
req.onreadystatechange = function {

if (req.readyState == 4) {

if (req.status == 200) {

setTimeout (function () {

document.location.href = ...;
}, 100); // in 100 ms.
}
}
}
----------------------------------

That's it.
Has anyone any comment on whether this is good or bad?

Arnaud Diederen (aundro wrote:

Personally, and I have no idea whether it is good practice, I use a
timeout function.
For example, if I'm using an XMLHttpRequest, in the
onreadystatechange() handler, when it comes to setting the
document.location.href, I'd wrap it in a timeout callback, rather than
do it directly:

------------- directly -----------
req.onreadystatechange = function {

if (req.readyState == 4) {

if (req.status == 200) {

document.location.href = ...
}
}
}
----------------------------------
------------- timeout -----------
req.onreadystatechange = function {

if (req.readyState == 4) {

if (req.status == 200) {

setTimeout (function () {

document.location.href = ...;
}, 100); // in 100 ms.
}
}
}
----------------------------------

That's it.
Has anyone any comment on whether this is good or bad?

Considering that setTimeout() is unnecessary because the request is
asynchronous already; that using function object references for its
first argument is error-prone because not backwards compatible; that
document.location is deprecated ever since in favor of window.location;
that XMLHttpRequest is a host object that is not cross-browser and not
backwards compatible; that you do not feature-test anything before,
while a simple hyperlink, which in contrast does not depend on support
for client-side scripting, will do exactly the same _better_: it is BAD
-- Broken As Designed.

Arnaud Diederen (aundro wrote:

Personally, and I have no idea whether it is good practice, I use a
timeout function.
For example, if I'm using an XMLHttpRequest, in the
onreadystatechange() handler, when it comes to setting the
document.location.href, I'd wrap it in a timeout callback, rather than
do it directly:
[...]
That's it.
Has anyone any comment on whether this is good or bad?
Considering that setTimeout() is unnecessary because the request is
asynchronous already;

I don't see your point. The request is asynchronous; that I know
already (though I can force it to be synchronous, and you couldn't
tell by looking at this code), but that's irrelevant, since the code I
posted was callback code.
that using function object references for its
first argument is error-prone because not backwards compatible;
I didn't know that
that
document.location is deprecated ever since in favor of
window.location;
Indeed, I use window.location, but that was just for the example,
sorry for the mistake.
that XMLHttpRequest is a host object that is not cross-browser and not
backwards compatible;
You seem to pay a lot of attention to looking backwards. What about
using the actual features when they are available? Why couldn't I?
that you do not feature-test anything before,
Indeed, I didn't, that's just an example
while a simple hyperlink, which in contrast does not depend on support
for client-side scripting, will do exactly the same _better_: it is BAD
-- Broken As Designed.

Thomas 'PointedEars' Lahn wrote:

Arnaud Diederen (aundro wrote:

> Personally, and I have no idea whether it is good practice, I use a
> timeout function. [...]
> [...]
> ------------- timeout -----------
> req.onreadystatechange = function {
>
> if (req.readyState == 4) {
>
> if (req.status == 200) {
>
> setTimeout (function () {
>
> document.location.href = ...;
> }, 100); // in 100 ms.
> }
> }
> }
> ----------------------------------
>
> That's it.
> Has anyone any comment on whether this is good or bad?
Considering that setTimeout() is unnecessary because the request is
asynchronous already; that using function object references for its
first argument is error-prone because not backwards compatible; that
document.location is deprecated ever since in favor of window.location;
that XMLHttpRequest is a host object that is not cross-browser and not
backwards compatible; that you do not feature-test anything before,
while a simple hyperlink, which in contrast does not depend on support
for client-side scripting, will do exactly the same _better_: it is BAD
-- Broken As Designed.

Wow!

Thomas 'PointedEars' Lahn just cancelled AJAX.

I did not such thing.
Poor people of the world.

Thomas 'PointedEars' Lahn <Po*********@web.de> writes:

Arnaud Diederen (aundro wrote:

Personally, and I have no idea whether it is good practice, I use a
timeout function.
For example, if I'm using an XMLHttpRequest, in the
onreadystatechange() handler, when it comes to setting the
document.location.href, I'd wrap it in a timeout callback, rather than
do it directly:
[...]
That's it.
Has anyone any comment on whether this is good or bad? Considering that setTimeout() is unnecessary because the request is
asynchronous already;

I don't see your point. The request is asynchronous; that I know
already (though I can force it to be synchronous, and you couldn't
tell by looking at this code), but that's irrelevant, since the code I
posted was callback code.

What are you trying to achieve with setTimeout(), that is, asynchronous (but
not threaded) evaluation/call, if the request is asynchronous already? The
event listener will not be called before a response is received, and the
`location' object will not be touched if the response status is different
than 200 (OK). What you achieve with setTimeout() here is merely delaying
evaluation/call for another 100 milliseconds. I fail to see any point in
that.

that using function object references for its
first argument is error-prone because not backwards compatible;

I didn't know that

Solution: Either use a string value, or do a feature test and choose a
calling method, or change your described requirements instead. BTW: your
function expressions are missing an argument list "`(...)'" and are
therefore none, but I assume that is because of the example, too.

that XMLHttpRequest is a host object that is not cross-browser and not
backwards compatible;

You seem to pay a lot of attention to looking backwards. What about
using the actual features when they are available? Why couldn't I?

Of course you could, and you should iff they are required. However, a
previous feature test is required on runtime or you will write a script
that will _break_, not only one that does not work.

while a simple hyperlink, which in contrast does not depend on support
for client-side scripting, will do exactly the same _better_: it is BAD
-- Broken As Designed.

Ok: say you're in "myFrame", you issue an XMLHttpRequest (or
whatever substitute, depending on the browser) *from within* that
frame and, when you get the response, you find out(1) that you should
change "myFrame"'s location (reload it or whatever).

How do you do that within FF without triggering the exception the OP
just described?
My solution is (sorry, I realize I was not clear at first): getting
another frame (say "myRootFrame"), and setting a timeout function in
"myRootFrame" that will change "myFrame"'s location.
What is your solution? I don't understand it.

Unfortunately, without further information from the OP ISTM that it is not
possible to devise a real solution to the problem. He thinks the cause of
this non-reproducible problem is req.send(null), but I still doubt that.

As for your problem, which does not strike me to have much to do with that
of the OP, you just leave the setTimeout() out, use `window.location'
instead of `document.location', and do the feature tests on runtime before.
Everything else is fine with your solution to _your_ problem to me.
However, your problem does not strike me being one in the first place
because

<a href="...">...</a>

will do exactly the same as your example does and it does not depend on
support for client-side scripting or any host object at all. Even if
we are talking about conditional navigation, this can be done better
server-side.
(1) I specified "you find out" because you might not need to refresh it.

Arnaud Diederen (aundro wrote:

Thomas 'PointedEars' Lahn <Po*********@web.de> writes:

Arnaud Diederen (aundro wrote:
Personally, and I have no idea whether it is good practice, I use a
timeout function.
For example, if I'm using an XMLHttpRequest, in the
onreadystatechange() handler, when it comes to setting the
document.location.href, I'd wrap it in a timeout callback, rather than
do it directly:
[...]
That's it.
Has anyone any comment on whether this is good or bad?
Considering that setTimeout() is unnecessary because the request is
asynchronous already;
I don't see your point. The request is asynchronous; that I know
already (though I can force it to be synchronous, and you couldn't
tell by looking at this code), but that's irrelevant, since the code I
posted was callback code.

What are you trying to achieve with setTimeout(), that is, asynchronous (but
not threaded) evaluation/call, if the request is asynchronous already? The
event listener will not be called before a response is received, and the
`location' object will not be touched if the response status is different
than 200 (OK). What you achieve with setTimeout() here is merely delaying
evaluation/call for another 100 milliseconds. I fail to see any point in
that.

Ok, I'll say it again then. The scenario is:

Imagine an application with many [i]frames:

+--------------+
+--------------+
|myRoot |
| |
| +-------+|
| |mySub ||
+-----+-------++
- Now, Joe user clicks on a button that is inside "mySub". That click
will use an asynchronous call to the server to perform some
action (using an XMLHttpRequest).

- The server replies that the frame "mySub" needs to be
refreshed/changed. It *might* be unnecessary to reload "mySub", but
for example, let's say "mySub" needs to be refreshed.

- The request was issued from "mySub", and the callback function for
the onreadystatechange is a function that sits in the scope of
"mySub". From that function, if you do a
`window.location.href = "http://..."', FireFox will complain, throwing
this weird error that is the _title_ of this thread.

==> So: you cannot set the href of the location (or, in other words:
request that a new document is loaded) of the window from the
onreadystatechange handler of an XMLHttpRequest that was performed
from that window.

My solution to this is: I setTimeout() in "myRoot"'s scope, *delaying
the loading of the new document after I have had the time to leave the
onreadystatechange handler of the request*

Solution: Either use a string value, or do a feature test and choose a
calling method, or change your described requirements instead. BTW: your
function expressions are missing an argument list "`(...)'" and are
therefore none, but I assume that is because of the example, too.
Yes, Thomas, yes..

that XMLHttpRequest is a host object that is not cross-browser and not
backwards compatible;
You seem to pay a lot of attention to looking backwards. What about
using the actual features when they are available? Why couldn't I?

Of course you could, and you should iff they are required. However, a
previous feature test is required on runtime or you will write a script
that will _break_, not only one that does not work.

I _know_ that, thanks

while a simple hyperlink, which in contrast does not depend on support
for client-side scripting, will do exactly the same _better_: it is BAD
-- Broken As Designed.
Ok: say you're in "myFrame", you issue an XMLHttpRequest (or
whatever substitute, depending on the browser) *from within* that
frame and, when you get the response, you find out(1) that you should
change "myFrame"'s location (reload it or whatever).

How do you do that within FF without triggering the exception the OP
just described?
My solution is (sorry, I realize I was not clear at first): getting
another frame (say "myRootFrame"), and setting a timeout function in
"myRootFrame" that will change "myFrame"'s location.
What is your solution? I don't understand it.

Unfortunately, without further information from the OP ISTM that it is not
possible to devise a real solution to the problem. He thinks the cause of
this non-reproducible problem is req.send(null), but I still doubt that.

Me too, as explained before.

As for your problem, which does not strike me to have much to do with that
of the OP, you just leave the setTimeout() out, use `window.location'
instead of `document.location', and do the feature tests on runtime before.
Everything else is fine with your solution to _your_ problem to me.
However, your problem does not strike me being one in the first place
because

<a href="...">...</a>
Please, understand and consider the scenario above.

will do exactly the same as your example does and it does not depend on
support for client-side scripting or any host object at all. Even if
we are talking about conditional navigation, this can be done better
server-side.

(1) I specified "you find out" because you might not need to refresh it.

Pardon? What is to be refreshed? Are you trying to say you want to check
if a resource is new and refresh its display only if that applies? If yes,
caches and cache control have been invented for that already.