XMLHttpRequest -- wrong Wikipedia article?

[Thomas 'PointedEars' Lahn]

Hello all,

many of the subscribers of this newsgroup know through experience that
Wikipedia is not exactly a fountain of wisdom when it comes to ECMAScript-
based programming. In particular, the last paragraph of
<http://en.wikipedia.org/wiki/XMLHttpRequest#The_onreadystatechange_event_listener>,
which might have led to <<[email protected]>, left me puzzled:

| The onreadystatechange event listener
|
| If the open method of the XMLHttpRequest object was invoked with the third
| parameter set to true for an asynchronous request, the onreadystatechange
| event listener will be automatically invoked for each of the following
| actions that change the readyState property of the XMLHttpRequest object.
|
| Theoretically, state changes should work like this:
|
| - After the open method has been invoked successfully, the readyState
| property of the XMLHttpRequest object should be assigned a value of 1.
| - After the send method has been invoked and the HTTP response headers
| have been received, the readyState property of the XMLHttpRequest object
| should be assigned a value of 2.
| - Once the HTTP response content begins to load, the readyState property
| of the XMLHttpRequest object should be assigned a value of 3.
| - Once the HTTP response content has finished loading, the readyState
| property of the XMLHttpRequest object should be assigned a value of 4.
|
| However, the major user agents are inconsistent with the handling of the
| onreadystatechange event listener. For example, the following should
| produce four alerts: 1,2,3,4
|
| xmlhttp.open("GET","somepage.xml",true);
| xmlhttp.send(null);
| xmlhttp.onreadystatechange = function() {
| alert(xmlhttp.readyState);
| };
|
| In fact, some browser versions may omit state changes #1 and/or #2; if the
| order of the first two lines is reversed, some browsers may cause state
| change #1 to fire twice (or continue to omit event #2).[26] Due to the
| already-stated inconsistencies, it is bad coding practice to execute the
| xmlhttp's send method before assigning a callback function to
| onreadystatechange event handler. If reversed, that is if one assigned a
| callback function to the onreadystatechange event handler before executing
| the xmlhttp's send method - not after - like one should, the above
| mentioned inconsistencies are no longer issues.[27]

Now is it just me or is this last paragraph just pointless babble, driven by
mythical incantations rather than solid knowledge (who is this Eric
Pascarello person anyway)?

I have never encountered any problem in http.js (formerly: httprequest.js)
or elsewhere using the logical order,

xmlhttp.open("GET", "somepage.xml", true);
xmlhttp.onreadystatechange = function() {
window.alert(xmlhttp.readyState);
};
xmlhttp.send(null);

for when doing it differently, inconsistent behavior and a race condition is
to be expected (it is an *asynchronous* call). And IIUC, that is also what
the last sentence of this paragraph says. Why put error-prone example code
there, then going at length to explain the problems that must be caused by
it, instead of simply putting the correct version and be done with it?

What do you think? Am I missing something important here?


PointedEars

 

[Tim Streater]

Hello all,

| In fact, some browser versions may omit state changes #1 and/or #2; if the
| order of the first two lines is reversed, some browsers may cause state
| change #1 to fire twice (or continue to omit event #2).[26] Due to the
| already-stated inconsistencies, it is bad coding practice to execute the
| xmlhttp's send method before assigning a callback function to
| onreadystatechange event handler. If reversed, that is if one assigned a
| callback function to the onreadystatechange event handler before executing
| the xmlhttp's send method - not after - like one should, the above
| mentioned inconsistencies are no longer issues.[27]

Now is it just me or is this last paragraph just pointless babble, driven by
mythical incantations rather than solid knowledge (who is this Eric
Pascarello person anyway)?

I have never encountered any problem in http.js (formerly: httprequest.js)
or elsewhere using the logical order,

xmlhttp.open("GET", "somepage.xml", true);
xmlhttp.onreadystatechange = function() {
window.alert(xmlhttp.readyState);
};
xmlhttp.send(null);

for when doing it differently, inconsistent behavior and a race condition is
to be expected (it is an *asynchronous* call). And IIUC, that is also what
the last sentence of this paragraph says. Why put error-prone example code
there, then going at length to explain the problems that must be caused by
it, instead of simply putting the correct version and be done with it?

What do you think? Am I missing something important here?

No, you're right. There are intermediate values for readyState, but who
cares, eh? The only interesting and reliable value is (unfortunately) 4.
You can ignore all the others, which I do without problems.

It's actually a pity there is no reliable 3.5 value meaning "here,
reliably, are some partial results".

 

[Denis McMahon]

[ the wikipedia article for XMLHttpRequest contains broken code for
onreadystatechange ]

Of course, you being you, instead of correcting the broken code, and
editing the article to take away the crud, just had to rush over here and
pontificate about it instead.

Rgds

Denis McMahon

 

[Thomas 'PointedEars' Lahn]

[ the wikipedia article for XMLHttpRequest contains broken code for
onreadystatechange ]

Of course, you being you, instead of correcting the broken code, and
editing the article to take away the crud, just had to rush over here and
pontificate about it instead.

It is good to know that there are still people I can count on when I am in
need of an unqualified, pointless, unhelpful, ad-hominem remark :->

Those who can read have observed that I was not pontificating; I was asking
if I misunderstood or overlooked anything in my evaluation of the text, so
that I could have a better chance avoiding an edit war at Wikipedia, using
the resulting thread as reference. And since the knowledgable people are
here, not there, it was only logical to ask about it here.


PointedEars

 

[VK]

| However, the major user agents are inconsistent with the handling of the

| onreadystatechange event listener. For example, the following should
| produce four alerts: 1,2,3,4
|
| xmlhttp.open("GET","somepage.xml",true);
| xmlhttp.send(null);
| xmlhttp.onreadystatechange = function() {
|   alert(xmlhttp.readyState);
| };
|
| In fact, some browser versions may omit state changes #1 and/or #2; if the
| order of the first two lines is reversed, some browsers may cause state
| change #1 to fire twice (or continue to omit event #2).[26] Due to the
| already-stated inconsistencies, it is bad coding practice to execute the
| xmlhttp's send method before assigning a callback function to
| onreadystatechange event handler. If reversed, that is if one assigned a
| callback function to the onreadystatechange event handler before executing
| the xmlhttp's send method - not after - like one should, the above
| mentioned inconsistencies are no longer issues.[27]

It is an acceptable amateurish text IMHO. After all Wiki is majorly
written by amateurs and for amateurs so expressing difficult matters
in simple words: and the main message is to not assign callback after
send() but do it before which is right.
I do agree that the text is overly verbose, it could be just as short
as "In order to avoid possible browser-specific inconsistencies always
assign callback function *before* issuing send() command".
Who knows: it might be a reflection of a yet another rwar about the
"best coding practice". I remember back in 2005-2006 C++'ers and
Java'ers nearly killed each other for the "right" increment position
in for-loops
for (i=0; i<len; i++) VS. for (i=0; i<len; ++i)
The sophistication, philosophical profoundness and religious
exaltation of arguments, used by both camps, - still remain the
immortal classic of rwars of all times The war ended only after
full reverse-engineering of the block in question so to find out that i
++ and ++i in for-loops ends in verbatim equivalent assembly code

 

[David Mark]

[ the wikipedia article for XMLHttpRequest contains broken code for
onreadystatechange ]

Of course, you being you, instead of correcting the broken code, and
editing the article to take away the crud, just had to rush over here and
pontificate about it instead.

It is good to know that there are still people I can count on when I am in
need of an unqualified, pointless, unhelpful, ad-hominem remark :->

Those who can read have observed that I was not pontificating; I was asking
if I misunderstood or overlooked anything in my evaluation of the text, so
that I could have a better chance avoiding an edit war at Wikipedia, using
the resulting thread as reference.  And since the knowledgable people are
here, not there, it was only logical to ask about it here.

Yes, change the article. And delete jQuery's while you are in
there.

I suspect the confusion was caused by observing cached GET results.
An async XHR call turns synchronous in those cases (at least in some
browsers) and it would make sense for statuses 1 and 2 to be skipped.
And yes, I've heard of browsers stuttering status codes as well. As
mentioned, best not to rely on interim status reports from XHR objects
(I know I don't).

Also best not to rely on Wikipedia for information on browser
scripting. They've got lots of pages extolling the virtues of
thoroughly debunked scripts (e.g. jQuery). Hell, if you believe them,
jQuery is the only library out there that uses feature detection/
testing (despite the fact that they are more into stealth sniffing by
object inference). Don't see much criticism at all. It's browser
scripting for fans as told by fans.