repeated XMLHttpRequest GETs and displaying result

[Dr J R Stockton]

In comp.lang.javascript message <[email protected]>
, Thu, 26 Jun 2008 23:56:16, Richard Cornford

Is there any point in a CPU spinning its wheels more efficiently?

A shorter algorithm, where it works as well or better, is always an
improvement. This one illustrates the point that no work that can be
done outside a loop should be done within it (and unary +).

If you still have access to the FAQ, how about correcting Section 5?

 

[Thomas 'PointedEars' Lahn]

I understand the need to clear a setInterval() timer, but not a
setTimeout() that has already timed out.

How did you get that idea?

In which browser/browsers did you observe those leaks and/or error
messages ? (IE, again ?)

Yes, it was IE 6 in particular.

Nope. I don't. But if you do, may you please explain why :


only in FF3... ?

Fx 2 exhibits the same behavior, and the Gecko source code shows why.


PointedEars

 

[Jorge]

Fx 2 exhibits the same behavior, and the Gecko source code shows why.

What ?
In Spain it runs fine in FF2, Opera and Safari... jejeje.
See : http://tinyurl.com/58tz3t

What's going on here ?

--Jorge.

 

[Thomas 'PointedEars' Lahn]

What ?

javascript:var x = new XMLHttpRequest(); x.open("GET", "/", true);
x.onreadystatechange = function() { if (x.readyState == 4)
window.alert(x.onreadystatechange); }; x.send(null);

shows `null' in

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.14) Gecko/20080404
Firefox/2.0.0.14

In Spain it runs fine in FF2, Opera and Safari... jejeje.
See : http://tinyurl.com/58tz3t

(Please don't post such URIs.)

Doesn't work at all in my Fx 2 (see above), stays at 999.

What's going on here ?

Unknown. Maybe it's because you are assigning the event listener *before*
you call open() which is not how asynchronous XHRs are usually done. The
proper order is construct -- open() -- .onreadystatechange -- send().


PointedEars

 

[Jorge]

Unknown.  Maybe it's because you are assigning the event listener *before*
you call open() which is not how asynchronous XHRs are usually done.  The
proper order is construct -- open() -- .onreadystatechange -- send().

Did you watch the video ?

http://tinyurl.com/5b2esw

And ? Why does it run in my FF2 ?

--Jorge.

 

[Thomas 'PointedEars' Lahn]

Did you watch the video ?

No, I used the URI and looked at the counter which did not change in my Fx2.

http://tinyurl.com/5b2esw

What part of "Please don't post such URIs." is still unclear to you?

And ?

And -- what?

Why does it run in my FF2 ?

Since I have no intention of repeating myself, I strongly suggest you learn
how to extract meaning from already posted texts.


PointedEars

 

[Jorge]

No, I used the URI and looked at the counter which did not change in my Fx2.

Install firebug (1.05) enable it and then it will run. (!)

This XPCOM XHR thing in FF is quite special, isn't it ?
Why the need to clear the handlers ?

What part of "Please don't post such URIs." is still unclear to you?

The why part.

And -- what?


Since I have no intention of repeating myself, I strongly suggest you learn
how to extract meaning from already posted texts.

I missed the post where you say "because you've got FireBug enabled".

--Jorge.

 

[Thomas 'PointedEars' Lahn]

Install firebug (1.05) enable it and then it will run. (!)

That appears to be the explanation because I have Firebug 1.2.0b3
installed on Fx 3, which is automatically disabled when running Fx 2
because it is not compatible.

This XPCOM XHR thing in FF is quite special, isn't it ?

Yes, apparently Firebug when enabled modifies XHR enough so that it behaves
quite different than implemented. Now that you mention it, I remember to
have seen several postings elsewhere that complained about XHR not properly
working when Firebug was enabled. However, I have not seen and did not
expect it to mess with `onreadystatechange' as well. Unfortunately, it is
still the same with Firebug 1.2.0b3.

Why the need to clear the handlers ?

You are asking the right question to the wrong person.

The why part.

Such URIs tend to not work for long which is especially bad when a posting
is archived as the URI quickly becomes useless. They are also non-obvious
so that even if the URL expires a service like the Internet WayBack machine
cannot be used on order to retrieve the content. And finally, following
them is only adding to the service provider's hit count while they are not
necessary at all.

This and more is most obvious to everyone else but you, and it has been
discussed before here. It may be even a FAQ.

I missed the post where you say "because you've got FireBug enabled".

You must be kidding.


Score adjusted

PointedEars

 

[Jorge]

Yes, apparently Firebug when enabled modifies XHR enough so that it behaves
quite different than implemented.  Now that you mention it, I remember to
have seen several postings elsewhere that complained about XHR not properly
working when Firebug was enabled.  However, I have not seen and did not
expect it to mess with `onreadystatechange' as well.  Unfortunately, itis
still the same with Firebug 1.2.0b3.

Hmm, yeah, the code at http://tinyurl.com/58tz3t runs in FF3 as well,
as long as firebug is enabled.

I don't think that that's unfortunate, that's the way it should be. I
can't figure out what's (Mozilla's) excuse to arbitrarily null a
property of an object after it has been created and setup by my code.
There's no need to, and other browsers don't do it.

BTW, did you notice that "this" is setup differently in the
onreadystatechange callback, in FF2 ? it points to the XHR object in
Safari, Opera and FF3.

Bye,
--Jorge.

 

[Jorge]

(...)
This and more is most obvious to everyone else but you,
(...)
(...)
Score adjusted

Thomas, Thomas. Eat your pills.

--Jorge.

 

[dhtml]

How did you get that idea?

I don't see why calling clearTimeout there.
============================================
var t = window.setTimeout(
function() {
window.clearTimeout(t);
============================================

The callback function for setTimeout has already fired. What is the
purpose for calling clearTimeout? The variable - t - is not even
needed.

Garrett