Summary: | Dvorak-Qwerty keyboard layout gives unexpected results in javascript keydown | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Andrew Pouliot <andpoul> | ||||||||||
Component: | WebCore Misc. | Assignee: | Alexey Proskuryakov <ap> | ||||||||||
Status: | RESOLVED FIXED | ||||||||||||
Severity: | Major | CC: | aestes, ap, eric, harrison | ||||||||||
Priority: | P3 | ||||||||||||
Version: | 528+ (Nightly build) | ||||||||||||
Hardware: | Mac | ||||||||||||
OS: | OS X 10.6 | ||||||||||||
Attachments: |
|
Description
Andrew Pouliot
2010-03-25 12:47:38 PDT
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 |