h3h.net

As geeks sometimes do, I was discussing event firing with respect to the input element with fellow members of #javascript@EFNet. I made a simple test script that shows the ordering of event firing. The inconsistencies across different browsers are interesting and funny; that is, if you’re a geek.

When considering the ordering of the events fired, I performed three basic tests on a fresh load of my test script:

1. Click the input element.
2. Click the label element.
3. Click the input element then click the label element.

The different behaviors across the browsers are as follows:

Mozilla (1.7.6)

I’ll start with Mozilla first because it seems to behave the most intuitively to me.

1. mousedown, focus, mouseup, click, change - There’s nothing special here. The focus event fires after the mousedown, mirroring the visual behavior, and after the click event comes the change event because the input’s state is changed from unchecked to checked.
2. focus, click, change - Again, nothing strange here. Clicking the label focuses the input and fires its click event, which leads to the change event again.
3. blur, focus, click - In this case the input is already focused, so clicking on the label makes the input blur, but then the label sets focus to the input once more and the click event is fired. This also seems intuitive to me.

Internet Explorer (6, SP2)

IE’s behavior, although mostly competent, seems a bit less intuitive.

1. mousedown, focus, mouseup, click - Same as Mozilla, but the change event isn’t fired. This is because, for some strange reason, DOM 2 Events specifies that the change event shouldn’t fire until the input element loses focus. This seems dumb to me because I want to know that an element has changed when it changes, not after the fact. Also note that “loses focus” is not the same as blur–if the browser window loses focus, the input’s blur event will be fired, but not the change event. It’s worth noting that the click event should be used whenever you’re trying to monitor the changes of radio buttons.
2. click, focus - Here the order is switched as the click event is fired before the focus event. I can’t see any reason for this inconsistency. The change event is, of course, still missing.
3. change, blur, click, focus - Here again the click and focus events are strangely reversed. Update: IE6 fires a change event before the other three. This was missed in original testing.

Opera (8.0)

Opera behaves mostly the same as IE, but doesn’t do the weird inconsistent switch of focus and click. It does have a quirk of its own though. I have my same qualms with the firing of the change event, and that’s something that the W3C messed up on.

1. focus, mousedown, click, mouseup - The focus event is fired before the mousedown. I have no idea where that one came from.
2. focus, click
3. blur, focus, click

Safari (1.3)

Safari really didn’t have a fair fight here because it lacks label support altogether. Hyatt, however, has assured me that he’s added support and that it will be in a future release (but sadly not with Tiger).

1. mousedown, mouseup, click - Oops! Where’d my focus event go? Apparently that event was completely forgotten.
2. Un-testable
3. Un-testable

Konqueror 3.5.x

Update! Konqueror comes late in the game.

1. mousedown, focus, mouseup, change, click - like Mozilla, but change and click are switched.
2. focus, mouseup, change, click - mouseup is a new one for this test; change and click are still switched.
3. blur, focus, mouseup, click - again just a mouseup that Mozilla doesn’t have.

So what have we learned from all of this? Mozilla implemented common sense behavior while sacrificing strict compliance to the lame (IMHO) spec. Kudos.

IE has some weird order switching that probably won’t matter in 99.9% of normal cases, but it’s bizarre nonetheless. Also in the process of testing I found that an input element without a name cannot be checked in IE.

Opera fires focus before mousedown, which is just…weird. Other than that it’s to spec.

Safari fumbles on the focus event and we’re waiting on label support. I would also like to applaud and thank Dave Hyatt for his transparent look into the development changes he’s making on Safari to address the problems highlighted by the new Acid2 test.

Konqueror is better than some, but the activation of the controls happens after mouseup instead of after click like the others. A KDE dev has said he might change this behavior to match the others.

All in all it’s been an interesting day.