Event compatibility tables

Last updated on 6 September 2011.

An older version of this page has been translated into Romanian.

On this page I give a quick overview of events browser compatibility. This research is exclusively about when the events fire, and on which elements you can add event listeners.

The spec is relatively clear about the latter, but frequently vague about the former. Thus it seems you’re currently reading the definitive treatise on event firing.

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

See also the mobile table.

Specification

This table contains all events in the Level 3 Events Specification, with the following exceptions:

  1. The useless DOM Level 2 events such as DOMNodeInserted, which are thankfully deprecated in this spec.
  2. The abort event: nobody ever needs it and it should be deprecated. Besides, the test case would require a download in the order of tens of Megs in order to be workable on fast connections (such as my home network).
  3. The composition events. I don’t understand them and don’t have the time to study them.

In addition the table treats several events that are not in the spec but have been supported forever.

Test IE 5.5 IE 6 IE 7 IE8 IE9 IE10 pr2 FF 7.0 Win FF 6.1 Mac Saf 5.1 Win Saf 5.1 Mac Chrome 14 Win Chrome 13 Mac Opera 11.51 Win Opera 11.51 Mac

When an element loses the focus.

Yes Yes Incomplete Incomplete Incomplete Yes
  • Firefox Mac, Safari, and Chrome sometimes don’t support these events on links and/or form fields. See detail page for bug descriptions.

When a form field value changes.

Buggy Incomplete Yes Yes Yes Incomplete
  • IE 5-8 has a serious bug in its handling of this event on checkboxes and radios.
  • IE and Opera have a serious bug in their handling of this event when the user uses the keyboard to change a select.

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

Almost Yes Almost Yes Yes Almost
  • All browsers but Safari have issues in preventing the default on form fields. Browsers judged Almost have two issues, the others (except Safari) one.

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

Yes Buggy Yes Yes Yes Yes Yes

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

  • IE8 always prevents the default when this event is handled on the document.
Test IE 5.5 IE 6 IE 7 IE8 IE9 IE10 pr2 FF 7.0 Win FF 6.1 Mac Saf 5.1 Win Saf 5.1 Mac Chrome 14 Win Chrome 13 Mac Opera 11.51 Win Opera 11.51 Mac

When text is copied.

Yes Yes Lazy Yes Lazy No
  • See detail page for lazy implementation.

When text is cut.

Yes Yes Lazy Yes Lazy No
  • See detail page for lazy implementation.

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

Yes Yes Yes Yes Yes

When the browser encounters a JavaScript error or a missing asset file.

Almost Yes Almost Yes Yes Incomplete
  • See detail page for bug descriptions.

When an element receives the focus.

Yes Yes Incomplete Incomplete Incomplete Yes
  • Firefox Mac, Safari, and Chrome sometimes don’t support these events on links and/or form fields. See detail page for bug descriptions.
Test IE 5.5 IE 6 IE 7 IE8 IE9 IE10 pr2 FF 7.0 Win FF 6.1 Mac Saf 5.1 Win Saf 5.1 Mac Chrome 14 Win Chrome 13 Mac Opera 11.51 Win Opera 11.51 Mac

As focus, but bubbles.

No Yes No Incomplete Incomplete Yes
  • Safari and Chrome fire these events only with addEventListener; not with traditional registration.

As blur, but bubbles.

No Yes No Incomplete Incomplete Yes
  • Safari and Chrome fire these events only with addEventListener; not with traditional registration.
hashchange

When the hash value of the location changes.

Test page.

No Almost Yes Yes Yes Yes

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

  • IE treats all hashes as case insensitive, while the other browsers treat them case sensitive.

When the user depresses a key.

Yes Yes Yes Yes Incorrect

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

  • Opera makes a mess: the keydown event does not repeat, and you cannot prevent the default.
Test IE 5.5 IE 6 IE 7 IE8 IE9 IE10 pr2 FF 7.0 Win FF 6.1 Mac Saf 5.1 Win Saf 5.1 Mac Chrome 14 Win Chrome 13 Mac Opera 11.51 Win Opera 11.51 Mac

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

Yes Incorrect Yes Yes Incorrect

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 and Opera fire keypress events on any key.

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.

When an asset (HTML page, image, CSS or JS file) is loaded. Almost Yes Almost Almost Almost Yes
  • Older IEs, Firefox, Safari, and Chrome do not fire a load event when a new style sheet is loaded.

When the user depresses a mouse button.

Yes Yes Yes Yes Yes
Test IE 5.5 IE 6 IE 7 IE8 IE9 IE10 pr2 FF 7.0 Win FF 6.1 Mac Saf 5.1 Win Saf 5.1 Mac Chrome 14 Win Chrome 13 Mac Opera 11.51 Win Opera 11.51 Mac

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

Come on, Mozilla. Come on, Apple. Come on, Google.
Yes No No No Yes

The other browsers should implement these events as soon as possible. They are in the spec. The spec is the thingy you should follow. So follow it!

(Yes, I know I’m shouting, but I’ve been saying this since 2003 and nobody has ever paid my message the least attention ... well, Opera has done something, but it took fucking eight years.)

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 the non-conforming browsers’ 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.

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

Yes No No No Yes

See mouseenter remarks. Including all-caps.

When the mouse is moved.

Yes Yes Yes Yes Yes

When the mouse leaves an element.

Yes Yes Yes Yes Yes
Test IE 5.5 IE 6 IE 7 IE8 IE9 IE10 pr2 FF 7.0 Win FF 6.1 Mac Saf 5.1 Win Saf 5.1 Mac Chrome 14 Win Chrome 13 Mac Opera 11.51 Win Opera 11.51 Mac

When the mouse enters an element.

Yes Yes Yes Yes Yes

When the user releases a mouse button.

Yes Yes Yes Yes Yes

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

No Yes Buggy Yes No Yes Yes Yes

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

  • If a mousewheel event handler is defined on an element in IE8, using the mouse wheel does not scroll the element. The event fires correctly, though. In other words, IE8 always prevents the default of the mousewheel event.

When text is pasted.

Yes Yes Lazy Yes Lazy No
  • See detail page for lazy implementation.
Test IE 5.5 IE 6 IE 7 IE8 IE9 IE10 pr2 FF 7.0 Win FF 6.1 Mac Saf 5.1 Win Saf 5.1 Mac Chrome 14 Win Chrome 13 Mac Opera 11.51 Win Opera 11.51 Mac

When the user resets a form.

Yes Yes Yes Yes Yes

When the window is resized.

Yes Yes Yes Yes Yes

When something is scrolled.

Yes Yes Yes Yes Yes
  • Safari probably monitors scrollTop access in order to determine whether the user has scrolled an element with overflow: auto. (Not applicable to iPhone.)

When the user selects text

Incomplete Yes Incomplete Incomplete Incomplete Incomplete

This event should also fire when the user selects text in any element. Only IE9 and up do so; the other browsers only react to selections in a text input or textarea.

Test IE 5.5 IE 6 IE 7 IE8 IE9 IE10 pr2 FF 7.0 Win FF 6.1 Mac Saf 5.1 Win Saf 5.1 Mac Chrome 14 Win Chrome 13 Mac Opera 11.51 Win Opera 11.51 Mac

When the user submits a form.

Yes Yes Yes Yes Yes
When a character is actually added to a control. (So it does not fire when the adding is prevented onkeydown or onkeypress.) No No Yes Yes No

Only works with addEventListener.

When the user navigates away from the page Yes Untestable Yes Yes Yes Incomplete
  • Firefox on Windows doesn’t display my iframe, so I can’t test it.
  • Opera doesn’t fire the unload event when you navigate Back and Forward. It does when you click on a link.

Equivalent of mousewheel

No Yes No No No No

Only works with addEventListener.

Test IE 5.5 IE 6 IE 7 IE8 IE9 IE10 pr2 FF 7.0 Win FF 6.1 Mac Saf 5.1 Win Saf 5.1 Mac Chrome 14 Win Chrome 13 Mac Opera 11.51 Win Opera 11.51 Mac