Closed Bug 1584029 Opened 5 years ago Closed 5 years ago

Support hardware media keys on Windows

Categories

(Core :: Audio/Video: Playback, task, P2)

Product:
Core
Component:
Audio/Video: Playback
Platform:
Unspecified
Windows
Type:
task

Tracking

()

Status:
RESOLVED DUPLICATE of bug 1584501

People

(Reporter: alwu, Unassigned)

References

Details

We would like to support hardware media keys, such like play/pause, prev and next, to control media playback on Windows.

OS: Unspecified → Windows

Would this be a dupe of bug 448910?

Although I don't understand the reason why you need to split bugs for each platform, we should be able to handle it with WidgetKeyboardEvent or dom::KeyboardEvent since there are a lot of defined multimedia/auto keys:
https://searchfox.org/mozilla-central/rev/23f836a71cfe961373c8bd0d0219ec60a64b3c8f/widget/NativeKeyToDOMKeyName.h#765-892

See Also: → 1584542

Actually I also created two bugs: One for Windows and one for Linux, without knowing of these here.
@masayuki: Controlling Media when the Widget has no focus. Also there is the MediaSession API and the possibility to do much more than just listening to keypresses (passing Metadata to the OS)

So maybe the bug is not named precisely or I didn't properly get it either. However synthesizesing key presses might be a good way to support Web Extensions which listen to Media Keys (notably this and see the relevant bug)

(In reply to Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(Away: 9/21~9/29) from comment #2)

Although I don't understand the reason why you need to split bugs for each platform, we should be able to handle it with WidgetKeyboardEvent or dom::KeyboardEvent since there are a lot of defined multimedia/auto keys:
https://searchfox.org/mozilla-central/rev/23f836a71cfe961373c8bd0d0219ec60a64b3c8f/widget/NativeKeyToDOMKeyName.h#765-892

As when I implemented supporting media keys on Mac in bug1575995, I found that we didn't receive any media keys event in EventStateManager, so I suppose that we have to have different implementations on each platform.

Are we able to know if the media keys are pressing or not on our current firefox? If we would like to support those keys on Linux and Windows, do you any suggestion, of which we should be aware before implementing that?

Thank you.

Flags: needinfo?(masayuki)

(In reply to Alastor Wu [:alwu] from comment #4)

As when I implemented supporting media keys on Mac in bug1575995, I found that we didn't receive any media keys event in EventStateManager, so I suppose that we have to have different implementations on each platform.

Are we able to know if the media keys are pressing or not on our current firefox? If we would like to support those keys on Linux and Windows, do you any suggestion, of which we should be aware before implementing that?

Well for me the Media Keys were working on Windows and Linux: I was breakpointing dom::KeyboardEvent's constructor and was able to catch them as long as the browser has the focus. If we don't have focus we either need Global Hotkeys (1584542) or support for the media APIs which I am working on

(In reply to Marc Streckfuß from comment #5)

Well for me the Media Keys were working on Windows and Linux: I was breakpointing dom::KeyboardEvent's constructor and was able to catch them as long as the browser has the focus. If we don't have focus we either need Global Hotkeys (1584542) or support for the media APIs which I am working on

I tested that on Mac, and didn't see any event coming from when I pressed media keys on mac keyboard. So maybe we have different event handling ways on mac and other platforms?

My guess would be that macOS just handles the media keys different and doesn't promote them as key press event.

Because if they did, you have the same problem that we'll have on Windows/Linux: When implementing the proper Media API, you'd receive both events in some cases and not in others:

  1. When FF is not in focus, you usually only receive the Media API Callbacks anyway (but when the app is in focus you don't really need media keys in most cases)
  2. When using something like KDE Connect, you don't even press a physical key, you use your smartphone to remote control. Should the OS fake a key event in that case?
  3. Hot-Keying the Media Keys is evil as only one application is then allowed to ever play media. Other ways of hooking keypresses are (probably) only available on Windows.

Actually this will be important for us too: Web Extensions can register Media Keys as global hotkeys and I'm not sure how to handle them then. Or if this should not be used and instead expose the Media Session API to Web Extensions etc.

That being said, I'll give my mac build a spin and see if I it behaves the same (no key events)

(In reply to Alastor Wu [:alwu] from comment #4)

(In reply to Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(Away: 9/21~9/29) from comment #2)

Although I don't understand the reason why you need to split bugs for each platform, we should be able to handle it with WidgetKeyboardEvent or dom::KeyboardEvent since there are a lot of defined multimedia/auto keys:
https://searchfox.org/mozilla-central/rev/23f836a71cfe961373c8bd0d0219ec60a64b3c8f/widget/NativeKeyToDOMKeyName.h#765-892

As when I implemented supporting media keys on Mac in bug1575995, I found that we didn't receive any media keys event in EventStateManager, so I suppose that we have to have different implementations on each platform.

Yeah, macOS's SDK does not define any media keys. Therefore, we don't receive media key events from NSTextInputClient protocol so that I was wondering how to do that. Looks like the patch does a complicated things...

Are we able to know if the media keys are pressing or not on our current firefox? If we would like to support those keys on Linux and Windows, do you any suggestion, of which we should be aware before implementing that?

I check on Win10 with Microsoft's keyboard and Logitech's keyboard. Then, I verified that those keys cause keydown events for them as expected. Although keyup events are fired only with Microsoft's keyboard.

I cannot check it on Linux for now since I don't have a drive to run Linux natively. On VMware on Win10, only keyup events are fired with Microsoft keyboard, but only F8 etc keydown events are fired with Logitech's keyboard.

If media keys don't work properly on Firefox on Windows or macOS, the keyboard's utility or desktop itself handles the media key events before Gecko receives them. In such case, we need to contact the vendors or developers.

Flags: needinfo?(masayuki)

Well this is only relevant when talking about a focused window, which it is rarely because then I can also use other hotkeys to stop the current media (so a rare case).
I can confirm that Media Keys already raise Events on Windows and Linux in that case.

But for global handling there only is MPRIS on Linux or XGrabKey, which blocks every other app. For Windows it's similar, because a keylogger solution is not desired.

As we have already had a draft patch in bug1584542, I would mark this bug as a duplication of that bug.

Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → DUPLICATE

That's not entirely correct, bug1584542 is there to resolve bug1411795, as while they also had an example with Media Keys, it is more about supporting global hotkeys at all.

This bug however should be rather a duplicate of SMTC (whereever I started pushing to phab, probably), because we have to decouple our thinking of keys here. When supporting SMTC and other Media Interfaces, Key-Stuff will be handled by the OS.

bug1584542 probably won't even be allowed to touch media keys, as it could conflict with SMTC, leading to doubled events. Then it will never be able to resolve this bug.

Sorry for typing wrong bug number again and again...

(In reply to Marc Streckfuß [:MeFisto94] from comment #7)

Actually this will be important for us too: Web Extensions can register Media Keys as global hotkeys and I'm not sure how to handle them then. Or if this should not be used and instead expose the Media Session API to Web Extensions etc.

Once we got media keys event from the media keys event source (STMC/MPRIS/MediaPlayer), then we can forward those keys to web extension so that we don't have to implement another mechanism to grap media keys globally.

You need to log in before you can comment on or make changes to this bug.