865649 - Implement KeyboardEvent.code (only for physical keyboard)

Status: RESOLVED FIXED

(Core :: DOM: Events, defect)

Description

[Mounir Lamouri (:mounir)]

Basically, it would work like .key but without applying the modifiers, see $URL.

Comment 1

[Mounir Lamouri (:mounir)]

https://dvcs.w3.org/hg/d4e/raw-file/tip/source_respec.htm#widl-KeyboardEvent-code

Comment 2

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=24740
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24739

These spec bugs should be fixed before I work on this.

Comment 3

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

And also, https://www.w3.org/Bugs/Public/show_bug.cgi?id=25229

Comment 4

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: part.1 Implement KeyboardEvent.code (WIP?)

Comment 5

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: part.2 Set KeyboardEvent.code value on Windows (WIP)

Comment 6

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

test build:
https://tbpl.mozilla.org/?tree=Try&usebuildbot=1&rev=80f82a76b11f

Comment 7

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: part.2 Set KeyboardEvent.code value on Windows

Some keys are supported only with virtual keycodes, without scancode...

Comment 8

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: part.1 Implement KeyboardEvent.code (WIP?)

Comment 9

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: part.3 Set KeyboardEvent.code value on Mac (WIP?)

Comment 10

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

https://tbpl.mozilla.org/?tree=Try&usebuildbot=1&rev=fde7de9aeb9a

Comment 11

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: part.3 Set KeyboardEvent.code value on Mac (WIP?)

Comment 12

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: part.1 Implement KeyboardEvent.code (WIP?)

Comment 13

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: part.2 Set KeyboardEvent.code value on Windows

Comment 14

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: part.3 Set KeyboardEvent.code value on Mac

Comment 15

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: part.4 Set KeyboardEvent.code value on Linux (WIP)

Comment 16

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: part.5 Set KeyboardEvent.code value on Android and Firefox OS (WIP)

Comment 17

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

TODO:

* Support special keys on Sun keyboard
* Fix NumLock vs Clear on Mac.
* Test Android version with USB connected keyboards (I've tested via Bluetooth converter of USB HID).
* Needs to investigate Android's scancode of F3 - F5 and NoConvert, Convert and Katakana/Hiragana of PC keyboard, Eisu and Kana of Mac keyboard.

Comment 18

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

This bug should support only physical keyboard. For virtual keycode or a11y tools which don't generate proper key event whose scancode is invalid, we need more work.

Comment 19

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: part.1 Implement KeyboardEvent.code

Okay, let's go forward.

* These patches don't support special keys on Sun keyboard. I'll file follow up bugs after they are defined in the spec.
* These patches don't support key events which are synthesized with not proper scancode (Windows) or hardware_keycode (X11). And also don't support virtual keyboard on Android for now.

Comment 20

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: part.2 Set KeyboardEvent.code value on Windows

Please review each patches which set .code value in widget roughly. I'll request additional review to each widget reviewer.

Comment 21

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: part.3 Set KeyboardEvent.code value on Mac

On Mac, it's too difficult to get scancode or USB HID Usage ID. So, we should use virtual keycode, instead...

Comment 22

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: part.4 Set KeyboardEvent.code value on Linux

GTK and Qt widget must be able to share the code.

Comment 23

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: part.5 Set KeyboardEvent.code value on Android and Firefox OS

Similarly, Android and Gonk must be able to share the scancode -> .code value mapping.

Comment 24

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

FYI: The .code spec is here:
https://dvcs.w3.org/hg/dom3events/raw-file/tip/html/DOM3-Events.html#keys-codevalues
The code values are defined in:
https://dvcs.w3.org/hg/dom3events/raw-file/tip/html/DOM3Events-code.html

KeyboardEvent.code represents the physical key. So, it must dependent on neither modifier state nor user selected keyboard layout.

Comment 25

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Test builds here:
https://tbpl.mozilla.org/?tree=Try&usebuildbot=1&rev=d18e11f6664f

Comment 26

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

I wrote a document in MDN:
https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent.code

Comment 27

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: part.1 Implement KeyboardEvent.code

Updating for https://www.w3.org/Bugs/Public/show_bug.cgi?id=25603

Comment 28

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: part.2 Set KeyboardEvent.code value on Windows

Comment 29

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: part.3 Set KeyboardEvent.code value on Mac

Comment 30

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: part.4 Set KeyboardEvent.code value on Linux

Comment 31

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: part.5 Set KeyboardEvent.code value on Android and Firefox OS

https://tbpl.mozilla.org/?tree=Try&usebuildbot=1&rev=fd39a31ad299

Comment 32

[Olli Pettay [:smaug][[e-mail]]]

Sorry about delay with this stuff. Not too easy to review and I've had easier-to-review patches in my
queue. But reviews are coming...

Comment 33

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 8421557 [details] [diff] [review]
part.1 Implement KeyboardEvent.code

>+DEFINE_PHYSICAL_KEY_CODE_NAME_WITH_SAME_NAME(Convert)
>+DEFINE_PHYSICAL_KEY_CODE_NAME_WITH_SAME_NAME(KanaMode)
>+DEFINE_PHYSICAL_KEY_CODE_NAME_WITH_SAME_NAME(Lang1)
>+DEFINE_PHYSICAL_KEY_CODE_NAME_WITH_SAME_NAME(Lang2)
>+DEFINE_PHYSICAL_KEY_CODE_NAME_WITH_SAME_NAME(Lang3)
>+DEFINE_PHYSICAL_KEY_CODE_NAME_WITH_SAME_NAME(Lang4)
>+DEFINE_PHYSICAL_KEY_CODE_NAME_WITH_SAME_NAME(Lang5)
I don't see Lang* in the spec, and there is HangulMode and Hanja
>+DEFINE_PHYSICAL_KEY_CODE_NAME_WITH_SAME_NAME(MediaPlayPause)
>+DEFINE_PHYSICAL_KEY_CODE_NAME_WITH_SAME_NAME(MediaSelect)
>+DEFINE_PHYSICAL_KEY_CODE_NAME_WITH_SAME_NAME(MediaStop)
>+DEFINE_PHYSICAL_KEY_CODE_NAME_WITH_SAME_NAME(MediaTrackNext)
>+DEFINE_PHYSICAL_KEY_CODE_NAME_WITH_SAME_NAME(MediaTrackPrevious)
Looks like the spec has changed a bit.
MediaNextTract, MediaPreviousTrack

>+// Legacy keys
>+DEFINE_PHYSICAL_KEY_CODE_NAME_WITH_SAME_NAME(Abort)
>+DEFINE_PHYSICAL_KEY_CODE_NAME_WITH_SAME_NAME(Hyper)
>+DEFINE_PHYSICAL_KEY_CODE_NAME_WITH_SAME_NAME(Meta)
Hmm, so Meta shouldn't be used as .code, but OSLeft should be used


How stable is this stuff in the spec.
Perhaps we should add a Pref to the KeyboardEvent.webidl code attribute and
do some testing with various keyboards and OSes, and only then enable it.

Comment 34

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 8421558 [details] [diff] [review]
part.2 Set KeyboardEvent.code value on Windows

>+// Media keys
>+// CODE_MAP_WIN(BrowserBack,               0xE000) // VK_BROWSER_BACK
>+
>+// CODE_MAP_WIN(BrowserFavorites,          0xE000) // VK_BROWSER_FAVORITES
>+
>+// CODE_MAP_WIN(BrowserForward,            0xE000) // VK_BROWSER_FORWARD
>+
>+// CODE_MAP_WIN(BrowserHome,               0xE000) // VK_BROWSER_HOME
>+
>+// CODE_MAP_WIN(BrowserRefresh,            0xE000) // VK_BROWSER_REFRESH
>+
>+// CODE_MAP_WIN(BrowserSearch,             0xE000) // VK_BROWSER_SEARCH
>+
>+// CODE_MAP_WIN(BrowserStop,               0xE000) // VK_BROWSER_STOP
>+
>+// CODE_MAP_WIN(Eject) // not available?
>+
>+// CODE_MAP_WIN(LaunchApp1,                0xE000) // VK_LAUNCH_APP1
>+
>+// CODE_MAP_WIN(LaunchApp2,                0xE000) // VK_LAUNCH_APP2
>+
>+// CODE_MAP_WIN(LaunchMail,                0xE000) // VK_LAUNCH_MAIL
>+
>+// CODE_MAP_WIN(MediaPlayPause,            0xE000) // VK_MEDIA_PLAY_PAUSE
>+
>+// CODE_MAP_WIN(MediaSelect,               0xE000) // VK_LAUNCH_MEDIA_SELECT
>+
>+// CODE_MAP_WIN(MediaStop,                 0xE000) // VK_MEDIA_STOP
>+
>+// CODE_MAP_WIN(MediaTrackNext,            0xE000) // VK_MEDIA_NEXT_TRACK
>+
>+// CODE_MAP_WIN(MediaTrackPrevious,        0xE000) // VK_MEDIA_PREV_TRACK
Why these all are commented out? Please add some comment that we special case stuff in ConvertScanCodeToCodeNameIndex

Comment 35

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 8421559 [details] [diff] [review]
part.3 Set KeyboardEvent.code value on Mac

rs+
This like other widget/* need a peer review.

Comment 36

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

(In reply to Olli Pettay [:smaug] from comment #33)
> Comment on attachment 8421557 [details] [diff] [review]
> part.1 Implement KeyboardEvent.code
> 
> >+DEFINE_PHYSICAL_KEY_CODE_NAME_WITH_SAME_NAME(Convert)
> >+DEFINE_PHYSICAL_KEY_CODE_NAME_WITH_SAME_NAME(KanaMode)
> >+DEFINE_PHYSICAL_KEY_CODE_NAME_WITH_SAME_NAME(Lang1)
> >+DEFINE_PHYSICAL_KEY_CODE_NAME_WITH_SAME_NAME(Lang2)
> >+DEFINE_PHYSICAL_KEY_CODE_NAME_WITH_SAME_NAME(Lang3)
> >+DEFINE_PHYSICAL_KEY_CODE_NAME_WITH_SAME_NAME(Lang4)
> >+DEFINE_PHYSICAL_KEY_CODE_NAME_WITH_SAME_NAME(Lang5)
> I don't see Lang* in the spec, and there is HangulMode and Hanja

https://dvcs.w3.org/hg/dom3events/raw-file/tip/html/DOM3Events-code.html#table-key-code-alphanumeric-functional-2

Don't you refer older draft or key value spec? In the key value spec, there are HangulMode and Hanja, but not Lang*.

> >+DEFINE_PHYSICAL_KEY_CODE_NAME_WITH_SAME_NAME(MediaPlayPause)
> >+DEFINE_PHYSICAL_KEY_CODE_NAME_WITH_SAME_NAME(MediaSelect)
> >+DEFINE_PHYSICAL_KEY_CODE_NAME_WITH_SAME_NAME(MediaStop)
> >+DEFINE_PHYSICAL_KEY_CODE_NAME_WITH_SAME_NAME(MediaTrackNext)
> >+DEFINE_PHYSICAL_KEY_CODE_NAME_WITH_SAME_NAME(MediaTrackPrevious)
> Looks like the spec has changed a bit.
> MediaNextTract, MediaPreviousTrack

https://dvcs.w3.org/hg/dom3events/raw-file/tip/html/DOM3Events-code.html#code-MediaTrackNext

> >+// Legacy keys
> >+DEFINE_PHYSICAL_KEY_CODE_NAME_WITH_SAME_NAME(Abort)
> >+DEFINE_PHYSICAL_KEY_CODE_NAME_WITH_SAME_NAME(Hyper)
> >+DEFINE_PHYSICAL_KEY_CODE_NAME_WITH_SAME_NAME(Meta)
> Hmm, so Meta shouldn't be used as .code, but OSLeft should be used

Oh, I'll file a spec bug about this. (This value is not used by us)

> How stable is this stuff in the spec.
> Perhaps we should add a Pref to the KeyboardEvent.webidl code attribute and
> do some testing with various keyboards and OSes, and only then enable it.

I think that KeyboardEvent.code value spec is enough stable at least for physical keyboard. Although, there are some minor bugs.

If we would disable the feature, wouldn't nobody test this feature on various keyboard and OSes?

FYI: All mapping in the patches from ScanCode is, I tested with a lot of keyboard including programmable keyboard. Therefore, for more testing, I believe that it should be enabled in default prefs for more feedback. Fortunately, next ESR is 31, so, even if we will change something about this, it shouldn't cause breaking the web. And if it would become unstable by being found some critical bugs, we could disable at that time.

Do you still think we should disable .code in default prefs? There is another option, it could be changed by a pref but should be enabled in default settings.

Comment 37

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 8421560 [details] [diff] [review]
part.4 Set KeyboardEvent.code value on Linux

rs+

Comment 38

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 8421561 [details] [diff] [review]
part.5 Set KeyboardEvent.code value on Android and Firefox OS

rs+

Comment 39

[Olli Pettay [:smaug][[e-mail]]]

(In reply to Masayuki Nakano (:masayuki) (Mozilla Japan) from comment #36)
> Don't you refer older draft or key value spec? In the key value spec, there
> are HangulMode and Hanja, but not Lang*.
Ah, yes, I was using the link in this bug comment 1


> If we would disable the feature, wouldn't nobody test this feature on
> various keyboard and OSes?
I was thinking some internal testing. But if the spec is stable enough, perhaps we can
just keep the API on, at least in Nightlies.

> Do you still think we should disable .code in default prefs? There is
> another option, it could be changed by a pref but should be enabled in
> default settings.
Yeah, could we perhaps get one extra Nightly cycle for testing. So enable for 32 Nightly, 
and for 33 everywhere?

Comment 40

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

(In reply to Olli Pettay [:smaug] from comment #39)
> (In reply to Masayuki Nakano (:masayuki) (Mozilla Japan) from comment #36)
> > Do you still think we should disable .code in default prefs? There is
> > another option, it could be changed by a pref but should be enabled in
> > default settings.
> Yeah, could we perhaps get one extra Nightly cycle for testing. So enable
> for 32 Nightly, 
> and for 33 everywhere?

Ah, it's reasonable. Does "dom.keyboardevent.code" sound good to you?

Comment 41

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

oops, perhaps, "dom.keyboardevent.code.enabled". Anyway, I'll post new patch which includes fix of new tests and request review again.

Comment 42

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: part.1 Implement KeyboardEvent.code

Adding a pref, "dom.keyboardevent.code.enabled" and it's referred by the new tests.

Comment 43

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: part.2 Set KeyboardEvent.code value on Windows (r=smaug)

This patch maps KeyboardEvent.code value which represents physical key with scancode. I confirmed the scancode values on Win8.1 and a lot of types of keyboards.

This patch doesn't support key events which are synthesized by something like a11y tools *without* proper scancode value. I'll file a follow up bug for it.

Comment 44

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: part.3 Set KeyboardEvent.code value on Mac (r=smaug)

This patch maps KeyboardEvent.code value which represents physical key with virtual keycode value.

On Mac, there is no way to get scancode of an NSEvent. Therefore, we cannot implement this strictly. E.g., on Mac, we cannot distinguish F13, F14, F15 vs. PrintScreen, ScrollLock, Pause since the PC keyboard's keys are mapped to F13 - F15.

FYI: clear key on numpad is same key as NumLock in USB spec. Therefore, clear key is mapped to "NumLock". See also the spec:
https://dvcs.w3.org/hg/dom3events/raw-file/tip/html/DOM3Events-code.html#code-NumLock

Comment 45

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: part.4 Set KeyboardEvent.code value on Linux (r=smaug)

This patch maps KeyboardEvent.code value which represents physical key with GdkEventKey::hardware_keycode on GTK. I confirmed all values of them are Ubuntu 14.04 (VM on Windows) and Fedora 20 (on physical machine) with a lot of types of keyboards.

I assume that Qt's scancode is same as the hardware_keycode of GDK. However, I cannot confirm it because I've not succeeded to build with Qt on my environment.

I'm not familiar with X11's scancode spec. If you know complete table of scancode, let me know it.

Comment 46

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: part.5 Set KeyboardEvent.code value on Android and Firefox OS (r=smaug)

This patch maps KeyboardEvent.code value which represents physical key with scancode.

I assume that Android and Gonk's scancode values are same. I confirmed the scancode values on Android 4.4 with a lot of types of keyboards.

This patch does NOT support virtual keyboard if it doesn't set scancode. I'll file a follow up bug at least for Android (I cannot confirm how this patch work on Firefox OS...).

Comment 47

[(inactive) Jim Chen [:jchen] [:darchons]]

Comment on attachment 8426095 [details] [diff] [review]
part.5 Set KeyboardEvent.code value on Android and Firefox OS (r=smaug)

Review of attachment 8426095 [details] [diff] [review]:
-----------------------------------------------------------------

Android part looks okay.

::: widget/shared/NativeKeyToDOMCodeName.h
@@ +53,5 @@
>  // Writing system keys
>  CODE_MAP_WIN(Backquote,                 0x0029)
>  CODE_MAP_MAC(Backquote,                 kVK_ANSI_Grave)
>  CODE_MAP_X11(Backquote,                 0x0031)
> +CODE_MAP_ANDROID(Backquote,             0x0029)

What's the source for these values? The Android documentation for getScanCode() says "These values are not reliable and vary from device to device."

Comment 48

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

(In reply to Jim Chen [:jchen :nchen] from comment #47)
> Comment on attachment 8426095 [details] [diff] [review]
> part.5 Set KeyboardEvent.code value on Android and Firefox OS (r=smaug)
> 
> Review of attachment 8426095 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> Android part looks okay.
> 
> ::: widget/shared/NativeKeyToDOMCodeName.h
> @@ +53,5 @@
> >  // Writing system keys
> >  CODE_MAP_WIN(Backquote,                 0x0029)
> >  CODE_MAP_MAC(Backquote,                 kVK_ANSI_Grave)
> >  CODE_MAP_X11(Backquote,                 0x0031)
> > +CODE_MAP_ANDROID(Backquote,             0x0029)
> 
> What's the source for these values? The Android documentation for
> getScanCode() says "These values are not reliable and vary from device to
> device."

Thank you for your review.

I picked them up with actual behavior of my environment. Nexus 7 (2013) with USB-Bluetooth adapter and a lot of keyboards, and also connected the keyboards directly with USB (via USB host adapter).

Comment 49

[Karl Tomlinson (:karlt back Feb 10)]

Comment on attachment 8426092 [details] [diff] [review]
part.4 Set KeyboardEvent.code value on Linux (r=smaug)

(In reply to Masayuki Nakano (:masayuki) (Mozilla Japan) from comment #45)
> This patch maps KeyboardEvent.code value which represents physical key with
> GdkEventKey::hardware_keycode on GTK. I confirmed all values of them are
> Ubuntu 14.04 (VM on Windows) and Fedora 20 (on physical machine) with a lot
> of types of keyboards.

> I'm not familiar with X11's scancode spec. If you know complete table of
> scancode, let me know it.

I think most modern Linux systems will get these from
http://cgit.freedesktop.org/xkeyboard-config/tree/keycodes/evdev

If you look at other files in that directory, you'll notice that the codes can
vary.  I suspect the 4-char code (e.g. TLDE) would be the ideal thing to map.
That can be obtained (on systems with XKB) with XkbGetNames() from
_XkbNamesRec::keys, which seems to be a pointer to an array indexed by key
code.  However, that's probably usually unnecessarily complex.

Given this is working on Ubuntu and Fedora systems, it seems a sensible first
implementation at least.

Comment 50

[Karl Tomlinson (:karlt back Feb 10)]

(In reply to Karl Tomlinson (needinfo?:karlt) from comment #49)
> That can be obtained (on systems with XKB) with XkbGetNames() from
> _XkbNamesRec::keys, which seems to be a pointer to an array indexed by key
> code.  However, that's probably usually unnecessarily complex.

Just for reference:
http://www.x.org/releases/current/doc/libX11/XKB/xkblib.html#The_XkbNamesRec_Structure

Comment 51

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Thank you, Karl, for the information and review.

Indeed, I don't want too complicated implementation for rare environment. However, if it would be a problem for some users, we should discuss about that.

Comment 52

[Michael Wu [:mwu]]

Do you have a Nexus 4 or Nexus 5? We have images available for those devices if you want to test B2G there - you just need a USB OTG cable to hook up your keyboard. Alternately, I can test this for you if you have a test page.

Comment 53

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

(In reply to Michael Wu [:mwu] from comment #52)
> Do you have a Nexus 4 or Nexus 5? We have images available for those devices
> if you want to test B2G there - you just need a USB OTG cable to hook up
> your keyboard. Alternately, I can test this for you if you have a test page.

I don't have both of them. Would you check it?

Test pages are here:
editable: https://dvcs.w3.org/hg/d4e/raw-file/tip/key-event-test.html
read-only: http://www.d-toybox.com/samples/key-event-test-on-readonly.html

.code value spec is here:
https://dvcs.w3.org/hg/dom3events/raw-file/tip/html/DOM3Events-code.html

The value doesn't depend on OS's active keyboard layout. It represents physical keyboard's key.

On the former, IME works. Therefore, I guess the latter is useful for testing Firefox OS.

A try build will be here:
https://tbpl.mozilla.org/?tree=Try&usebuildbot=1&rev=70f94bec3a36

Comment 54

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

(In reply to Masayuki Nakano (:masayuki) (Mozilla Japan) from comment #53)
> (In reply to Michael Wu [:mwu] from comment #52)
> A try build will be here:
> https://tbpl.mozilla.org/?tree=Try&usebuildbot=1&rev=70f94bec3a36

Hmm, the binary image isn't uploaded...

Comment 55

[Michael Wu [:mwu]]

Comment on attachment 8426095 [details] [diff] [review]
part.5 Set KeyboardEvent.code value on Android and Firefox OS (r=smaug)

Thanks for the info. I tested the patches on a Nexus 5 and the test page seems to indicate correct behavior.

Comment 56

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Thank you, Smaug, jimm, Steven, Karl, romaxa, nchen and Michael!

https://hg.mozilla.org/integration/mozilla-inbound/rev/944b88892f77
https://hg.mozilla.org/integration/mozilla-inbound/rev/d9eedf819c0d
https://hg.mozilla.org/integration/mozilla-inbound/rev/8c46fe36d7dd
https://hg.mozilla.org/integration/mozilla-inbound/rev/92bbe2efd172
https://hg.mozilla.org/integration/mozilla-inbound/rev/91af45ec6288

Comment 57

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/944b88892f77
https://hg.mozilla.org/mozilla-central/rev/d9eedf819c0d
https://hg.mozilla.org/mozilla-central/rev/8c46fe36d7dd
https://hg.mozilla.org/mozilla-central/rev/92bbe2efd172
https://hg.mozilla.org/mozilla-central/rev/91af45ec6288

Comment 58

[Martin Lundberg]

What is the status of this? I'm trying to catch when I click on play/pause, next and previous media keys on my corded apple keyboard but when I hit "play/pause" iTunes starts and after maybe a couple of seconds the event is shown in Firefox but the event.code is OSLeft and the keyCode is 224. If I hit next or previous keys nothing happens at all. All I'm doing right now is console.log in a handler for 'keydown' on the jsbin site.

I've read above that there seem to be problems checking some keys on mac. Is this not supported?

Thanks!

Comment 59

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

This is now disabled by pref in release builds because we still have additional work for supporting Sun keyboard's special keys (https://www.w3.org/Bugs/Public/show_bug.cgi?id=24739). But we could ignore the spec bug because such users are very minority, though.

Comment 60

[Martin Lundberg]

I'm using Firefox Developer Edition and in about:config 'dom.keyboardevent.code.enabled' is set to "true".

Comment 61

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Yes, in beta and release channel, it's false in the default settings. Dev Edition is based on Aurora. Therefore, it's enabled for tested by testers in default settings.

Comment 62

[Martin Lundberg]

I'm sorry but I didn't understand that. Should it work for me since I've got Dev Edition and the option set to true?

Comment 63

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Yes, you can see code value in this testcase: https://dvcs.w3.org/hg/d4e/raw-file/tip/key-event-test.html

Comment 64

[Martin Lundberg]

But the 3 Apple Keyboard media keys seen here: http://support.apple.com/library/content/dam/edam/applecare/images/en_US/macbookpro/macbook_air_early.png does not work at all for me. Outputs nothing and when I hit the play/pause all that happends is that iTunes starts.

My previous text about the play/pause button outputting OSLeft after a while was just something I misunderstood, it came from when I hit Command-Tab to close iTunes.

Are the media keys on the Apple Keyboard supposed to work?

Comment 65

[Karl Tomlinson (:karlt back Feb 10)]

(In reply to Martin Lundberg from comment #64)
> Are the media keys on the Apple Keyboard supposed to work?

They will only work if the browser receives events from the OS.
Comment 58 suggests that the OS is capturing the events before they get to the focused application, for iTunes.

Comment 66

[Martin Lundberg]

I found some more information about handling media keys in OS X and I'm not sure but should I create a new  bug about this instead of talking about it here or do you want it here?

Comment 67

[Martin Lundberg]

Sorry for the double posting but so that you know what I'm talking about in the last comment what I found was http://overooped.com/post/2593597587/mediakeys which linked to https://github.com/nevyn/SPMediaKeyTap

I'm not sure how Firefox on OS X works if this is something it could use but I feel that Mozilla wanting things to be web-based instead of native apps things like this should work :)

Comment 68

[Jean-Yves Perrier [:teoli]]

I guess this is documented (thank you, :mayasuki; it is much much appreciated)
https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent.code
and
https://developer.mozilla.org/en-US/Firefox/Releases/32#Interfaces.2FAPIs.2FDOM

(I don't think there is a bug to enable this on release builds, don't forget to add ddn when this one is created!)