User Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.1 (KHTML, like Gecko) Chrome/21.0.1180.83 Safari/537.1 Steps to reproduce: Listen for keypress/keydown/keyup event and press media Play/Pause key. Actual results: event.keyCode returns 0 Expected results: event.keyCode should return 179

Related to or duplicate of bug 448910.

(In reply to Aleksej [:Aleksej] from comment #1) > Related to or duplicate of bug 448910. The problem appeared in firefox 15, in 14 branch everything worked correct. So I don't think it's related to old bug 448910.

Can you provide a test case in this matter?

> Created attachment 660023 [details] The pop-up windows do show “0” for me on Linux-x86_64 with: * Firefox 16.0b2 * Nightly Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120328 Firefox/14.0a1 * Nightly Mozilla/5.0 (X11; Linux x86_64; rv:13.0a1) Gecko/20120202 Firefox/13.0a1

On Win7 32bit in Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20100101 Firefox/14.0.1 I still get keyCode 179. In 15 and 16 beta it returns 0.

Please fix this! http://jsbin.com/pocovo/1/edit?html,js,output Win10, FF 45.0.1

// FF workaround if (ev.keyCode == 0 && ev.key != null) { if (ev.key == "MediaPlayPause") ev.keyCode = 179; if (ev.key == "MediaTrackNext") ev.keyCode = 176; if (ev.key == "MediaTrackPrevious") ev.keyCode = 177; }

Must be a regression of bug 630810.

Hmm... We can fix following keys simply: > VK_MEDIA_PREV_TRACK 0xB1 > VK_MEDIA_STOP 0xB2 > VK_MEDIA_PLAY_PAUSE 0xB3 However, |VK_MEDIA_NEXT_TRACK 0xB0| is risky because we already use 0xB0 for DOM_VK_TILDE. I'm not sure if there are some keyboard layouts which can input tilde without Shift key (or with Shift key but without Shift key causes a Unicode character). And also I found different mapping about Volume keys: > VK_VOLUME_MUTE 0xAD > VK_VOLUME_DOWN 0xAE > VK_VOLUME_UP 0xAF However, we define them as: > const unsigned long DOM_VK_VOLUME_MUTE = 0xB5; > const unsigned long DOM_VK_VOLUME_DOWN = 0xB6; > const unsigned long DOM_VK_VOLUME_UP = 0xB7; And we already define the keyCode values are: > const unsigned long DOM_VK_HYPHEN_MINUS = 0xAD; > const unsigned long DOM_VK_OPEN_CURLY_BRACKET = 0xAE; > const unsigned long DOM_VK_CLOSE_CURLY_BRACKET = 0xAF; Different from DOM_VK_TILDE, changing these mapping must cause breaking some web sites which have special path for Gecko. So, I think that we should fix only following 3 keys here: > VK_MEDIA_PREV_TRACK 0xB1 > VK_MEDIA_STOP 0xB2 > VK_MEDIA_PLAY_PAUSE 0xB3 Since these keyCode values are not used in Gecko. However we shouldn't touch other mapping forever (i.e., WONTFIX) since web users will be usable KeyboardEvent.key even on Google Chrome starting after a couple of months. How do you think, smaug?

FIY: In ASCII capable keyboard layout, our keyCode value is decided with similar rules of KeyboardEvent.key. I.e., computed from inputting character. On the other hand, on the other browsers, keyCode value is similar to KeyboardEvent.code at least on Windows. A view from another point, Gecko's keyCode mapping doesn't depend on platforms, i.e., better consistency between any platforms, but the other browsers' mapping really depend on platform and US keyboard layout. In other words, keyCode is useful to guess an ASCII character to be inputted with the key on Gecko. However, that's true only when US keyboard layout is active on the other browsers. This is the reason why we've already reserved a lot of keyCode values. (I.e., keys whose virtual keycode values are defined our keyCode mapping may be incompatible with other browsers.)

Wouldn't it be a bit odd to fix MEDIA_PREV_TRACK but not MEDIA_NEXT_TRACK? If DOM_VK_TILDE isn't used by any commonly used keyboard layout, perhaps we could change MEDIA_NEXT_TRACK too. VOLUME_* could be handled as a separate bug. What do other browsers report for HYPHEN_MINUS and _CURLY_BRACKET?

(In reply to Olli Pettay [:smaug] from comment #12) > Wouldn't it be a bit odd to fix MEDIA_PREV_TRACK but not MEDIA_NEXT_TRACK? Yes. > If DOM_VK_TILDE isn't used by any commonly used keyboard layout, perhaps we > could change > MEDIA_NEXT_TRACK too. Yeah, ideally, yes. But I have no idea how to do investigate it without installing whole keyboard layouts into my Windows and Mac environments... > VOLUME_* could be handled as a separate bug. What do other browsers report > for HYPHEN_MINUS and _CURLY_BRACKET? I think other browsers don't map from native virtual key code to DOM keyCode on Windows because IE which is the original implementation of keyCode is just expose native virtual key code value with this attribute. On the other hand, other browsers using odd mapping based on US keyboard layout. Therefore, keyCode for printable keys are not useful on other keyboard layouts. We stopped such behavior at bug 630810 for making keyCode value i18n aware and making perfect consistency between platforms. After that, Windows defines new virtual keyCode values for such multimedia keys. So, even if we change keyCode definition *of* Gecko now, it might break a lot of websites which are fixed by bug 631165. So, honestly, I strongly want to recommend all developers should use KeyboardEvent.key and stop using KeyboardEvent.keyCode anymore. But I'm still not sure what we should do for legacy KeyboardEvent.keyCode which is useful only with a few environments.