Bug 36616 – Dvorak-Qwerty keyboard layout gives unexpected results in javascript keydown

• Status: RESOLVED
• Resolution: FIXED
• Component: WebCore Misc.

[Andrew Pouliot]

Webkit is reporting incorrect key codes to web apps when the meta/command key is down in the dvorak - qwerty command layout.

Steps to reproduce:

1. Enable the "Dvorak - Qwerty <command>" layout in system preferences and switch to it

2. Open test page in Safari

3. Type command-k with the text field selected (hit command and the k key on the keyboard)

console log is :
key pressed. code:84 char:0 meta:true fromCharCode:T keyIdentifier:U+0054 keyLocation:0

expected:
key pressed. code:75 char:0 meta:true fromCharCode:K keyIdentifier:U+004B keyLocation:0

The point of the dvorak-qwerty layout is that it should send qwerty-mapped characters when the command key is held down, otherwise behaving like a dvorak keyboard. This is so that commands are still in their familiar and ergonomic places ie command-c, etc.

The impacts of this bug on dvorak-qwerty users are far and wide, as many websites trap keyboard shortcuts and prevent the default action. Thus, typing command-V, which usually results in a "paste" action can instead trigger whatever is mapped to command-K in the web app.

For a real-world example, try to use the http://stackoverflow.com code editor in this layout.

[Andrew Pouliot]

Created attachment 51671 [details]
Here is the test case

[Andrew Pouliot]

I'm currently looking at KeyEventMac.mm where it creates a PlatformKeyboardEvent from an NSEvent. 

If I print out the NSEvent going into here, I see:

NSEvent: type=KeyDown loc=(0,1158) time=56678.2 flags=0x100108 win=0x0 winNum=13159 ctxt=0x0 chars="k" unmodchars="t" repeat=0 keyCode=40"


In this case, I think the modified chars reflect the intent of the user. There may be other cases like option-e on the mac (dead key), where it might be desirable to send "e"=unmodified rather than ""=modified on to javascript. Does anyone depend on this behavior?

I'm still trying to track down where in code the calculation of the keyCode/keyIdentifier to report to javascript is.

[Andrew Pouliot]

Created attachment 51711 [details]
Test case: logs both keypress and keydown

Now logging both keypress and keydown.

[Andrew Pouliot]

Interesting: it took my reading the source code to realize that the behavior
for keypress is different than that of keydown.

Keydown is working correctly, ie returning k, whereas keydown returns T.

I updated the test case and here are the results for typing command-k:

onkeydown :  code:84 char:0 meta:true fromCharCode:T keyIdentifier:U+0054
keyLocation:0
onkeypress :  code:107 char:107 meta:true fromCharCode:k keyIdentifier:
keyLocation:0

Is keypress the canonical event to use for making keyboard commands, and I
didn't realize it, or is this still a bug with keydown?

In any case, the behavior of keydown is causing problems "in the real world,"
as few developers even are aware of the existence of alternate keyboard
layouts.

[Alexey Proskuryakov]

I think it's a bug with keydown. The code that provides keyCode in keydown is nonsense - we end up with 0 for non-Roman keyboard layouts!

Will need to check IE to be sure that this nonsense isn't expected behavior.

[Alexey Proskuryakov]

Created attachment 52056 [details]
proposed fix

[Alexey Proskuryakov]

Committed <http://trac.webkit.org/changeset/56804>.

[Alexey Proskuryakov]

Created attachment 52082 [details]
regression tests... who would believe?

[Alexey Proskuryakov]

DumpRenderTree fix committed revision 56808.

[Eric Seidel (no email)]

Why can't we use hashmaps for any of this?  These long if-blocks are super ugly, and we're adding more of them. :(

[David Harrison]

This patch is thought to have caused https://bugs.webkit.org/show_bug.cgi?id=37776