Open Bug 1572869 (media-control) Opened 1 year ago Updated 1 day ago

[meta] Control any media without interacting directly with pages where media are

Categories

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

enhancement

Tracking

()

People

(Reporter: alwu, Assigned: alwu)

References

(Depends on 12 open bugs)

Details

(Keywords: meta)

This is a meta bug to track all media control related issues and there are some different possible features which we could implement under this topic.

1. Support hardware media keys
No matter play/pause keys from normal keyboard, from Mac's touch bar, or from the headphone or any other hardware controllers which are desinated to control media, we should provide an ability to control media via these keys.

2. Media Control Interface on desktop
Chrome has implemented something like that [1], which is a controller interface to play/pause/seek next or prev (if website implements that via MediaSession).

When websites implements MediaSession, they would hook up the control to that session object. If they doesn't, controller can still control media via a default session object.

Although we haven't had any implementation for MediaSession yet, we can still acheieve this feature by the implementation in bug1565689.

[1] https://www.theverge.com/2019/7/6/20684353/google-chrome-global-media-controls-play-button-pause-experimental-test-canary

3. An external Media Control Module for GeckoView
We have a media control interface on Fennec, which will show in Android notification bar and lockscreen while media is playing, but we have nothing on Fennix.

So we could implement some API to let GeckoView create an extern module which are used to control media inside Gecko.

Depends on: 1575995
Depends on: 1577367
Depends on: 1577890
Depends on: 1578615
Depends on: 1578945
Depends on: 1579588
Depends on: 1584029
Depends on: 1584030
Duplicate of this bug: 448910
Depends on: 1353652
Depends on: 1251795
Depends on: 1583858
Depends on: 1584501

Speaking of 448910, there is one take away though:

  1. We might need a bug to track control of regular <video> and <audio> elements
  2. We have to think about in-app-focus. What happens if I open two videos in different tabs vs different windows etc.
  3. We might need a bug to track combining all the bugs, wiering up the APIs

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

Speaking of 448910, there is one take away though:

  1. We might need a bug to track control of regular <video> and <audio> elements

All those things are based on controlling <video> and <audio> tags, so I don't understand why we need another bug to track them.
Eg. In bug1575995, we are able to control those tags via mac play/pause key.

  1. We have to think about in-app-focus. What happens if I open two videos in different tabs vs different windows etc.

Audio competing between tabs has been implemented in bug1565689. On Android, we have an android component to handle audio focus between apps.

  1. We might need a bug to track combining all the bugs, wiering up the APIs

That's why we use this bug to track all related implementations.

Depends on: 1590579
Depends on: 1591230
Depends on: 1591288
No longer depends on: 1583858
See Also: → 1583858
See Also: → 1584542
Depends on: 1591608
Depends on: 1591620
Depends on: 1592037
Depends on: 1592151
Depends on: 1592454
Depends on: 1592461
Depends on: 1593131
Depends on: 1593826
Depends on: 1598968
Depends on: 1599591
Depends on: 1599938

One thing I have to investigate is PlayPause() vs. dedicated Play() and Pause().
Under MPRIS I had the "bug", that when pausing the video manually, I had to press my media button twice, as it's state was on "still playing".

I think the major takeaway here is, that we need to propagate such "MediaStateChangeEvents" to the native backends, so the OS knows that the video has been paused (which is also important for UI/UX).
Is that related to the Metadata, i.e.e could this be done in one pass?

Depends on: 1601144
Depends on: 1601379
Depends on: 1601508
Depends on: 1601510
Depends on: 1602336
Depends on: 1602617

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

I think the major takeaway here is, that we need to propagate such "MediaStateChangeEvents" to the native backends, so the OS knows that the video has been paused (which is also important for UI/UX).
Is that related to the Metadata, i.e.e could this be done in one pass?

Yes, I've also been thinking about the same thing, we should have a event to notify when media controller playing state change or metadata change.

Depends on: 1603527
Depends on: 1603544
Depends on: 1603878
Depends on: 1604653
Depends on: 1604691
Depends on: 1604962
Depends on: 1605769
Depends on: 1606588
Depends on: 1606782

This will annoy plenty of Mac users that use iTunes/Music/Spotify. A workaround to lock your media keys to your preferred music app is https://github.com/milgra/macmediakeyforwarder.

Is there a chance of adding a pref or an toggle in Preferences for this behavior?

Depends on: 1609452
Depends on: 1610723
Depends on: 1611021
Depends on: 1611031
Depends on: 1611272
Depends on: 1611328
Depends on: 1611332
You need to log in before you can comment on or make changes to this bug.