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

[Jambalaya]

Re: Problem with XmlHttpRequest (0x80040111 / nsIXMLHttpReque st.status) on several configurations

bollax@hotmail. com wrote:[color=blue]
> I suppose PSI-Links are taboo ?
>
> I guess I caould always have <a href="#'" onlclick="doAJA X"> and the
> ajax return sub does document.locati on.href to the mp3 file.
>
> then it wouldn't matter as the ajax will have finished processign and
> returned. as long as document.locati on.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.[/color]

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+playe r+javascript>

[Arnaud Diederen]

Re: Problem with XmlHttpRequest (0x80040111 / nsIXMLHttpReque st.status) on several configurations

"VK" <schools_ring@y ahoo.com> writes:
[color=blue]
> bol...@hotmail. com wrote:[color=green]
>> I suppose PSI-Links are taboo ?[/color]
>
> 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.
>[color=green]
>> I guess I caould always have <a href="#'" onlclick="doAJA X"> and the
>> ajax return sub does document.locati on.href to the mp3 file.[/color]
>
> That would be really risky because document.locati on.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:[/color]

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
onreadystatecha nge() handler, when it comes to setting the
document.locati on.href, I'd wrap it in a timeout callback, rather than
do it directly:

------------- directly -----------
req.onreadystat echange = function {

if (req.readyState == 4) {

if (req.status == 200) {

document.locati on.href = ...
}
}
}
----------------------------------


------------- timeout -----------
req.onreadystat echange = function {

if (req.readyState == 4) {

if (req.status == 200) {

setTimeout (function () {

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

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

Best regards,
Arnaud

[Thomas 'PointedEars' Lahn]

Re: Problem with XmlHttpRequest (0x80040111 / nsIXMLHttpReque st.status) on several configurations

Arnaud Diederen (aundro wrote:
[color=blue]
> 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
> onreadystatecha nge() handler, when it comes to setting the
> document.locati on.href, I'd wrap it in a timeout callback, rather than
> do it directly:
>
> ------------- directly -----------
> req.onreadystat echange = function {
>
> if (req.readyState == 4) {
>
> if (req.status == 200) {
>
> document.locati on.href = ...
> }
> }
> }
> ----------------------------------
>
>
> ------------- timeout -----------
> req.onreadystat echange = function {
>
> if (req.readyState == 4) {
>
> if (req.status == 200) {
>
> setTimeout (function () {
>
> document.locati on.href = ...;
> }, 100); // in 100 ms.
> }
> }
> }
> ----------------------------------
>
> That's it.
> Has anyone any comment on whether this is good or bad?[/color]

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

[VK]

Re: Problem with XmlHttpRequest (0x80040111 / nsIXMLHttpReque st.status) on several configurations


Thomas 'PointedEars' Lahn wrote:[color=blue]
> Arnaud Diederen (aundro wrote:
>[color=green]
> > 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
> > onreadystatecha nge() handler, when it comes to setting the
> > document.locati on.href, I'd wrap it in a timeout callback, rather than
> > do it directly:
> >
> > ------------- directly -----------
> > req.onreadystat echange = function {
> >
> > if (req.readyState == 4) {
> >
> > if (req.status == 200) {
> >
> > document.locati on.href = ...
> > }
> > }
> > }
> > ----------------------------------
> >
> >
> > ------------- timeout -----------
> > req.onreadystat echange = function {
> >
> > if (req.readyState == 4) {
> >
> > if (req.status == 200) {
> >
> > setTimeout (function () {
> >
> > document.locati on.href = ...;
> > }, 100); // in 100 ms.
> > }
> > }
> > }
> > ----------------------------------
> >
> > That's it.
> > Has anyone any comment on whether this is good or bad?[/color]
>
> 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.locati on 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.[/color]

Wow!

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

[Arnaud Diederen]

Re: Problem with XmlHttpRequest (0x80040111 / nsIXMLHttpReque st.status) on several configurations

Thomas 'PointedEars' Lahn <PointedEars@we b.de> writes:
[color=blue]
> Arnaud Diederen (aundro wrote:
>[color=green]
>> 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
>> onreadystatecha nge() handler, when it comes to setting the
>> document.locati on.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?[/color]
>
> Considering that setTimeout() is unnecessary because the request is
> asynchronous already;[/color]

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.
[color=blue]
> that using function object references for its
> first argument is error-prone because not backwards compatible;[/color]

I didn't know that
[color=blue]
> that
> document.locati on is deprecated ever since in favor of
> window.location ;[/color]

Indeed, I use window.location , but that was just for the example,
sorry for the mistake.
[color=blue]
> that XMLHttpRequest is a host object that is not cross-browser and not
> backwards compatible;[/color]

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?
[color=blue]
> that you do not feature-test anything before,[/color]

Indeed, I didn't, that's just an example
[color=blue]
> 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.[/color]

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 "myRootFram e"), and setting a timeout function in
"myRootFram e" 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

[Thomas 'PointedEars' Lahn]

Re: Problem with XmlHttpRequest (0x80040111 / nsIXMLHttpReque st.status) on several configurations

VK wrote:
[color=blue]
> Thomas 'PointedEars' Lahn wrote:[color=green]
>> Arnaud Diederen (aundro wrote:[color=darkred]
>> > Personally, and I have no idea whether it is good practice, I use a
>> > timeout function. [...]
>> > [...]
>> > ------------- timeout -----------
>> > req.onreadystat echange = function {
>> >
>> > if (req.readyState == 4) {
>> >
>> > if (req.status == 200) {
>> >
>> > setTimeout (function () {
>> >
>> > document.locati on.href = ...;
>> > }, 100); // in 100 ms.
>> > }
>> > }
>> > }
>> > ----------------------------------
>> >
>> > That's it.
>> > Has anyone any comment on whether this is good or bad?[/color]
>>
>> 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.locati on 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.[/color]
>
> Wow!
>
> Thomas 'PointedEars' Lahn just cancelled AJAX.[/color]

I did not such thing.
[color=blue]
> Poor people of the world.[/color]

Poor VK who still does not understand.


PointedEars

[Thomas 'PointedEars' Lahn]

Re: Problem with XmlHttpRequest (0x80040111 / nsIXMLHttpReque st.status) on several configurations

Arnaud Diederen (aundro wrote:
[color=blue]
> Thomas 'PointedEars' Lahn <PointedEars@we b.de> writes:[color=green]
>> Arnaud Diederen (aundro wrote:[color=darkred]
>>> 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
>>> onreadystatecha nge() handler, when it comes to setting the
>>> document.locati on.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?[/color]
>> Considering that setTimeout() is unnecessary because the request is
>> asynchronous already;[/color]
>
> 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.[/color]

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.
[color=blue][color=green]
>> that using function object references for its
>> first argument is error-prone because not backwards compatible;[/color]
>
> I didn't know that[/color]

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.
[color=blue][color=green]
>> that XMLHttpRequest is a host object that is not cross-browser and not
>> backwards compatible;[/color]
>
> 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?[/color]

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.
[color=blue][color=green]
>> 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.[/color]
>
> 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 "myRootFram e"), and setting a timeout function in
> "myRootFram e" that will change "myFrame"'s location.
> What is your solution? I don't understand it.[/color]

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.locatio n'
instead of `document.locat ion', 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.
[color=blue]
> (1) I specified "you find out" because you might not need to refresh it.[/color]

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

[Arnaud Diederen]

Re: Problem with XmlHttpRequest (0x80040111 / nsIXMLHttpReque st.status) on several configurations

Thomas 'PointedEars' Lahn <PointedEars@we b.de> writes:
[color=blue]
> Arnaud Diederen (aundro wrote:
>[color=green]
>> Thomas 'PointedEars' Lahn <PointedEars@we b.de> writes:[color=darkred]
>>> 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
>>>> onreadystatecha nge() handler, when it comes to setting the
>>>> document.locati on.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;[/color]
>>
>> 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.[/color]
>
> 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.[/color]

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 onreadystatecha nge is a function that sits in the scope of
"mySub". From that function, if you do a
`window.locatio n.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
onreadystatecha nge 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
onreadystatecha nge handler of the request*

[color=blue]
> 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.[/color]

Yes, Thomas, yes..
[color=blue]
>[color=green][color=darkred]
>>> that XMLHttpRequest is a host object that is not cross-browser and not
>>> backwards compatible;[/color]
>>
>> 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?[/color]
>
> 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.[/color]

I _know_ that, thanks
[color=blue]
>[color=green][color=darkred]
>>> 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.[/color]
>>
>> 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 "myRootFram e"), and setting a timeout function in
>> "myRootFram e" that will change "myFrame"'s location.
>> What is your solution? I don't understand it.[/color]
>
> 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.[/color]

Me too, as explained before.
[color=blue]
>
> 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.locatio n'
> instead of `document.locat ion', 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>[/color]

Please, understand and consider the scenario above.
[color=blue]
>
> 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.
>[color=green]
>> (1) I specified "you find out" because you might not need to refresh it.[/color]
>
> 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.[/color]

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

[bollax@hotmail.com]

Re: Problem with XmlHttpRequest (0x80040111 / nsIXMLHttpReque st.status) on several configurations

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.

[PedroG]

Ajax

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:

[daniel.maceira@gmail.com]

Re: Problem with XmlHttpRequest (0x80040111 / nsIXMLHttpReque st.status) on several configurations

Did you find a solution for the error 0x80040111
(NS_ERROR_NOT_A VAILABLE) ?!
I´m having the same problem...

[jkichline]

This fixed the problem

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="doSub mit(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="doSub mit(this); return false;">...</form>

Problem solved... a little strange that it works this way, but at least it was fixable.

[LateDeveloper]

Problem with XMLHTTPrequest in FireFox

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:som efunction();">C lick</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:som efunction();"></input>, the problem resolved itself.

I hope this spares someone the grief I had.