[Webkit-unassigned] [Bug 15232] New: keyCode/charCode/which not reported correctly

[bugzilla-daemon at webkit.org]

http://bugs.webkit.org/show_bug.cgi?id=15232

           Summary: keyCode/charCode/which not reported correctly
           Product: WebKit
           Version: 522+ (nightly)
          Platform: PC
        OS/Version: All
            Status: UNCONFIRMED
          Severity: Normal
          Priority: P2
         Component: HTML DOM
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: zerodpx at gmail.com
                CC: oliver at apple.com


keyCode/charCode/which are reported differently in every browser (sadly), but
WebCore reports values for these that seem more bogus than most; and Mac and
Windows differ.

Currently, on WebCore (both OSes), the following are true:
* which == keyCode
* For keydown/keyup, keyCode returns the virtual keyCode
* For other cases (notably keypress), keyCode returns charCode

On Mac, when handling keypress, charCode (and thus keyCode and which) returns a
large nonzero value (~65000) for "non-printable" keys like the arrow keys.  On
Windows, these are all reported as 0.  Both behaviors seem questionable.

Here are some behaviors of other browsers:
* On Firefox, for keypress, keyCode is reported as 0 (while which == charCode
!= 0) for most printable characters, and the virtual key code for nonprintable
characters (where which == charCode == 0).  One weird case seems to be the
enter key, which reports which == keyCode == 13, with charCode == 0.
* On Opera, for keypress, charCode is always undefined, keyCode is the
character code for printable characters and the virtual keyCode for
nonprintable characters, and which is the same as in Firefox.
* On IE7, I'm not sure there is a keypress event; for keydown, charCode and
which are undefined, and keyCode is the virtual key code (not the character
code; so 'p' and 'P' are both 80, unlike in Opera).

(Incidentally, the browsers also differ in how they fire events for the meta
keys; Firefox fires (but does not repeat) keydown for shift/ctrl/alt/meta,
while Safari does not fire it.)

Suggested changes:
* Always report 0 for charCode in keydown/keyup
* For keypress, determine whether the key generates printable output; if so,
report keyCode == charCode.  Otherwise report 0 for charCode and the virtual
key code for keyCode.
* Report which as keyCode for keydown/keyup and charCode for keypress, except
for cases where Firefox (or, more accurately, Netscape Navigator 4) reports it
as keyCode during keypress, such as <enter> and <delete>.
* For any event other than keydown/keyup/keypress, report 0 for all of these
(may already be true).

This would make WebKit match Firefox except that it would report a nonzero
value for keyCode for printable characters in keypress, which is what all other
browsers do.


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