Re: [D4E] KeyboardEvent.code and KeyboardEvent.queryKeyCap() are very strange spec

My comments re keyCode are based on the prevalent Windows virtual key code
scheme - from what you've described it sounds like you're testing on a
browser that uses that scheme, but on a non-Windows platform for which it
has a buggy implementation of keyCode.

On a Windows system Chrome/WebKit will produce:
- keyCode=49 for both 1 and Shift+1.
- NumPad keys actually do change according to shift state (at the PS/2
level NumLock is actually implemented as a virtual shift state), but
Shift+0 should not produce keyCode=0.
- left & right keys (shift, ctrl, alt) have the same keyCode because
Windows reflects the underlying PS/2 codes, which distinguish them by
setting the "extended" bit for the right one, and not setting it for the
left.
- The backtick behaviour is because it's a dead key in your selected
language layout. The browser should arguably treat that as a special-case
IME, deliver keydown/keyup for the key as normal and provide composition
events for the resulting text.
- Again, the difference between $ unmodified and shifted sounds like a bug
in the browser's emulation of Windows virtual keys for your platform. :(



On 11 March 2013 14:00, Florian Bösch <pyalot@gmail.com> wrote:

> On Mon, Mar 11, 2013 at 9:41 PM, Wez <wez@chromium.org> wrote:
>
>> Which keys are you thinking of?  keyCode changes for some keys based on
>> lock-states (the NumPad keys) but not for shift/ctrl/alt modifier-states..
>>
>
> - the key "1" (above the alphabet) has the keyCode 49, but when I press
> shift+"1" it becomes 187.
> - the key "0" (numpad) has the keyCode 96, but when I press shift+"0" it
> becomes 0
> - left/right shift both have the same keyCode (16)
> - left/right ctrl have the same keyCode (17)
> - main block and numpad "enter" have the same keyCode (13)
> - The backtick key does not trigger a keydown event (`/^), only on the
> second press it does.
> - The $ key is 52 unmodified, but 220 with shift
> - etc. etc.
>