Fix CodeForKeyboardEvent to properly calculate the scancode.

Fix CodeForKeyboardEvent to properly calculate the scancode.

Current code just uses the key_event.nativeKeyCode which is copied
from the Windows' lParam. The proper scancode needs to be shifted
and masked out of the lParam (as is done for UsbKeyCodeForKeyboardEvent.

BUG=325015
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=238362

[garykac, 2013-12-03 02:43:37]

I haven't tested this on Windows yet (will do so tomorrow), but this looks like
the culprit.

[Wez, 2013-12-03 03:02:57]

Why would this call all keys to be treated as Escape, though? That suggests
we're returning the wrong thing in the case of no match being found?

https://codereview.chromium.org/100533003/diff/1/content/renderer/pepper/usb_...
File content/renderer/pepper/usb_key_code_conversion_win.cc (right):

https://codereview.chromium.org/100533003/diff/1/content/renderer/pepper/usb_...
content/renderer/pepper/usb_key_code_conversion_win.cc:32: return
key_converter->NativeKeycodeToCode(scancode);
nit: There are equivalent functions in ui/events/keycode, so we should file a
bug to use those directly rather than Pepper having its own copy of this logic.

[garykac, 2013-12-03 03:22:09]

On 2013/12/03 03:02:57, Wez wrote:
> Why would this call all keys to be treated as Escape, though? That suggests
> we're returning the wrong thing in the case of no match being found?

The lower 16 bits of the lParam are the key repeat count, which will most
commonly be set to 1.  A Windows scancode of 1 maps to "Escape".

I believe (but haven't yet tested since I'm at home) If we hold a key down until
it repeats, we'll start seeing a variety of different keys being inserted.

[Wez, 2013-12-03 05:08:38]

lgtm

[commit-bot: I haz the power, 2013-12-03 05:09:36]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/garykac@chromium.org/100533003/1

[commit-bot: I haz the power, 2013-12-03 12:01:55]

Change committed as 238362