[Webkit-unassigned] [Bug 30652] New: No key identifier in key events for dead keys

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=30652

           Summary: No key identifier in key events for dead keys
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: Macintosh
        OS/Version: Mac OS X 10.5
            Status: UNCONFIRMED
          Severity: Normal
          Priority: P2
         Component: HTML DOM
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: pub-webkit at coq.no


Related to bug No. 20027

Copy of Apple bug No. 6600446



Summary

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.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.