422,922 Members | 2,127 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 422,922 IT Pros & Developers. It's quick & easy.

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

P: n/a
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

Dec 17 '05 #1
Share this Question
Share on Google+
42 Replies


P: n/a
I've still got the problem.
I can't find why.

Jan 16 '06 #2

P: n/a
Greg wrote:
I've still got the problem.
I can't find why.

Have you tried if (req.status && req.status == 200)?

--
Ian Collins.
Jan 16 '06 #3

P: n/a
VK

Greg wrote:
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))

If it helps, ask my why (and you owe me a bottle of Bordeaux of a good
year :-D

Jan 16 '06 #4

P: n/a
VK wrote:
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), there is no such status
code in HTTP and the Microsoft IXMLHttpRequest interface reference, from
which Gecko's XMLHttpRequest derives, does not suggest the property could
hold this value or a value convertible to 0 ever. Therefore, the approach
Ian suggested is, unfortunately unsurprisingly, more reasonable than this.

<URL:http://msdn.microsoft.com/library/en-us/xmlsdk/html/f6de15fc-72e9-418e-b275-d94b0b2045de.asp>
<URL:http://xulplanet.com/references/objref/XMLHttpRequest.html>
PointedEars
Jan 16 '06 #5

P: n/a
VK

Thomas 'PointedEars' Lahn wrote:
`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)


I'm wondering what do you have to say about Windows issues if you
stated several times that you are under Linux? Unless you have Windows
installed as well ? Are we cheating? ;-)

FYI: using IXMLHTTPRequest for local (file:\\) files under Windows / IE
6.x returns status 0 is success. So if the said bookmarklet used both
for local and remote files, it may cause a hard to catch erratic
behavior, because for local files status will never be 200 - despite
the file itself will be perfectly loaded.
Also as you cannot set Content-Type for file:\\ (at least for Windows),
XML files loaded from harddrive do no trig XML parser (as it reacts on
Content-Type only, not on file extension), so for your local .xml files
responseXML is always "", only responseText is OK. That is another
erratic behavior which may draw you crazy because the same file may
parse just fine from server and "disappear" as soon as saved as local
file.

ECMAScript Ed. 3 doesn't know about it which is not a suprise of any
kind.

P.S. It is not the fact that it is the OP's problem, but something to
start with. Another explanation can be in Firefox' bookmarlet security
mechanics. We shall move on it if the above suggestion will fail.

Jan 16 '06 #6

P: n/a
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 will try to debug this piece of code during the day. If I find a
solution, I'll come back to you.

By the way, this address book project is now on SourceForge :
http://sourceforge.net/projects/gcontact
But, for now, screens are only available in French.

Jan 18 '06 #7

P: n/a
VK

Greg wrote:
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]....


The list line sounds really close to
<http://ajaxtoolbox.com/forum/viewtopic.php?p=102&sid=f2be51bc80038174198e5f52e7 d91554>

Does it help anyhow if you do not use any req properties in
else-brunch?

Jan 18 '06 #8

P: n/a
No... Don't use req properties in else brunch doesn't help...
Thank for the link, I'm looking if it can help me...

Jan 18 '06 #9

P: n/a
Wait !
Now, some HttpRequests are working !
But not on all functions on my application...
It's strange but now, I can look for differences between functions wich
are working and thoses which don't !
I think I will soon debug that problem !

Cool.

Jan 18 '06 #10

P: n/a
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 !

Jan 18 '06 #11

P: n/a
VK

Greg wrote:
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 !


It is not really a bug AFAIK, but a difference between IXMLHTTPRequest
(Microsoft) and XMLHttpRequest (others). At least all MSDN samples seem
to go with "" and all Mozilla samples with null. Never studied it
profoundly though.

Jan 18 '06 #12

P: n/a
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 = "";
  3.  
  4. function makeRequest(url, parameters, vars) {
  5. http_request = false;
  6. retvars = vars;
  7.  
  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. }
  24.  
  25. if (!http_request) {
  26. alert('AJAX - Giving up :( Cannot create an XMLHTTP
  27. instance');
  28. return false;
  29. }
  30.  
  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);
  39.  
  40. }
  41.  
  42. function alertContents() {
  43.  
  44. if (http_request.readyState == 4) {
  45. if (xmlHttp.status == 0 || http_request.status == 200) {
  46. // Call global AJAX function
  47.  
  48. AJAX(http_request.responseText,retvars);
  49.  
  50. } else {
  51. alert('There is a problem with AJAX, please contact
  52. support.');
  53. }
  54. }
  55.  
  56. }
the script is this
Expand|Select|Wrap|Line Numbers
  1. #!/usr/bin/perl
  2.  
  3. ######################
  4. # Set Error Trapping #
  5. ######################
  6.  
  7. use CGI::Carp qw(fatalsToBrowser warningsToBrowser);
  8. use warnings;
  9. use strict;
  10. # use diagnostics;
  11.  
  12. ##################
  13. # Use SQL module #
  14. ##################
  15. use sql;
  16.  
  17. # Set File DSN to use
  18. $sql::DSN = "filedsn";
  19.  
  20. # Read URL & Form data.
  21. my %data = &get_data();
  22.  
  23. # Get Tune
  24. my @rs = &getSQL("Charts","UserID,Plays","UserID = '$data{'mp3'}'");
  25.  
  26. # Update Plays
  27. $rs[0]{'Plays'}++;
  28. my $rec = &updSQL("Charts","Plays = $rs[0]{'Plays'}","UserID =
  29. '$data{'mp3'}'");
  30.  
  31. my $disp = $rs[0]{'Plays'};
  32.  
  33. # Build Return AJAX data
  34. my $catlist = "Content-type: text/html\n\n
  35. $disp";
  36.  
  37. # Print AJAX data
  38. print $catlist;
  39. exit();
  40.  
  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?

Jan 20 '06 #13

P: n/a
VK

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

the script is this
Expand|Select|Wrap|Line Numbers
  1. #!/usr/bin/perl
  2.  ######################
  3.  # Set Error Trapping #
  4.  ######################
  5.  use CGI::Carp qw(fatalsToBrowser warningsToBrowser);
  6.  use warnings;
  7.  use strict;
  8.  # use diagnostics;
  9.  ##################
  10.  # Use SQL module #
  11.  ##################
  12.  use sql;
  13.  # Set File DSN to use
  14.  $sql::DSN = "filedsn";
  15.  # Read URL & Form data.
  16.  my %data = &get_data();
  17.  # Get Tune
  18.  my @rs = &getSQL("Charts","UserID,Plays","UserID = '$data{'mp3'}'");
  19.  # Update Plays
  20.  $rs[0]{'Plays'}++;
  21.  my $rec = &updSQL("Charts","Plays = $rs[0]{'Plays'}","UserID =
  22.  '$data{'mp3'}'");
  23.  my $disp = $rs[0]{'Plays'};
  24.  # Build Return AJAX data
  25.  my $catlist = "Content-type: text/html\n\n
  26.  $disp";
  27.  # Print AJAX data
  28.  print $catlist;
  29.  exit();
  30.  ########

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?


This may (or may not) help:

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

Jan 20 '06 #14

P: n/a
> This may (or may not) help:

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

Jan 21 '06 #15

P: n/a
VK

bo****@hotmail.com wrote:
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.


Exactly the same script on exactly the same page produces different
results on different machines. Possible explanations:

1. Act of God
Always possible but let's us keep it as the last ressort.

2. Difference in UA.
What is *exactly* the Firefox version on the machine of problem?
What is *exactly* the Firefox version on a machine w/o problem?

3. Difference in OS
What is *exactly* the OS (including installed SP) on the machine of
problem?
What is *exactly* the OS (including installed SP) on a machine w/o
problem?

4. Difference in network connection
Does the machine of problem have *any* difference in network connection
in comparison with other machines.

Also why two different names here (xmlHttp and http_request)?
if (http_request.readyState == 4) {
if (xmlHttp.status == 0 || http_request.status == 200) {

Jan 21 '06 #16

P: n/a


bo****@hotmail.com wrote:

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";


so obviously you don't want to send XML but rather HTML (text/html).
Calling http_request.overrideMimeType('text/xml') then is kind of
nonsense and harmful as XMLHttpRequest now expects XML and tries to
parse the response body as XML to build responseXML. That is a wasteful
attempt if you send text/html so consider removing that overrideMimeType
call.


--

Martin Honnen
http://JavaScript.FAQTs.com/
Jan 21 '06 #17

P: n/a
thanks for the replies,

To answer a few questions which might help.

1. They are not separate machines, it's the same machine, version of FF
(v1.0.7).
2. http_request = new XMLHttpRequest();
if (http_request.overrideMimeType) {
http_request.overrideMimeType('text/xml');

thanks for the heads up, the code for making the AJAX request is code
i've used supplied on a forum like this one, so unfortunately it's a
bit of a cargo cult code senario, i know - you don't have to say, but
part of the beauty of the internet is being able to share code so those
not clever enough to write it themselves can still get the benefits,
well that's my excuse!

i can see what your saying though, I removed it and it hasn't helped
though, it's just bizzare how i click the vote for tune link, it calls
the AJAX, sends the request, gets the returned HTML/TEXT and updates
the DOM, cushtie!, but the same thing for the play.cgi gives that
error, I do the same process in both scripts (obviously one updates
votes and the other plays on the DB) but apart from that there is no
difference so why is it crashing in FF for this one script, FF works
fine for the other parts that call the same AJAX script, which is why
i'm scratching my head, completely baffled.

Jan 22 '06 #18

P: n/a
OK - I've worked out the problem, don't know how to fix it , if there
is a fix or if it's a major bug in FireFox, but here goes....

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.

To test my theory I put the href for the votes link to the mp3 file
also and I got the same error in the java console and the DOM didn't
update with the returned TEXT/HTML.

So I conclude that what ever firefox does to get an mp3 file (or maybe
any file) is trashing the AJAX http request, the ajax is running the
request, the file starts to download and that somehow is corrupting the
HTTP ajax request and causing the error.

Can some one try this themselves and confirm the same problem?, does
this make sense to anyone, can it be fixed, is it a bug in FF.

well at least i now know why it is happening, i guess it's a start - lol

Jan 22 '06 #19

P: n/a


bo****@hotmail.com wrote:

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.


So what exactly do you have,
<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.
What exactly do you have, a link with a target attribute?

--

Martin Honnen
http://JavaScript.FAQTs.com/
Jan 22 '06 #20

P: n/a
Wow - thanks for the quick reply, there is no target as that would
leave a blank window open. Is the anchor changing the page location so
it's trashing the http request.
<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.


that statement is the scenario i have, and it works fine in I.E. , is
it to do with the way FF gets <anchors> to audio files, does firefox
trash the page for ANY anchor but I.E. doesn't?

how can I get round this without loading the mp3 into a new page and
leaving an empty window open?

Jan 22 '06 #21

P: n/a
I have a similat problem I believe. I'm doing something like this in
an iframe
parent.document.getElementById("landmark").src="la ndmark.php?user=test";
parent.makeRequest();

basically a user makes a change in the iframe, and the iframe calls the
parent window to refresh itself using an ajax call. when I started the
makeRequest() AJAX call before change the SRC I got the ns_error. Now
that I've changed the order, w/ the SRC first and AJAX 2nd the error
went away.

Jan 23 '06 #22

P: n/a
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).

If you are on a page, click a link to another page with audio links on
it, click the audio link and then click the button provided to "GO
BACK", the browser tries to go back but just reloads the page you are
currently on. It's doesn't even reload the audio file, which
technically it should with the way the browser is behaving.

I'm having to go through my website and hardcode URLs on certain menu
option because I tried to use Internet standards and not break the
"back button", so issued history.back(-1) but because of the pathetic
way FF handles a URL to MP3's , being browser/user friendly is not
possible.

Why FF see's a hyperlink to an audio file as if the browser has gone to
another page is beyond me, because it hasn't. All I know is this is the
biggest reason i've ever seen to not use FF.

As i run a record music site and the way FF handles audiofiles, FF has
to be my biggest nightmare!

click an audio file in FF and bang, there goes the history.back(-1)
method, there goes your AJAX request, i'm sure there are more things it
trashes also, what a nightmare.

Anyone got any ideas as to a way to deal with this?

Jan 24 '06 #23

P: n/a
VK

bo****@hotmail.com wrote:
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).


<A href > - unless default action is cancelled - means *navigation* to
the resource indicated by href. Therefore FF behavior is completely
correct.
It would help to understand you interface:
<a href="someMusic.mp3" onclick="someFunction()">
- does it mean that you are loading mp3 file to the browser window
*and* executing someFunction() ? That doesn't have too much sense but
in any case FF is still totally right.

<span onclick="someFunction('someMusic.mp3')">Clip 001</span> is
universally correct (with MP3 player object on the page you handle over
your someFunction).

Jan 24 '06 #24

P: n/a
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.

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.

Also what would "someFunction('someMusic.mp3')" actually do to initiate
the browser to play the audio file.

Are you saying I should have an audio player object embeded in the
page, and not use the, as I thought "universally accepted way" of
allowing the user to have their own, default audio player play the
music? - in my case I choose RealPlayer to play audio files, others use
WinAmp, some Windows Media Player.

Or is there an object that you can have that is a mechanism to pass the
audio file to the users "default" audio player.

Any help understanding the correct method and implementing it, is much
appreciated.

Jan 24 '06 #25

P: n/a
VK

bo****@hotmail.com wrote:
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.


It is really a whole separate question of playing / downloading media
files from a web-page. Seems simple like a moo-cow, but small details
give you real hell as soon as you try to support more than one browser.

Yes, I would use <object><embed> combo to activate default player for
the current system. But <object><embed> combo by itself is a whole
science to layout it in a "no-crash" way.

Really if you already have a working solution for IE I would try adjust
it somehow for Firefox and hell on standards.
How about creating a hidden iframe named say "hellOnThem" and dump MP3
files into it?
<a href="music.mp3" target="hellOnThem" onclick="myFunction()">
This dirty trick helped me once with Netscape, but a while ago.

Jan 24 '06 #26

P: n/a
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?

If i used a hidden iframe, would that still give problems with the
busted history.back(-1); issue?

oh and what's a psi-link ?

Jan 24 '06 #27

P: n/a
VK

bol...@hotmail.com wrote:
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 ?


My personal donation to the computer lingo :-)

"HTML link used to trig JavaScript execution while staying on the same
page"

Feel free to use the above description, "pseudo-link", > "psi-link" or
coin your own term :-)

Jan 24 '06 #28

P: n/a
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.

Thanks for all the help.

Jan 24 '06 #29

P: n/a
VK

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:

<iframe name="foo"></iframe>
<a href="03.mp3" target="foo" onclick="alert(history.length)">Link</a>
<a href="02.mp3" target="foo" onclick="alert(history.length)">Link</a>

Jan 24 '06 #30

P: n/a
bo****@hotmail.com wrote:
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.


People have been doing this for years without AJAX by using a flash
movie in the page. Javascript interaction with flash is excellent and
flash is almost universally available.
<url:http://www.google.com/search?hl=en&q=flash+mp3+player+javascript>

Jan 24 '06 #31

P: n/a
"VK" <sc**********@yahoo.com> writes:
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?

Best regards,
Arnaud
Jan 25 '06 #32

P: n/a
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.
PointedEars
Jan 25 '06 #33

P: n/a
VK

Thomas 'PointedEars' Lahn wrote:
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.


Wow!

Thomas 'PointedEars' Lahn just cancelled AJAX. Poor people of the world.

Jan 25 '06 #34

P: n/a
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.
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.


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.

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

Arnaud
Jan 25 '06 #35

P: n/a
VK wrote:
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.


Poor VK who still does not understand.
PointedEars
Jan 25 '06 #36

P: n/a
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.
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.


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.

Please elaborate.
PointedEars
Jan 25 '06 #37

P: n/a
Thomas 'PointedEars' Lahn <Po*********@web.de> writes:
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.


This is not a matter of bandwidth, but a matter of "losing some state"
in which the application was.
You see, I'm developping a geographic tool (map navigation, usage of
resource directories to find map features),
which is very dynamic, and requires quite a lot of JavaScript.
I could same the current state of a given window, reload this window
(taking advantage of caching), and then restore the previous state,
but this is not appriopriate in all cases.

Arnaud
Jan 25 '06 #38

P: n/a
Well my solution was the non-standards easy option.

hidden iframe 1px by 1px and the href to the mp3 targets the iframe.

which technically makes it no longer a PSI-Link ;-)

the AJAX runs fine and returns as expected.

and even the browser back button doesn't break.

I still concider it a bug in FF (the way it handles audio file links is
undesireable).

being technically correct isn't always the desired result!

but of course if FF has been made to handle these types of links in
this manner then FF is doing what it's been told, bug by design!

thanks to everyone who has helped and given their advice, now I have a
working page which is cross-browser compatible.

kind regards,

Craig.

Jan 27 '06 #39

P: 1
Hi!

In the context of this problem, i have another..

I have a file, for example index.php containing the AJAX code, a link to make the request to a page test.php and a div or span to put the result.

Inside test.php i have:

------------------ teste.php ---------------
<?

header('Content-type: text/plain; charset=ISO-8859-1');
?>

<script>
alert('hello');
</script>
-----------------------------------------

The problem is that it doent execute the javascript code when i make the request.

Does anyone knows how i solve this problem?

Thanks :confused:
Feb 13 '06 #40

P: n/a
Did you find a solution for the error 0x80040111
(NS_ERROR_NOT_AVAILABLE) ?!
Im having the same problem...

Feb 15 '06 #41

P: 1
I had the same problem and this advice fixed the issue. I was making the AJAX calls from an onsubmit event on a form like this...

<form onsubmit="doSubmit(this);">...</form>

Then, I had a function that ran the AJAX like this...

function doSubmit(f) {
// Read in the form value
// Make the AJAX call
// Do some processing...
return false;
}

This caused that funky error. To correct it, I simply changed the onsubmit event attribute to this...

<form onsubmit="doSubmit(this); return false;">...</form>

Problem solved... a little strange that it works this way, but at least it was fixable.
Apr 25 '06 #42

P: 1
I had exactly the same problem on a site I'm designing - worked fine in IE but got this error in FireFox. I found the solution but it was very arcane.

The XMLHTTPrequest was fired from a button. When the code read <button onclick = "javascript:somefunction();">Click</button> the problem happened because FF made at least two attempts to fire the XMLHTTPrequest.

By changing the code to <input type = 'button' value = 'Click' onclick = "javascript:somefunction();"></input>, the problem resolved itself.

I hope this spares someone the grief I had.
May 5 '06 #43

This discussion thread is closed

Replies have been disabled for this discussion.