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.
Created attachment 51671 [details] Here is the test case
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.
Created attachment 51711 [details] Test case: logs both keypress and keydown Now logging both keypress and keydown.
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.
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.
Created attachment 52056 [details] proposed fix
Committed <http://trac.webkit.org/changeset/56804>.
Created attachment 52082 [details] regression tests... who would believe?
DumpRenderTree fix committed revision 56808.
Why can't we use hashmaps for any of this? These long if-blocks are super ugly, and we're adding more of them. :(
This patch is thought to have caused https://bugs.webkit.org/show_bug.cgi?id=37776