This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 24739 - [D3E-code] Define code values for the special keys on Sun keyboard
Summary: [D3E-code] Define code values for the special keys on Sun keyboard
Status: RESOLVED FIXED
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: HISTORICAL - DOM3 Events (show other bugs)
Version: unspecified
Hardware: PC Windows NT
: P2 normal
Target Milestone: ---
Assignee: Gary Kacmarcik
QA Contact: public-webapps-bugzilla
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-02-20 03:16 UTC by Masayuki Nakano
Modified: 2015-01-28 01:39 UTC (History)
3 users (show)

See Also:


Attachments

Description Masayuki Nakano 2014-02-20 03:16:43 UTC
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.
Comment 1 Gary Kacmarcik 2014-04-07 21:33:11 UTC
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.
Comment 2 Masayuki Nakano 2014-04-08 01:13:32 UTC
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.
Comment 3 Masayuki Nakano 2014-04-16 06:51:43 UTC
(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'.
Comment 4 Gary Kacmarcik 2014-06-03 17:09:56 UTC
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.
Comment 5 Masayuki Nakano 2014-06-04 10:44:05 UTC
(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.
Comment 6 Masayuki Nakano 2014-06-04 10:49:52 UTC
.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.
Comment 7 Masayuki Nakano 2014-06-17 14:59:29 UTC
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?
Comment 8 Masayuki Nakano 2014-11-13 11:38:43 UTC
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.
Comment 9 Masayuki Nakano 2015-01-14 01:46:15 UTC
We discussed about this:
http://www.w3.org/2014/06/18-webapps-minutes.html
Comment 10 Gary Kacmarcik 2015-01-28 01:39:41 UTC
Per discussion on 27 Jsn's meeting, the 'ContextMenu' and 'Props' code values are sufficient to distinguish the Sun keys.