KeyboardEvent

KeyboardEvent objects describe a user interaction with the keyboard. Each event describes a key; the event type (keydown, keypress, or keyup) identifies what kind of activity was performed.

Method overview

Attributes

Constants

Virtual key codes

Key location constants

These constants describe the location on the keyboard of key events. DOM level 3

Methods

getModifierState()

See KeyboardEvent.getModifierState.

initKeyboardEvent()

Initializes the attributes of a keyboard event object. This method was introduced in draft of DOM Level 3 Events, but deprecated in newer draft. Gecko won't support this feature since implementing this method as experimental broke existing web apps (see bug 999645). Web applications should use constructor instead of this if it's available.

void initKeyboardEvent(
  in DOMString typeArg,
  in boolean canBubbleArg,
  in boolean cancelableArg,
  in views::AbstractView viewArg,
  in DOMString charArg,
  in DOMString keyArg,
  in unsigned long locationArg,
  in DOMString modifiersListArg,
  in boolean repeat
);

Parameters

typeArg

The type of keyboard event; this will be one of keydown, keypress, or keyup.

canBubbleArg

Whether or not the event can bubble.

cancelableArg

Whether or not the event can be canceled.

viewArg

?

charArg

The value of the char attribute.

keyArg

The value of the key attribute.

locationArg

The value of the location attribute.

modifiersListArg

A whitespace-delineated list of modifier keys that should be considered to be active on the event's key. For example, specifying "Control Shift" indicates that the user was holding down the Control and Shift keys when pressing the key described by the event.

repeatArg

The value of the repeat attribute.

There are keydown, keypress, and keyup events. For most keys, Gecko dispatches a sequence of key events like this:

1. When the key is first depressed, the keydown event is sent.
2. If the key is not a modifier key, the keypress event is sent.
3. When the user releases the key, the keyup event is sent.

Special cases

Certain keys toggle the state of an LED indicator, such as Caps Lock, Num Lock, and Scroll Lock. On Windows and Linux, these keys dispatch only the keydown and keyup events. Note that on Linux, Firefox 12 and earlier also dispatched the keypress event for these keys.

On Mac, however, Caps Lock dispatches only the keydown event due to a platform event model limitation. Num Lock had been supported on old MacBook (2007 model and older) but Mac hasn't supported Num Lock feature even on external keyboards in these days. On the old MacBook which has Num Lock key, Num Lock doesn't cause any key events. And Gecko supports Scroll Lock key if an external keyboard which has F14 is connected. However, it generates keypress event. This inconsistent behavior is a bug; see bug 602812.

Auto-repeat handling

When a key is pressed and held down, it begins to auto-repeat. This results in a sequence of events similar to the following being dispatched:

1. keydown
2. keypress
3. keydown
4. keypress
5. <<repeating until the user releases the key>>
6. keyup

This is what the DOM Level 3 specification says should happen. There are some caveats, however, as described below.

Auto-repeat on some GTK environments such as Ubuntu 9.4

In some GTK-based environments, auto-repeat dispatches a native key-up event automatically during auto-repeat, and there's no way for Gecko to know the difference between a repeated series of keypresses and an auto-repeat. On those platforms, then, an auto-repeat key will generate the following sequence of events:

1. keydown
2. keypress
3. keyup
4. keydown
5. keypress
6. keyup
7. <<repeating until the user releases the key>>
8. keyup

In these environments, unfortunately, there's no way for web content to tell the difference between auto-repeating keys and keys that are just being pressed repeatedly.

Auto-repeat handling prior to Gecko 4.0

Before Gecko 4.0 , keyboard handling was less consistent across platforms.

Windows

Auto-repeat behavior is the same as in Gecko 4.0 and later.

Mac

After the initial keydown event, only keypress events are sent until the keyup event occurs; the inter-spaced keydown events are not sent.

Linux

The event behavior depends on the specific platform. It will either behave like Windows or Mac depending on what the native event model does.

Specification

DOM 3 Events: KeyboardEvent

Example

<!DOCTYPE html>
<html>
<head>
<script>
var metaChar = false;
var exampleKey = 16;

function keyEvent(event) {
  var key = event.keyCode || event.which;
  var keychar = String.fromCharCode(key);
  if (key == exampleKey) {
    metaChar = true;
  }
  if (key != exampleKey) {
    if (metaChar) {
      alert("Combination of metaKey + " + keychar);
      metaChar = false;
    } else {
      alert("Key pressed " + key);
    }
  }
}

function metaKeyUp (event) {
  var key = event.keyCode || event.which;

  if (key == exampleKey) {
    metaChar = false;
  }
}
</script>
</head>

<body onkeydown="keyEvent(event)" onkeyup="metaKeyUp(event)">
</body>
</html>

Browser compatibility

*1 The arguments of initKeyboardEvent() of WebKit and Blink's are different from the definition in DOM Level 3 Events. The method is: initKeyboardEvent(in DOMString typeArg, in boolean canBubbleArg, in boolean cancelableArg,  in views::AbstractView viewArg, in DOMString keyIndentifierArg, in unsigned long locationArg, in boolean ctrlKeyArg, in boolean altKeyArg, in boolean shiftKeyArg, in boolean metaKeyArg, in boolean altGraphKeyArg)

*2 Gecko won't support initKeyboardEvent() because supporting it completely breaks feature detection of web applications. See bug 999645.

*3 The argument of initKeyboardEvent() of IE is different from the definition in DOM Level 3 Events. The method is: initKeyboardEvent(in DOMString typeArg, in boolean canBubbleArg, in boolean cancelableArg, in views::AbstractView viewArg, in DOMString keyArg, in unsigned long locationArg, in DOMString modifierListArg, in boolean repeatArt, in DOMString locationArg). See document of initKeyboardEvent() in MSDN.