chrome.input.ime sends invalid key names for USB keyboard keys |
||
Issue descriptionGoogle Chrome 65.0.3325.209 (Official Build) (64-bit) Platform 10323.67.0 (Official Build) stable-channel panther What steps will reproduce the problem? (1) In a chrome.input.ime.onKeyEvent listener, log `key` property of incoming events to the console. (2) Install the IME extension from (1) and activate its input method. (3) Attach a 104-key USB keyboard. (3) Press the Delete, Insert, PrintScreen, ScrollLock, Pause, ContextMenu, and Escape keys. What is the expected result? The value of the `key` property should follow the specification at https://www.w3.org/TR/uievents-key/. What happens instead? The Delete key is encoded as the string '\u007f' instead of 'Delete'. The Escape key is encoded as 'Esc' instead of 'Escape'. The Insert, PrintScreen, ScrollLock, Pause, and ContextMenu have the `key` property set to the empty string.
,
Apr 10 2018
Related: https://crbug.com/826538 covers well-formed but incorrect key names.
,
Apr 10 2018
Correction: Insert, PrintScreen, ScrollLock, Pause, and ContextMenu have the `key` property set to a non-empty string containing the null byte ('\u0000').
,
Apr 10 2018
This also applies to the Home, End, PageUp, PageDown, MetaLeft, and MetaRight keys.
,
Apr 10 2018
And the MediaPlayPause key, but (oddly) not other media keys (for example, AudioVolumeUp seems to send the correct key name).
,
Apr 10 2018
NumLock also sends the null byte. And for some reason, NumpadEnter sends '\r' instead of 'Enter'.
,
Sep 11
|
||
►
Sign in to add a comment |
||
Comment 1 by bcmi...@google.com
, Apr 10 2018