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 25338 - D3E spec should recommend that KeyboardEvent.code of some keys whose label are different from PC's keyboard should be mapped from the key labels on Mac keyboard
Summary: D3E spec should recommend that KeyboardEvent.code of some keys whose label ar...
Status: RESOLVED FIXED
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: HISTORICAL - DOM3 Events (show other bugs)
Version: unspecified
Hardware: Macintosh MacOS X
: P2 normal
Target Milestone: ---
Assignee: Gary Kacmarcik
QA Contact: public-webapps-bugzilla
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-04-14 09:19 UTC by Masayuki Nakano
Modified: 2014-05-13 00:28 UTC (History)
3 users (show)

See Also:

Attachments

Description Masayuki Nakano 2014-04-14 09:19:42 UTC 
On Mac, when PC keyboard is corrected, following keys have different label.

Mac                         PC
F13                         PrintScreen
F14                         ScrollLock
F15                         Pause
Help                        Insert *1
Clear                       NumLock

*1 not present on modern Mac keyboard, but there was the key on legacy Mac keyboard, and Sun keyboard's Help key maps kVK_Help

I think that we can ignore "backspace" vs. "delete" because Mac's keyboard also has "delete" key on function block with forward delete key's symbol. I.e., the delete key above return key works really as "Backspace" key.

So, the problem is, if D3E spec undefined whether browsers should map code value from PC's key name or Mac's key name, there will be compatibility problem between browsers.

I believe that browsers on Mac should prefer Mac's keyboard label. The reason is, these keys mentioned above are not work as PC. So, for browser users, they are different keys from PC. Additionally, ordinal Mac users must use Mac's keyboard rather than PC's keyboard.

Therefore, I believe that D3E spec should note this, and browsers should map the keys as:

Mac                         Preferred .code value
F13                         F13
F14                         F14
F15                         F15
Help                        Help
Clear                       Clear
Comment 1 Masayuki Nakano 2014-04-14 09:22:13 UTC 
FYI: Of course, KeyboardEvent.key value should be mapped from actual key's purpose since .key should represent its purpose.
Comment 2 Gary Kacmarcik 2014-04-15 21:15:50 UTC 
This is already working as intended.

There are different USB codes for
   F13-F24 = 68/69/6a
and
   PrintScreen/ScrollLock/Pause = 46/47/48

So they are different keys.

Apparently, the OS (or KVM switch) will map these keys to F13-15 on a Mac, but as far as the spec is concerned, we don't care.  If these keys are reported to the browser as PrintScreen/et al., then they should be encoded as PrintScreen,...  If they come through as F13... then that's how they should be encoded.

In this case, Mac users will see F13,... because the OS (or some other lower component) is translating the PrintScreen into F13.

So this is way beyond the scope of what we need to worry about for this spec.
Comment 3 Masayuki Nakano 2014-04-16 01:24:22 UTC 
Indeed...

On Mac, browsers cannot refer scan code because NSEvent of Cocoa and EventRef of Carbon don't provide it. Instead of that, virtual keycode provided by [NSEvent keyCode] is the only hint.

So, we cannot distinguish F13-F15 and Help. So, using these values to .code must be the best solution.

How about "Clear" case? It uses NumLock ID, IIRC. Should browsers use "NumLock" for "Clear" on Mac?
Comment 4 Masayuki Nakano 2014-04-24 03:59:58 UTC 
Garykac:

Could you check the my last question? I confirmed that Mac's clear key is NumLock key. Only the physical label is different.

So, on Mac, which is better "NumpadClear" vs. "NumLock" on Mac browsers?
Comment 5 Masayuki Nakano 2014-04-24 04:18:45 UTC 
According to the purpose of KeyboardEvent.code, even on Mac, the clear key should be "NumLock". However, I'm not sure if web applications want such behavior.

KeyboardEvent.key of the key on Mac is "Clear". So, even if KeyboardEvent.code is "NumLock" on Mac, it might be OK for web apps.

With those reasons, it might be better to use "NumLock" code value for the key even on Mac. But then, I strongly hope that the table in "6.3.1.4 Numpad Section" should add comment "Clear key on Mac keyboard" into "Notes (Informative)" cell for "NumLock".
Comment 6 Gary Kacmarcik 2014-04-28 04:06:27 UTC 
If "Clear" on the Mac produces the same code as "NumLock", then it would be nice if they were the same.

My only concern is that NumLock implies a state (locked or unlocked) which Clear doesn't have.

Because of this, I think that it's better to have the Mac "Clear" key produce a separate code like "NumpadClear".
Comment 7 Gary Kacmarcik 2014-04-30 00:22:52 UTC 
I'm OK with Mac Clear being the same as NumLock (esp since that's the USB code that it returns).

We still need to keep NumpadClear around for keypad like the following (that Travis found):
http://www.bing.com/images/search?q=microsoft+sculpt+number+pad&FORM=HDRSC2&id=F9469927A0E2504497E3C941499BD5C903520074&selectedIndex=22#view=detail&id=F9469927A0E2504497E3C941499BD5C903520074&selectedIndex=0
Comment 8 Gary Kacmarcik 2014-05-13 00:28:14 UTC 
The Clear/NumLock issue is fixed in https://dvcs.w3.org/hg/dom3events/rev/6c2226898bf9