1625580 - considering media session's playback state to determine if we need to stop the media control or not

Status: NEW

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

Description

[Alastor Wu [:alwu]]

[Short brief-up]

Currently, after the media starts playing, we would start to listen to the media control keys and allow users to use those keys to control media.

When combining with the media session API, we would have two different playback states, one is the declared playback state from MediaSession's playbackState [1] and the another is the guessed playback state that is determined from the media playback itself [2].

[1] https://w3c.github.io/mediasession/#declared-playback-state
[2] https://w3c.github.io/mediasession/#guessed-playback-state

Those two states can be used to determine the actual playback state [3], which should represent the final result of the playback state.

[3] https://w3c.github.io/mediasession/#actual-playback-state

And we would only route the media control keys to the tab with the audio focus, which means there must be something really playing. So if website uses a media session without any playing media, that media session won't receive any media control keys even if its playback state is playing or paused.

---

In order to prevent intercepting media control keys from other applications when we don't really need them, we have a mechanism that is to start a stop-media-control-timer which would make specific media elements lose an ability to be controlled if they are been paused over a certain period of time. (now it's 60 seconds)

Now the critiria to start a timer is only considering the media's playback state, so we might encounter a situtaion where all media is paused but the media session's declared playback state is still playing.

And I think in this case, we should not stop listening to the media control keys, but we will incorrectly stop it in our current implementation because we only consider guessed state.

Therefore, we should consider actual playback state to start a timer, instead of considering only guessed playback state.

---

Also, we got some feedback about whether we should stop media control when media session's playback state is none.

As I mentioned above, we should consider both guessed and declared playback state, so the final playback state we used to determine if we would like to start a stop-media-control-timer should be actual playback state.

Comment 1

[Ryan Hendrickson [rhendric on GitLab, GitHub]]

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

Now the critiria to start a timer is only considering the media's playback state, so we might encounter a situtaion where all media is paused but the media session's declared playback state is still playing.

And I think in this case, we should not stop listening to the media control keys, but we will incorrectly stop it in our current implementation because we only consider guessed state.

Therefore, we should consider actual playback state to start a timer, instead of considering only guessed playback state.

I think it's also worth considering the case when all media is paused and the media session's declared playback state is, correctly, paused. IMO, in this case we should also not stop listening to the media control keys. If a user is using a web app as their primary music player, presses the pause key, gets up for an hour and comes back, the web app would ideally continue to respond to the play key the same way that a desktop music player would. A web page not trying to be a primary media player doesn't need to hold this control once the media has stopped. I suggest that interacting with the media session is a reasonable proxy for ‘trying to be a primary media player’, since the only purpose of that API is to communicate to the platform what the browser is playing and to define how to react to global media events.

Then the question arises, once a page has interacted with the media session, should it have a way to declare that it no longer wants media control (for example, if there are separate controls on the page to stop and to pause playback, and the stop control is pressed)? The Media Session standard recommends that UAs implement default handlers for play and pause actions if the page has not defined any, so removing the action handlers from the media session is not a satisfactory way to release media control.

With these considerations in mind, looking just at the actual playback state is not enough, since that state can only take values of playing and paused, which doesn't differentiate between ‘paused temporarily, like a media player’ and ‘stopped and inert, like a normal web page’.

A simple way to draw this distinction without changing or adding any API would be to use declared playback state to determine if the browser should grant control unconditionally (if declared is playing or paused), or conditional on the guessed state being playing (if declared is none). There is the question of what to do about the stop-media-control-timer in cases when the media session API has been used—should it be disabled entirely, or used whenever the declared state is none? I don't have a strong opinion on this last question; I'm most concerned about ensuring that pages that want it can continue to listen to media control keys even when they aren't actively playing, so that they can serve as primary media players.