This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
As I tested with Sun's Japanese USB keyboard, special keys use following code: Printed key name USB Usage ID Page 0x07 Name in USB-HID spec Help 0x75 Help Stop 0x78 Stop Again 0x79 Again Props 0x76 Menu Undo 0x7A Undo Front 0x77 Select Copy 0x7C Copy Open 0x74 Execute Paste 0x7D Paste Find 0x7E Find Cut 0x7B Cut FYI: following keys are using a value which is used by normal JIS keyboard. 確定(Kakutei) 0x8B Intl5 変換(Henkan) 0x8A Intl4 日本語(Nihongo) On Off 0x88 Intl2 Compose 0x65 Application かな(Kana) 0x40 Right-Alt See bug 23751 comment 4 for the mapping to keysym on GTK.
This has been fixed: Already existing UI keys: 'Help', 'Again', 'Props', 'Find' Already existing Editing keys: 'Undo', 'Copy', 'Cut', 'Paste' Already existing Multimedia keys: 'Open' 'Menu' should use 'ContextMenu' 'Select' has just been added (bug 23751) 'Stop' could be either 'MediaStop' or 'BrowserStop', depending on what makes more sense. I'd rather not add a new 'Stop' button since that would add confusion.
Hmm, sounds odd to me to share code values between Sun keyboard's special keys and multimedia keyboard's keys because I understand that code attribute represents *physical" key. I'm trying to implement KeyboardEvent.code on Firefox. Therefore, if I'd find problem with this approach, I'd reopen this bug.
(In reply to Gary Kacmarcik from comment #1) > This has been fixed: > > Already existing UI keys: > 'Help', 'Again', 'Props', 'Find' No, they are no defined as .code value except 'Help'. > Already existing Editing keys: > 'Undo', 'Copy', 'Cut', 'Paste' Same. > Already existing Multimedia keys: > 'Open' Same. > 'Menu' should use 'ContextMenu' Hmm, on Linux, the key code of X11 distinguishes the 'ContextMenu' key between 'OSRight' and 'CtrlRight'. I don't think that it should not be shared same code name between 2 physical keys. > 'Select' has just been added (bug 23751) No, not into .code. > 'Stop' could be either 'MediaStop' or 'BrowserStop', depending on what makes > more sense. I'd rather not add a new 'Stop' button since that would add > confusion. I confirmed that the 'Stop' button of Sun keyboard is same as 'BrowserStop' of multimedia keyboard. So, you don't need to add 'Stop'.
These key values (except for 'Menu') have been added in https://dvcs.w3.org/hg/dom3events/rev/30e57b6dfe37 For the code values, we identify the keys by position for the "writing system keys" and by function for the other keys. Since the Sun 'Menu' key serves the same purpose as the 'ContextMenu' key, it should be encoded as 'ContextMenu'. Also, having a generic 'Menu' key would be confusing since it might be misinterpreted as the standard key labeled "Menu". If we need to add another one, then we'd need to have a prefix that distinguishes it from the other "menu" keys.
(In reply to Gary Kacmarcik from comment #4) > For the code values, we identify the keys by position for the "writing > system keys" and by function for the other keys. Since the Sun 'Menu' key > serves the same purpose as the 'ContextMenu' key, it should be encoded as > 'ContextMenu'. Hmm, I don't like your idea "by function for the other keys" because such definition makes browsers need to compute code value with virtual keycode (or keysym) and it may depend on modifier state. However, I believe that you meant "by original function expected by keyboard vendor for the other key". Then, I can agree with your idea. > Also, having a generic 'Menu' key would be confusing since it might be > misinterpreted as the standard key labeled "Menu". If we need to add another > one, then we'd need to have a prefix that distinguishes it from the other > "menu" keys. Wait, you took a mistake. "Menu" key of USB HID is labeled "Props". So, as you said, it should be "ContextMenu" value for .code, "Props" value should be removed from the table. -> REOPEN for the latter issue.
.code value USB HID name Label on Sun keyboard BrowserStop Stop Stop Again Again Again ContextMenu Menu Props Undo Undo Undo Select Select Front Copy Copy Copy Open Execute Open Paste Paste Paste Find Find Find Cut Cut Cut I believe this is the mapping table you expected.
Oh, wait. I realized that if KeyboardEvent.code value will be used for an argument of new API in UI Events or something, two or more physical keys on a physical keyboard should not be mapped to a code value. For example, if D4E will define a new API which can query a good localized label for a physical key like KeyboardEvent.getLocalizedLabel(DOMString codeArg), Garykac's idea of .code value of non-printable keys is not useful. Sun keyboard's "Props" key and "ContextMenu" key cause different .key value in default settings of Ubuntu and Fedora. Therefore, such new API should be able to distinguish the keys with independent .code value. How do you think about this issue?
Gary: Could you fix this bug? Only this spec bug blocks to enable KeyboardEvent.code on Firefox. So, we would be happy if you fix this bug.
We discussed about this: http://www.w3.org/2014/06/18-webapps-minutes.html
Per discussion on 27 Jsn's meeting, the 'ContextMenu' and 'Props' code values are sufficient to distinguish the Sun keys.