674739 - Implement DOM3 KeyboardEvent types for audio

Status: RESOLVED FIXED

(Core :: DOM: Events, defect, P2)

Description

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

As far as I can tell, these aren't delivered uniformly through DOM key events.  The use case is, if I have headphones plugged into my computer that's playing, say, HTML5 http://www.rdio.com/, I want to be able to use my headphone's controls pad to play/pause/etc. rdio playback.

I may have overlooked existing standards for this, if so sorry.

I think there may be two parts to this
 (1) Add keycodes or whatever for media keys
 (2) Add a new "focus context" for audio playback, so that rdio can grab "media focus" even if it's in a background tab, and keep listening to media-key presses.  Can do the latter in a separate bug.

Comment 1

[Paul Rouget [:paul]]

DOM3 includes such keycodes:
http://www.w3.org/TR/DOM-Level-3-Events/#key-values-list

Comment 2

[Justin Lebar (not reading bugmail)]

> (2) Add a new "focus context" for audio playback, so that rdio can grab "media focus" even if it's 
> in a background tab, and keep listening to media-key presses.

Maybe I'm weird, I don't want random pages to grab my "media focus".  That would break my ability to control my desktop media player, if I happened to have rdio open.  Or, I happen to be listening to Pandora, but I want to change my system speaker volume.

I agree it'd be useful under some circumstances, but I'm wary of letting a random webpage register a system-global keyboard shortcut.

Let's deal with this separately.  We really need these keycodes for b2g; we're using pageup/pagedown, which is causing all sorts of silly confusion.

Comment 3

[Dietrich Ayala (:dietrich)]

Required for B2G. We can't overload pageup/down for this in production.

Comment 4

[Andreas Gal :gal]

Its not clear to me that this would keep us from shipping v1. Renom if you disagree.

Comment 5

[Justin Lebar (not reading bugmail)]

We don't need this because we have an alternative resolution to bug 762362.

Comment 6

[Brad Lassey [:blassey] (use needinfo?)]

Attachment: patch for volume up/down

Just want to make sure I'm on the right track with this.

Comment 7

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

Comment on attachment 709059 [details] [diff] [review]
patch for volume up/down

Although, I still don't like to add new keycode...

Basically, 0xAE and 0xAF are the best value for them.
http://msdn.microsoft.com/en-us/library/dd375731%28v=VS.85%29.aspx

However, they have been already assigned to DOM_VK_OPEN_CURLY_BRACKET and DOM_VK_CLOSE_CURLY_BRACKET, unfortunately. Although, AFAIK, the is no keyboard driver/utility using these virtual keycode. So, I guess that IE never fires key events with these keycodes actually.

0xE2 is VK_OEM_102. Probably, we will never use this code because in our new rules, we cannot keep compatibility with IE for such keycodes (printable keys in standard position except [0-9a-z]). So, 0xE2 should be safe.

However, 0xE3 isn't so. It's an OEM specific keycode. See bug 833719. If we will decide we define all OEM specific keycodes for compatibility with IE (rather than a11y on non-Windows platforms), 0xE3 will be used.

Please use 0xB6 and 0xB7. AFAIK, no keyboard driver/utility uses these virtual keycodes. So, we must never use them in the future.

And please map 0xAE and 0xAF to the new DOM keycodes on Windows too in a separated patch. Change here:
http://mxr.mozilla.org/mozilla-central/source/widget/windows/KeyboardLayout.cpp#1080

Comment 8

[Brad Lassey [:blassey] (use needinfo?)]

Attachment: patch for volume keys

Comment 9

[Brad Lassey [:blassey] (use needinfo?)]

Attachment: patch for windows to use volume keys

Comment 10

[Brad Lassey [:blassey] (use needinfo?)]

Attachment: patch for android to use volume keys

Comment 11

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

Comment on attachment 709847 [details] [diff] [review]
patch for volume keys

0xB8 is reserved. So, in the future, it might become an important virtual keycode and we would be in trouble with compatibility with IE. So, don't use 0xB8. Use 0xB5-0xB7.

With that change, r=me. And ask sr to smaug.

Comment 12

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

Comment on attachment 709936 [details]
patch for android to use volume keys


>+        // KEYCODE_AT (77) ... KEYCODE_MEDIA_FAST_FORWARD (90)
>+        case AndroidKeyEvent::KEYCODE_MUTE:            return NS_VK_VOLUME_MUTE;

nit: alignment.

>         case AndroidKeyEvent::KEYCODE_PAGE_UP:            return NS_VK_PAGE_UP;
>         case AndroidKeyEvent::KEYCODE_PAGE_DOWN:          return NS_VK_PAGE_DOWN;

Comment 13

[Brad Lassey [:blassey] (use needinfo?)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/d91803d01873
https://hg.mozilla.org/integration/mozilla-inbound/rev/27c00bd9cc71
https://hg.mozilla.org/integration/mozilla-inbound/rev/a840d8f3fcb2

cjones, since you're the one that originally filed this bug, do you want to leave this open for more media keys to be implemented or resummarize to cover just volume keys and open a new bug?

Comment 14

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/d91803d01873
https://hg.mozilla.org/mozilla-central/rev/27c00bd9cc71
https://hg.mozilla.org/mozilla-central/rev/a840d8f3fcb2

Comment 15

[Brad Lassey [:blassey] (use needinfo?)]

spun out bug 839446 to handle the media key events. Re-summarizing this bug to reflect what was done.

Comment 16

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

https://developer.mozilla.org/en-US/docs/DOM/KeyboardEvent#Virtual_key_codes