[Webkit-unassigned] [Bug 36364] New: KeyboardEvents -- standards-compliant behavior

[bugzilla-daemon at webkit.org]

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

           Summary: KeyboardEvents -- standards-compliant behavior
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: PC
        OS/Version: All
            Status: UNCONFIRMED
          Severity: Enhancement
          Priority: P2
         Component: HTML DOM
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: ivo.krab at rvponp.fgov.be


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.

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