Event compatibility tables

Last updated on 29 April 2008.

See section 7B of the book.

Microsoft documentation.

Mozilla documentation. Be sure to study the "Other events", too.

Safari has always referred to my compatibility tables for more JavaScript information, so you’re currently reading the Safari documentation.

Opera documentation; unfortunately the events are summed up on a per-tag basis.

W3C DOM Events specification. Unfortunately it does not always pay attention to the current implementation of the events in the browsers.

On this page I give a quick overview of events browser compatibility.

I assume that you know the three event registration models (traditional, W3C and Microsoft) as well as event bubbling and capturing.

I spent most of my time on the cross-browser events; the links in the first compatibility table lead to even more compatibility tables with detailed information about these events.

I merely tested basic browser support for the Microsoft and W3C events without delving too deeply into the details.

Cross-browser events

Definition: cross-browser events are supported by IE and at least two of the following three browsers: Firefox, Safari, Opera.

All bugs noted in the table below are explained on the detail pages. I haven’t tested the load and unload events yet; they’ll be added to the table later on.

Event IE 5.5 IE 6 IE 7 IE8b1 FF 2 FF 3b5 Saf 3.0 Win Saf 3.1 Win Opera 9.26 Opera 9.5b Konqueror 3.5.7

When an element loses the focus.

Yes Too many Almost Incomplete Almost Incomplete Incomplete
  • Firefox 2 fires too many events in a variety of circumstances.
  • Firefox 3 fires too many events when blurring the window.
  • Safari and Opera don’t support these events on links and/or form fields in all circumstances.
  • Konqueror doesn’t support these events on the browser window.

When a form field value changes.

Buggy Yes Yes Yes Yes
  • IE has a serious bug in its handling of this event on checkboxes and radios.

When a mousedown and mouseup event occur on the same element OR an element is activated by the keyboard.

Yes Yes Yes Yes Yes
Event IE 5.5 IE 6 IE 7 IE8b1 FF 2 FF 3b5 Saf 3.0 Win Saf 3.1 Win Opera 9.26 Opera 9.5b Konqueror 3.5.7

When the user right-clicks to get the context menu.

Yes Minimal Yes Buggy Yes No No

Preventing the default (i.e. preventing the context menu from appearing) is the whole point of this event.

  • IE8b1 doesn’t allow you to prevent the default.
  • To prevent the default in Firefox 3 you have to cancel the event bubbling.

When text is copied.

Yes No Too many Yes No No
  • Firefox 3 has a lazy implementation.

When text is cut.

Yes No Too many Yes No No
  • Firefox 3 has a lazy implementation.

When two click events take place on the same element within a reasonable timeframe.

Yes Yes Yes Yes No

When the browser encounters a JavaScript error or a non-existent image file.

Almost Almost Incomplete Incomplete Incomplete
  • IE and Firefox have trouble with JavaScript errors in the traditional event registration model.
  • Safari, Opera and Konqueror do not support this event on JavaScript errors.
Event IE 5.5 IE 6 IE 7 IE8b1 FF 2 FF 3b5 Saf 3.0 Win Saf 3.1 Win Opera 9.26 Opera 9.5b Konqueror 3.5.7

When an element receives the focus.

Yes Too many Incomplete Almost Incomplete Incomplete
  • Firefox fires too many events in a variety of circumstances. (FF2 in more circumstances than FF3.)
  • Safari and Opera don’t support these events on links and/or form fields in all circumstances.
  • Konqueror doesn’t support these events on the browser window.

When the user depresses a key.

Yes Yes Yes Minimal Incomplete

The event should continue firing as long as the user keeps the key depressed.

  • The keydown event does not repeat in Opera and Konqueror.
  • You cannot prevent the default onkeydown in Opera.

When a keystroke leads to a character being added to an HTML element.

Yes Too many Too many Yes Minimal Too many Too many

This event should fire only if a keystroke leads to a character actually being added to an HTML element such as a text input. It should not fire when the user presses keys like the arrow keys which do not result in a character.

The event should continue firing as long as the user keeps the key depressed.

  • Firefox, Safari 3.0, Opera and Konqueror fire keypress events on any key.
  • You cannot prevent the default onkeypress in Opera 9.26.

When the user releases a key.

Yes Yes Yes Yes Yes

This event fires after the keystroke has been processed; for instance after a character has been added to a text input. It’s not possible to cancel the default action because that action has already taken place. This event should not repeat.

Event IE 5.5 IE 6 IE 7 IE8b1 FF 2 FF 3b5 Saf 3.0 Win Saf 3.1 Win Opera 9.26 Opera 9.5b Konqueror 3.5.7

When the user depresses a mouse button.

Yes Yes Yes Yes Yes

When the mouse is moved.

Yes Yes Yes Yes Yes

When the mouse leaves an element.

Yes Buggy Yes Yes Yes Yes
  • IE8b1 has an odd bug on elements with a padding.

When the mouse enters an element.

Yes Buggy Yes Yes Yes Yes
  • IE8b1 has an odd bug on elements with a padding.

When the user releases a mouse button.

Yes Yes Yes Yes Yes
Event IE 5.5 IE 6 IE 7 IE8b1 FF 2 FF 3b5 Saf 3.0 Win Saf 3.1 Win Opera 9.26 Opera 9.5b Konqueror 3.5.7

When the user uses the mousewheel. Note that the page does not have to scroll for the event to fire.

No Yes No Yes Yes No

It is possible to cancel the default action so that the element does not scroll.

When text is pasted.

Yes No Too many Yes No No
  • Firefox 3 has a lazy implementation.

When the user resets a form.

Yes Yes Yes Yes Yes

When the window is resized.

Yes Yes Yes Almost Almost
  • Opera and Konqueror have some bubbling problems.
Event IE 5.5 IE 6 IE 7 IE8b1 FF 2 FF 3b5 Saf 3.0 Win Saf 3.1 Win Opera 9.26 Opera 9.5b Konqueror 3.5.7

When something is scrolled.

Yes Crash Yes Buggy Yes No
  • IE8b1 may crash after a while.
  • Safari probably monitors scrollTop access in order to determine whether the user has scrolled an element with overflow: auto.

When the user selects text in a text input field.

Yes Yes Yes Yes No

As far as I’m concerned this event should also fire when the user selects text in any element. No browser agrees, though.

When the user submits a form.

Yes Yes Yes Yes Yes
Event IE 5.5 IE 6 IE 7 IE8b1 FF 2 FF 3b5 Saf 3.0 Win Saf 3.1 Win Opera 9.26 Opera 9.5b Konqueror 3.5.7

W3C events

The events below do not work with traditional event registration. You have to use addEventListener in order to capture these events.

I don’t understand why this should be so; it breaks the ancient and reliable rule that any event is available in any registration model.

The camelcase-like event names are required. Here, too, an old rule is broken: all other event names are strictly lower case.

Event IE 5.5 IE 6 IE 7 IE8b1 FF 2 FF 3b5 Saf 3.0 Win Saf 3.1 Win Opera 9.26 Opera 9.5b Konqueror 3.5.7
DOMActivate

Should fire when an element is activated.

Test page.

No Yes Incorrect and incomplete No Incorrect

A link is activated when the user follows it. A checkbox or radio is activated when it is checked or unchecked.

  • Safari and Konqueror incorrectly treat this event as an equivalent of the click event. For instance, when you click on a text input the event fires. It shouldn’t: clicking on a text input does not activate the text box. Firefox correctly fires a click event only.
  • Safari does not fire this event on radios and checkboxes.
DOMAttrModified

An attribute in the DOM tree of the element has been changed.

Test page.

No Too many No Too many No
  • Firefox and Opera also fire this event when you scroll a page, even though no DOM attribute is modified.
DOMCharacterDataModified

Text in the DOM tree of the element has been changed.

Test page.

No Incomplete Incomplete Yes Incomplete Incomplete
  • Firefox, Safari 3.0, Opera and Konqueror do not fire the event when you change character data through innerHTML.
Event IE 5.5 IE 6 IE 7 IE8b1 FF 2 FF 3b5 Saf 3.0 Win Saf 3.1 Win Opera 9.26 Opera 9.5b Konqueror 3.5.7
DOMFocusIn

As focus, but bubbles.

Test page.

No No No Yes No Yes Yes
DOMFocusOut

As blur, but bubbles.

Test page.

No No No Yes No Yes Yes
DOMMouseScroll

When the user uses the mouse wheel.

Test page.

No Yes No No No

Equivalent of mousewheel.

DOMNodeInserted

A new node has been inserted into the DOM tree of the element.

Test page.

No Yes Yes Yes Incomplete

If you change an element’s innerHTML, browsers first fire a DOMNodeRemoved event for every child node of the element, and then a DOMNodeInserted event for every child node in the new version.

  • Konqueror does not fire these events when you use innerHTML.
Event IE 5.5 IE 6 IE 7 IE8b1 FF 2 FF 3b5 Saf 3.0 Win Saf 3.1 Win Opera 9.26 Opera 9.5b Konqueror 3.5.7
DOMNodeRemoved

A node has been removed from the DOM tree of the element.

Test page.

No Yes Yes Yes Incomplete

If you change an element’s innerHTML, browsers first fire a DOMNodeRemoved event for every child node of the element, and then a DOMNodeInserted event for every child node in the new version.

  • Konqueror does not fire these events when you use innerHTML.
DOMSubtreeModified

The most generic event: something in the DOM tree of the element has changed.

Test page.

No No Yes Yes No Yes
textInput

Equivalent of keypress.

Test page.

No No Yes No No

This is a DOM event, despite the "DOM" bit missing in the name. Therefore it does not work with traditional event registration.

Event IE 5.5 IE 6 IE 7 IE8b1 FF 2 FF 3b5 Saf 3.0 Win Saf 3.1 Win Opera 9.26 Opera 9.5b Konqueror 3.5.7

Microsoft events

Event IE 5.5 IE 6 IE 7 IE8b1 FF 2 FF 3b5 Saf 3.0 Win Saf 3.1 Win Opera 9.26 Opera 9.5b Konqueror 3.5.7
activate

Despite the name this event is an equivalent of focusin.

Test page.

Yes No No No No
beforecopy

Test page.

Yes No No Yes No No

I do not understand the real purpose of these events. However, when the user calls up a context menu that contains cut, copy and paste actions, beforecut, beforecopy and beforepaste all fire.

beforecut

Test page.

Yes No No Yes No No

See beforecopy.

beforepaste

Test page.

Yes No No Incomplete No No

See beforecopy.

  • Safari 3.1 does not fire this event before an actual paste action. It works fine on context menus.
Event IE 5.5 IE 6 IE 7 IE8b1 FF 2 FF 3b5 Saf 3.0 Win Saf 3.1 Win Opera 9.26 Opera 9.5b Konqueror 3.5.7
deactivate

Despite the name this event is an equivalent of focusout.

Test page.

Yes No No No No
focusin

As focus, but bubbles.

Test page.

No Yes No No No No

Not available on the window.

focusout

As blur, but bubbles.

Test page.

No Yes No No No No

Not available on the window.

hashchange

When the hash value of the location changes.

Test page.

No Yes No No No No

This event might be interesting for monitoring Back/Forward in Ajax interfaces.

Event IE 5.5 IE 6 IE 7 IE8b1 FF 2 FF 3b5 Saf 3.0 Win Saf 3.1 Win Opera 9.26 Opera 9.5b Konqueror 3.5.7
mouseenter

When the mouse enters an element, but it doesn’t bubble.

MUCH more useful than mouseover. Come on, Mozilla. Come on, Safari. Come on, Opera. Come on, Konqueror.

Test page.

Yes No No No No

The other browsers should implement these events as soon as possible.

(Yes, I know I’m shouting, but I’ve been saying this since 2003 and nobody has ever paid my message the least attention.)

Mouseover and mouseout also fire when the user mouses over or out of a child element of the element you registered the events on. Mouseenter and mouseleave don’t. Thus, they are the true equivalent of CSS :hover.

Once these events are supported by all browsers, creating dropdown menus will become a walk in the park. It’s Firefox’s, Safari’s and Opera’s fault that we still have to waste hours and hours on carefully distinguishing between important and unimportant mouseover and mouseout events. If we just had mouseenter and mouseleave, all our problems would be solved.

mouseleave

When the mouse leaves an element, but it doesn’t bubble.

MUCH more useful than mouseout.

Test page.

Yes No No No No

See mouseenter remarks.

Event IE 5.5 IE 6 IE 7 IE8b1 FF 2 FF 3b5 Saf 3.0 Win Saf 3.1 Win Opera 9.26 Opera 9.5b Konqueror 3.5.7