Bug 15232 – keyCode/charCode/which not reported correctly

• Component: DOM
• Status: RESOLVED FIXED

[Peter Kasting]

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.

[Peter Kasting]

Created attachment 16312 [details]
Testcase

Here's a testcase that can be used to see what various browsers report for keypress (or, in IE's case, keydown).

[Erik Arvidsson]

IE has a slightly different semantics but following Gecko seems to be the right thing to do.

IE only fires keypress for events for printable characters. So a you will not get a keypress event for <shift>

IE does not implement which or charCode. It uses keydown/keypress to distinguish printable characters. The keyCode is the same for 'p' and 'P'.

Another annoyance is the way the events repeats when holding down the key is different on different platforms. 

IE: keydown repeat
IE: keypress does not repeat
Gecko on Win32: keydown repeat
Gecko on Win32: keypress does not repeat 
Gecko on Mac: keydown does not repeat
Gecko on Mac: keypress repeat 

[Oliver Hunt]

First up, i'll say this: keyCode and charCode are both ugly -- especially in the context of international input

The key event models used by IE and Firefox are different, and a spent a *long* time a couple of months ago fixing Safari's key event model to maximise compatibility with sites that depend on bizarre firefox behaviour, or the slightly more sane ie model.  Here's the description i sent to the web-api list:

Anyhoo, just for reference the WebKit key press handling is (approximately) as follows:

function handleKeyEvent(event) {
    if (event.isKeyUpEvent) {
        // Fire a DOM KeyUp event
        fireKeyUpEvent(event);
        return;
    }

    // We need to call the input method now as the our behaviour changes according to whether
    // the event was handled by the Input Method
    if (inputMethod.handleEvent(event)) {
        // The event was handled by the Input Method, if the IM would insert/change the current composition as a result
        // of this event then the change has *already* happened
        // A number of sites break under IMs if we just send the correct keyCode for the keyDown for an IM handled event
        // So we set the keyCode to 229, which matches IE :-/
        event.keyCode = 229;
        // Fire a DOM keydown event
        fireKeyDownEvent(event);
        return;
    }

    // Even though the IM has not "handled" the event the content of the text region may have
    // changed (eg. confirmation of a composition with various Korean IMs)
    bool defaultHandled = fireKeyDownEvent(event);
    defaultHandled = fireKeyPressEvent(event) || defaultHandled;
    if (!defaultHandled)
        fireTextInputEvent(event);
}

This behaviour is not something that should be used to standardise on as it has been designed with the goal of website compatibility rather than to be "nice".

Important things to note:
 * preventDefault on KeyDown will *not* prevent KeyPress events from being fired (this matches Firefox behaviour, and is needed for a couple of sites)
 * preventDefault on KeyDown *or*KeyPress will prevent the TextInput event, eg. no text will be inserted
 * autorepeat keys trigger keydown and keypress events (otherwise we break sites that expect keydown for all keyevents)
 * KeyPress and TextInput events are *not* fired if an Input Method has handled the event
 * the keyCode for a KeyDown event that has been handled by the Input Method will be 229, this is needed to not break a number of sites -- might be reducible to only mask the keycode for control keys, but that's difficult to verify.  People do really stupid things on keydown.
 * the Input Method *may* have side effects that occur before any key event has been fired.  This is kind of icky, but matches IE behaviour, but i strongly doubt any sites exist that depend on this behaviour.
 

[David Kilzer (:ddkilzer)]

<rdar://problem/5490408>

[Darin Adler]

(In reply to comment #0)
> 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).

Those sound good to me. The parts that seem most unclear are:

- What does "whether the key generates printable output" mean in practice? It's not obvious to me how to implement that part.
- What exactly are the cases where Netscape Navigator 4 report use keyCode rather than charCode for the value of "which" for keypress?

Ollie, I can't tell whether any of your comments contradict anything here. This bug is about the keyCode/charCode/which values, and I don't think the proposed change conflicts with anything you said.

Erik, your comments about repeating events seem to belong in another bug, since this bug is about the keyCode/charCode/which values, not which events are dispatched.

My biggest concern is that refining this behavior will break existing Dashboard widgets or websites that have adapted to Safari's behavior over the last 5 years.

[Darin Adler]

(In reply to comment #0)
> (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.)

I'd like to see another bug report just about this issue.

> * For any event other than keydown/keyup/keypress, report 0 for all of these
> (may already be true).

Yes, that's already true.

[Oliver Hunt]

I'll note that defining "correctly" is difficult as keyCode/charCode are not defined by any spec.

I'll point out that we do support DOM3's keyIdentifier property which gives you string representations of the key -- eg "U+....", "Left",  "Right", etc...

--Oliver

[Alan Sheinberg]

Well, aside from changing the whole set of keyCodes to be "correct", at the very least it makes sense to have consistent keyCodes between the Windows and Mac versions.  As was pointed out, for non-printable keys on keypress, the two versions produce different keyCodes.  Are there any plans to change this?

[Oliver Hunt]

(In reply to comment #8)
> Well, aside from changing the whole set of keyCodes to be "correct", at the
> very least it makes sense to have consistent keyCodes between the Windows and
> Mac versions.  As was pointed out, for non-printable keys on keypress, the two
> versions produce different keyCodes.  Are there any plans to change this?
> 
The problem with keyCode/charCode is that they are platform specific, there is no "correct" value -- you really are much better off using the DOM3 keyIdentifier property.

That said, yes we do intend to get the two platforms as close as is technically possible, but the fact that keyCode/keyDown is platform (possibly even hardware) specific means that there is no guarantee that it will ever be possible to make the two match exactly.

[Darin Adler]

(In reply to comment #8)
> As was pointed out, for non-printable keys on keypress, the two
> versions produce different keyCodes.  Are there any plans to change this?

It would be helpful to have specific bug reports about particular keys (or sets of keys) that differ between the platform. Should be easy to fix, and would be much easier to understand if expressed that way!

[Oliver Hunt]

(In reply to comment #10)
> (In reply to comment #8)
> > As was pointed out, for non-printable keys on keypress, the two
> > versions produce different keyCodes.  Are there any plans to change this?
> 
> It would be helpful to have specific bug reports about particular keys (or sets
> of keys) that differ between the platform. Should be easy to fix, and would be
> much easier to understand if expressed that way!
> 
A major problem is that (IIRC) we construct key event information for windowless plugins from our internal event representation -- changing the key code could easily break plugins.  Once again i'll try to remind people, keyCode *is* platform specific.

keyCode and charCode also don't account for international input -- you're looking at something that is largely platform dependent, and can easily break your site for international users.

[Alan Sheinberg]

> It would be helpful to have specific bug reports about particular keys (or sets
> of keys) that differ between the platform. Should be easy to fix, and would be
> much easier to understand if expressed that way!
> 

In particular, on Windows, the arrow keys on keypress have keyCode 0 whereas in Mac, they have keyCodes 63232-63235.

I would be happy to file a particular bug for this if necessary.

Thanks,
Alan

[Darin Adler]

(In reply to comment #12)
> > It would be helpful to have specific bug reports about particular keys (or sets
> > of keys) that differ between the platform. Should be easy to fix, and would be
> > much easier to understand if expressed that way!
> 
> In particular, on Windows, the arrow keys on keypress have keyCode 0 whereas in
> Mac, they have keyCodes 63232-63235.
> 
> I would be happy to file a particular bug for this if necessary.

Please do.

[Darin Adler]

(In reply to comment #11)
> A major problem is that (IIRC) we construct key event information for
> windowless plugins from our internal event representation -- changing the key
> code could easily break plugins.  Once again i'll try to remind people, keyCode
> *is* platform specific.

JavaScript keyCode doesn't have to be identical to our internal event representation.

[Alexey Proskuryakov]

We have significantly changed keyboard event processing in current nightly builds to better match IE: <http://lists.webkit.org/pipermail/webkit-dev/2007-December/002992.html>. AFAICT, this fixed most or all issues mentioned in this report - please test whether the new behavior looks right to you, and file new reports for remaining issues and/or newly introduced bugs.