In the past I’ve mentioned my confusion about the differing behaviour of certain aspects of the oh-so-trendy XMLHttpRequest object, but now I have access to a couple of non-windows browsers for testing I thought I’d take a look to see how they handle it. Perhaps unsurprisingly they are also subtly different again from IE, Firefox and Opera. Is this what happens when browser makers have to reverse engineer someone else’s feature instead of working with documented standards?
Here’s a quick overview of how the this keyword and the event object — which is
(in theory) passed to the event handler in standards compliant browsers and found in window.event
in IE — work when used in the onreadystatechange
and onload event handlers across some different browsers.
| this | event object | event target | |
|---|---|---|---|
| onreadystatechange | object Window | null | N/A |
| onload | N/A | N/A | N/A |
| this | event object | event target | |
|---|---|---|---|
| onreadystatechange | arguments.callee |
undefined | N/A |
| onload | object XMLHttpRequest | object Event | object XMLHttpRequest |
| this | event object | event target | |
|---|---|---|---|
| onreadystatechange | object XMLHttpRequest | undefined | N/A |
| onload | object XMLHttpRequest | undefined | N/A |
| this | event object | event target | |
|---|---|---|---|
| onreadystatechange | object Window | object Event | null |
| onload | object Window | object Event | null |
To me, what Mozilla/Firefox does with the onload event seems most sane, as in it’s
most like any other normal event. (Although at the moment, I’m struggling to think of ways the
event object could be really useful in this case). The way it works with onreadystatechange just seems
plain weird… Mozilla also allows you to use addEventListener to detect the onload
event:
xmlhttp.addEventListener('load', function(e) {
// do stuff
}, false);
But this doesn’t appear to work in any of the other browsers, or for onreadystatechange in Mozilla.
The W3C working draft of The XMLHttpRequest Object
says that onreadystatechange events MUST implement the
Event interface [DOM3EV].
So the event handler for onreadystatechange should be
passed an event object, something which is only done by Safari 2 and Konqueror at present. Currently the specs only deal with onreadystatechange and not onload or any
other events.
While the event object seems to be covered by the spec I’m not sure if all the weirdness and inconsistency found when using this would
be within the scope of the current standardization efforts? But it would certainly be nice if this worked reliably cross browser. It should also be noted
that some hitch-like function (or whatever
you choose to call it) can be used to get this pointing at something a little more useful in Mozilla and the KHTML browsers,
however it doesn’t seem to help in IE.
function hitch(obj, fn) {
return function() { fn.apply(obj, arguments); }
}
function orsc() {
alert(this);
}
xmlhttp.onreadystatechange = hitch(xmlhttp, orsc);
Permalink. Posted on 23rd June 2006 in Browsers, JavaScript, Web Standards.
"this" should probably be defined in general. What it would point to inside an EventListener. So that would out of scope of the XMLHttpRequest specification.
Note also that the specification states readystatechange and not onreadystatechange. There's an event and an attribute that takes an EventListener. There's also a difference between the two ;-)
# Posted by Anne van Kesteren on 23rd June 2006.
The draft W3C spec. www.w3.org/TR/XMLHttpRequest/ puts XHR on top of DOM3 Events which uses DOM2 but I'm stuffed if I can find out if the behaviour of "this" is standardised anywhere!
In fact Flanagan's 4th edition "JavaScript: The Definitive Guide" explicitly says that "this" behaves in an O-O way for HTML attribute events but is implementation-dependent
in DOM2 :-(
# Posted by James Denholm-Price on 10th July 2006.
Sorry, comments for this item are currently closed.








