Bug 30652 - No key identifier in key events for dead keys
Summary: No key identifier in key events for dead keys
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: DOM (show other bugs)
Version: 528+ (Nightly build)
Hardware: Macintosh OS X 10.5
: P2 Normal
Assignee: Nobody
Keywords: InRadar
Depends on:
Reported: 2009-10-21 16:57 PDT by O. Andersen
Modified: 2010-07-11 09:42 PDT (History)
2 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description O. Andersen 2009-10-21 16:57:06 PDT
Related to bug No. 20027

Copy of Apple bug No. 6600446


keyDown/keyUp events for dead keys (typically combining accents) do not contain (non-null) keyIdentifier, keyCode or which, which makes it impossible to distinguish between different dead keys (and keyboard layouts often have more than one dead key).

(Incidentally, keyPress events are not being produced for dead keys at all, and dead keys do not influence the event corresponding to the subsequently pressed non-dead key.)

Use case 1

Moderately complex keyboard layouts, e.g., based on Greek–Latin transcription schemes, can be demo'd on a Web site or indeed used for input on a Web page.  Unfortunately, the lack of support for dead keys makes this less practical.

<http://øistein.com/russisk/> is an outdated Web page (which still works in Firefox and Opera) that illustrates the underlying idea. Click inside the green box and type ‘jats’ slowly.

Use case 2

<http://coq.no/widget/tastiera/en> is a Dashboard Widget that maps the QWERTY keyboard to keys on a piano. This widget currently employs a work-around: when the widget gets focus, the keyboard layout is changed to US (which contains no dead keys); and when it loses focus, the keyboard layout is changed back to the user's original keyboard layout. However, this is inelegant and brittle; it would be better not to have to do this juggling but instead be able to detect dead keys (or, to put it it differently, to be able to detect any key irrespective of keyboard layout).

For this use case, it would be even nicer to have access to key codes representing the physical keys being pressed and thus invariant with respect to keyboard layout. This is not absolutely essential given that a Dashboard Widget can access keyboard layouts and thus derive the physical key from the corresponding character, but the situation would probably be different for a similar use case using WebKit as a browser.
Comment 1 O. Andersen 2009-11-06 02:28:24 PST
Related: http://lists.w3.org/Archives/Public/www-dom/2009OctDec/0131.html

On the Mac platform, making the equivalent of Cocoa NSEvent keyCode available as an attribute for keydown/keyup should be fairly straightforward and would be useful for Dashboard Widgets even if it does not work on other platforms.  (A cross-platform solution would be even better, of course.)
Comment 2 O. Andersen 2010-07-11 09:42:11 PDT
A partial solution to this has appeared in Safari 5:

1) For non-dead keys, keyIdentifier identifies the corresponding character (as before).

2) For dead keys, keyIdentifier is undefined, but keyCode is now set to the corresponding character on a US keyboard. This makes it easy to identify the key that was pressed (except that the key § on a non-ANSI keyboard has the same keyCode as `).

This works well in the context of a Dashboard Widget, where Objective-C code can be used to detect the current keyboard layout, enabling mapping from keys to characters or vice versa.  For web applications, however, the current mix of character and key identifiers is not ideal; identifying keys and characters separately for all keys would be better.