1591230 - [MediaControl-OSX] Use 'MediaPlayer' framework for receiveing media keys

Status: RESOLVED FIXED

(Core :: Widget: Cocoa, task, P2)

Description

[Alastor Wu [:alwu]]

We have already had a patch from bug1251795, and I think that bug is used to implement how to support global media key for web extension, so we should probably separate the native platform implementation from that.

This bug is used to implement catching media key events globally on OSX by using MediaPlayer framework.

On Windows, we have bug1584542.
On Linux, we have bug1584030.

Comment 1

[paul.eliot.warner]

Attachment: Bug 1591230 - On macOS use MediaPlayer library for media keys when available.

Comment 3

[Stephen A Pohl [:spohl]]

[Tracking Requested - why for this release]:

We will need to ensure that the patches here remove the use of CGEventTapCreate[1]. This has to land in 71 to avoid the scary native dialog reported in bug 1594028.

[1] https://searchfox.org/mozilla-central/rev/3300072e993ae05d50d5c63d815260367eaf9179/dom/media/mediacontrol/MediaHardwareKeysEventSourceMac.mm#85

Comment 4

[Alastor Wu [:alwu]]

Does it need to be P1? because the pref "media.hardwaremediakeys.enabled" is off by default, so you don't change it explicitly, we won't create a CGEventTap and you won't get this problem.

Comment 5

[Stephen A Pohl [:spohl]]

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

Does it need to be P1? because the pref "media.hardwaremediakeys.enabled" is off by default, so you don't change it explicitly, we won't create a CGEventTap and you won't get this problem.

If this can be confirmed, then no, it doesn't have to be a P1. Unfortunately, I have been unable to reproduce myself.

Comment 6

[Alastor Wu [:alwu]]

We would create the MediaHardwareKeysEventSourceMac, which uses CGEventTap, only when the pref is on [1]. So if the issue is caused by using the CGEventTap, then it would definitely not happen if user keep the default setting.

[1] https://searchfox.org/mozilla-central/rev/8b7aa8af652f87d39349067a5bc9c0256bf6dedc/dom/media/mediacontrol/MediaControlKeysManager.cpp#34-36

Comment 7

[Stephen A Pohl [:spohl]]

I agree that based on code inspection, we shouldn't be running into this by default. I was hoping to get confirmation from someone who is able to reproduce the scary dialog when the pref is on that it does not pop up with the pref turned off. Since this is most likely the case I'm going to lower the priority to P2. :haik, did you say that you were able to reproduce the dialog on your system?

Comment 8

[Haik Aftandilian [:haik]]

(In reply to Stephen A Pohl [:spohl] from comment #7)

I agree that based on code inspection, we shouldn't be running into this by default. I was hoping to get confirmation from someone who is able to reproduce the scary dialog when the pref is on that it does not pop up with the pref turned off. Since this is most likely the case I'm going to lower the priority to P2. :haik, did you say that you were able to reproduce the dialog on your system?

Yes, I realized it appears to be triggered by YouTube. I am able to reproduce this by turning on the pref media.hardwaremediakeys.enabled, restarting the browser, and then visiting YouTube and watching a video such as https://www.youtube.com/watch?v=QgiSModQM7s.

Comment 9

[Pascal Chevrel:pascalc]

If media.hardwaremediakeys.enabled is set to false by default, that there is no end-user UI to activate (apart from about:config) and that there are no plans to do a pref rollout to activate it in the 71 window, then we don't need to track it for 71 release. If I am missing some context, don't hesitate to contact me, thanks.

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/155e5d7c120c
On macOS use MediaPlayer library for media keys when available. r=spohl,alwu

Comment 11

[Raul Gurzau (:RaulG)]

https://hg.mozilla.org/mozilla-central/rev/155e5d7c120c