TruerWords Logo
Google
 
Web www.truerwords.net

Search TruerWords

Welcome
Sign Up  Log On

“Events, Listeners, and MSIE: A Big Surprise”

From: Seth Dillingham In Response To: Top of Thread.  
Date Posted: Wednesday, February 7, 2007 9:32:20 PM Replies: 1
   
Enclosures: None.

I've been doing event-based JavaScripting for approximately as long as there has been such a thing.

One of the foundations of this programming is that MSIE puts its event object at window.event, and most everybody else passes the event object to the listener (the method that is called when the event is triggered).

I moved past my frustration with that difference in behavior many years ago, so I could get some real work done. Know what I mean?

Turns out it's not true anyway.

Someone (can't say who) contacted me today in a fit of confusion. HIs events listeners in MSIE 6 were receiving events objects as parameters.

He was using Prototype to set up his listeners, so I assumed it had something to do with that. I looked into it...

First, I tried my own test, of course. Yep, there's the event object.

Second, I traced the code in Prototype. Function.bindAsEventListener() would explain it... except that's not what we were using in this case.

Nothing else in Prototype explained it, so I went out to the web to see what others had to say.

David Flanagan — The Man Himself, author of my favorite book on JavaScripthad this to say: back on October 23 of last year (just 3 1/2 months ago):

I don't know how I know this: it is just one of those things I've always known about IE. But a reader (Tom Stambaugh of zeetix.com) just emailed me with a trivially simple counter example. It turns out that if you use attachEvent() (at least in IE 6) then the event handler you specify is passed an event object as an argument.

I don't think I'm the only one who believed that handlers registered with attachEvent() don't get passed an event object. For example, the documentation on attachEvent() at about.com says:

Also unlike the standard DOM method, the event is not passed to the function as a parameter. Instead IE supplies a standard window.event object to hold the details relating to the latest event.

And the documentation for the YUI event library advertises, as a feature of the library, that:

The first parameter your callback receives when the event fires is always the actual event object. There is no need to look at window.event.

[SNIP]

Update: Thanks to the commenters who have pointed out the interesting fact that the event object passed to a handler is not the same object (not == to) window.event. I've written a trivial test that demonstrates that 1) an object is passed to a handler registered with attachEvent(), 2) that this object is not == to window.event, and that 3) the properties of this object are the same as the properties of window.event (except that they both have a property that refers to different empty arrays).

[SNIP]

Update 2: In comments, Alistair Potts presents test results that indicate that attachEvent has always passed a copy of the window.event object to event handlers. His test code is at: http://www.partyark.co.uk/html/ieeventtest.htm

(I seriously wonder if everybody else based their assumptions on David's own writing. I think the original version of his book was published by Gutenberg himself, and almost every serious JavaScripter has a copy of it.)

Long story, short: MSIE has (almost) always passed the event object to the listeners, as long as you registered the listener with attachEvent instead of just "assigning" the listener.


Discussion Thread:
Trackbacks:

There are no trackbacks.


Until August 31
My Amazon sales
benefit the PMC

Homepage Links

Apr 1 - Aug 31
Ad revenue
benefits the PMC


TruerWords
is Seth Dillingham's
personal web site.
From now on, ending a sentence with a preposition is something up with which I will not put. - WC