Bug 36364

Summary: KeyboardEvents -- standards-compliant behavior
Product: WebKit Reporter: Ivo Krab <ivo.krab>
Component: DOMAssignee: Nobody <webkit-unassigned>
Status: UNCONFIRMED ---    
Severity: Enhancement CC: ap, rniwa
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: PC   
OS: All   

Description Ivo Krab 2010-03-19 06:54:36 PDT
This is a separated thread to discuss the issue I raised in https://bugs.webkit.org/show_bug.cgi?id=16735

I repeat my comment:
> I did not quite follow the whole discussion or dig into the code, but is it
> foreseen that dispatching a "keydown" also fires the corresponding "keypress"
> if the keyIdentifier warrants it (if a visible character is typed as a result
> of the keydown). The standard does not foresee to be able to dispatch
> "keypress" as a separate event, but one should result in the other (if
> preventDefault is not called from a keyDown handler).

Darin Adler replied:

>Sounds logical but:
>
>    1) Not really the same thing as this bug, so not clear it should be
>discussed here.
>
>   2) Does not match other browsers’ behavior so could lead to
>incompatibilities.

>We tried a while back to have keydown events dispatch keypress events in their
>default event handlers but found this is not how any other browser behaves.
>Lets discuss this

Concerning point 2:
Yes, other browsers behave differently, but I don't know of any that have a usable implementation of creating and dispatching DOM KeyboardEvents, let alone a standards-compliant one.
What we currently have in other browsers are non-standard methods, in which the way to initialize the event is to explicitly set the keyCode, charCode etc.
Webkit takes the road of making these read-only in the event (which is the reason for bug 16735, currently it is IMPOSSIBLE to dispatch a newly created key event that makes any sense). I can sympathise with that approach if 16735 gets fixed, because standard way is the future, and the standards way is to let the browser decide what the value of keyCode and charCode should be, dependent on the effect you wish to achieve, i.e. the result char or key action, as indicated by the keyIdentifier.

Still, the standard also clearly indicates that keypress should not be fired as a separate event. Earlier versions of the DOM-L3 draft did not even describe it, the recent versions (http://www.w3.org/TR/DOM-Level-3-Events/#events-keyboardevents) do mention it, but as "Deprecated".
However, as long as an actual physical key press fires a "keypress" after the "keydown", a despatched created "keydown" event should do likewise IMHO, since the "keypress" is always the consequence of the "keydown" and is NOT issued if a "keydown" event handler calls preventDefault.

Let the other browsers with their nonstandard methods of firing key events (FF "KeyEvent" interface, IE fireEvent("onkeyxxx") of an anonymous event object with settable keyCode) continue on the way of no consequence to firing a "keydown". Webkit chose not to emulate these, but with the standard being correctly implemented, all normal consequences of dispatching an event, including subsequential events, should be generated.
Comment 1 Alexey Proskuryakov 2010-03-19 08:47:12 PDT
It's not correct that keypress is always a consequence of keydown. On Windows, any process can send a WM_CHAR message to the browser, which will result in only keypress being dispatched.

Generating a keypress from a programmatically created keydown is technically possible, but it would introduce lots of unexpected edge case behaviors. That's because we'd need to call back into OS keyboard event handling code to process the raw keydown. On different OSes, we'd get some or all of issues:

- it would be possible to control the browser by dispatching e.g. Cmd+Q;
- event queue would be out of sync, so stateful input methods (inline input, or just dead keys for plain keyboards) will be confused;
- since processing a raw keydown with an input method frequently pops up additional UI elements, and runs a nested event loop, we'd get stuck in these.