User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.1 (KHTML, like Gecko) Chrome/22.0.1201.0 Safari/537.1 Steps to reproduce: On a windows XP platform, go to https://bugzilla.mozilla.org/attachment.cgi?id=618602 and hit both CTRL keys one after the other Actual results: Both keys returns the same location as being DOM_KEY_LOCATION_LEFT: keyup: target=<INPUT>, location=DOM_KEY_LOCATION_LEFT keydown: target=<INPUT>, location=DOM_KEY_LOCATION_LEFT keyup: target=<INPUT>, location=DOM_KEY_LOCATION_LEFT keydown: target=<INPUT>, location=DOM_KEY_LOCATION_LEFT Expected results: The right CTRL key location should have been DOM_KEY_LOCATION_RIGHT
Created attachment 641935 [details] [diff] [review] Patch I'll test this patch this weekend if I have much time. But unfortunately, currently, tryserver isn't available, sigh...
(In reply to Masayuki Nakano (:masayuki) (Mozilla Japan) from comment #1) > Created attachment 641935 [details] [diff] [review] > Patch > > I'll test this patch this weekend if I have much time. > > But unfortunately, currently, tryserver isn't available, sigh... For what it's worth, I just tested it and everything works fine so far on my old xp. Thanks for the quick and efficient answer.
Created attachment 642338 [details] [diff] [review] Patch We shouldn't overwrite the mVirtualKeyCode with wrong scancode.
Created attachment 642352 [details] [diff] [review] Patch Jimm, could you review this quickly if you realized this request on the 15th? This patch fix the keycode values for shift/ctrl/alt of NativeKey::mOriginalVirtualKeyCode and NativKey::mVirtualKeyCode. mOriginalVirtualKeyCode must have VK_SHIFT/VK_CONTROL/VK_MENU. mVirtualKeyCode must have VK_LSHIFT/VK_RSHIFT/VK_LCONTROL/VK_RCONTROL/VK_LMENU/VK_RMENU. If the left-right distinguished key code comes, this patch sets VK_SHIFT/VK_CONTROL/VK_MENU manually and does NOT compute the mVirtualKeyCode. Instead of that, it just sets the received keycode to mVirtualKeyCode. If the received keycode isn't one of VK_SHIFT/VK_CONTROL/VK_MENU, this patch does NOT compute the mVirtualKeyCode because the lParam might be broken value if the message is sent/posted by other applications. This patch just set the received keycode to the mVirtualKey in this case too. If the received keycode is one of VK_SHIFT/VK_CONTROL/VK_MENU, this patch computes the left-right distinguished keycode with MapVirtualKeyEx() and scan code in lParam. But if it's impossible on XP or WinServer2003, this patch *guess* the LR difference from the extended key flag if the received keycode is VK_CONTROL or VK_MENU. On the other hand, if the received keycode is VK_SHIFT, always use VK_LSHIFT because both shift keys are not extended keys. So, we have no hint in this case. If the result of MapVirtualKeyEx() isn't indicate the left-right distinguished keycode of the received keycode, this patch *guess* the mVirtualKeyCode with extended key flag. So, this patch supports the generated key messages without scancode this might help compatibility with other utils. And for the conformation of the change, this patch adds the KeyboardEvent.location tests into test_keycodes.xul.
Comment on attachment 642352 [details] [diff] [review] Patch Sorry for the delay. This looks ok overall.
https://hg.mozilla.org/integration/mozilla-inbound/rev/205aaea8796d No problem, this is really my fault and I requested the review in the last weekend. Thanks.