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.

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

> (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.

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

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

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

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

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 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 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;

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?

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

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