Expose play/pause about mediasession HOT 20 CLOSED

Do you mean to trigger the default actions for when a media session is interrupted and then resumes again?

from mediasession.

Firstly play/pause behavior is enforced against current playing media in the current model. When you are interrupted you lose media focus and your media resources must stop – i.e. pause() media elements and suspend() AudioContext objects (pending Web Audio support in the spec).

Secondly, not exposing play/pause means a web developer cannot ignore/override that interruption request. If your media is interrupted you cannot e.g. preventDefault() on receiving a MediaSession 'pause' event or immediately re-invoke play(). That's going to mess up whatever was trying to get media focus and would indefinitely prevent other web pages from playing their media.

from mediasession.

Whether or not pausing is enforced seems orthogonal to whether or not play/pause are exposed. IIUC, Anne is simply asking why it's not possible to play and pause all the things controlled by a session while it is active. You can implement it with scripts of course, but if there's some plausible reason to want the convenience methods exposed, it seems harmless to do so.

from mediasession.

Ah, right. Thanks for the clarification.

Adding play() and pause() methods to MediaSession objects sounds doable as a convenience feature.

from mediasession.

I would prefer to leave that for later. We might want to focus on the basics before introducing helper methods. Also, if we were to go this route, exposing the elements that are part of the MediaSession might be a better idea, doesn't it?

from mediasession.

I'm not sure I understand. When play/pause are pressed on the keyboard/lockscreen, how does the application know whether to play/pause non-connected bits, such as an animation? (Or adjust network policies, etc.)

from mediasession.

As far as the MediaSession is concerned, I think play/pause button should resume/interrupt the session.

from mediasession.

When play/pause are pressed on the keyboard/lockscreen, how does the application know whether to play/pause non-connected bits, such as an animation?

If the animations are sync'd with a media element, using currentTime and listening to pause events might suffice. If it's Web Audio, it really depends on what that integration looks like, there is a definite risk that there won't be any events to hang this on to.

If we fix #78 we'd have event for the cause of the pausing and playing, might that be sufficient or is the case you have in mind more intricate?

from mediasession.

I think that's sufficient, but ideally @ehsan or @sicking confirms.

from mediasession.

The other case for exposing play/pause is for letting a page integrate with Flash. They could use these events to drive some code in Flash.

from mediasession.

But if play/pause simply act on the participating media elements and audio contexts and there are none in the case of Flash, how does that work? Perhaps I'm misunderstanding the proposed behavior of web-exposed play/pause methods.

from mediasession.

Wait, not methods, events on MediaRemoteControls.

from mediasession.

I think that's sufficient, but ideally @ehsan or @sicking confirms.

No that's not sufficient. We need the play and pause events on MediaRemoteControls for Flash, which is a crucial use case of this API for Mozilla. Also, the solution in #69 (comment) for media elements seems pretty backwards, we need to let authors to more complicated things, such as receive a play event, and schedule an audio node to be started and faded in after a timeout, for example.

from mediasession.

OK, yes, fixing #78 would not be sufficient, because interruptions are not the only cause of play/pause, notable using the play/pause button should also do that :)

Presumably, then, we should fire non-cancelable play/pause events whenever we're going to play/pause all of the participating media elements, and audio contexts if we can figure that out.

from mediasession.

OK, yes, fixing #78 would not be sufficient, because interruptions are not the only cause of play/pause, notable using the play/pause button should also do that :)

Yes, exactly :-)

Presumably, then, we should fire non-cancelable play/pause events whenever we're going to play/pause all of the participating media elements, and audio contexts if we can figure that out.

Hmm, why a non-cancelable event? It seems like a valid thing to do for the author to cancel it if that's what they want!

from mediasession.

Hmm, why a non-cancelable event? It seems like a valid thing to do for the author to cancel it if that's what they want!

If you have a pause button, does it ever make sense to not pause? If the event can be canceled, you'd also have to keep any notification UI in sync with that, which seems like a bit of extra work and testing, so there would have to be a reasonable use case IMHO.

Given the semantics I'm suggesting, paused/playing might better names, to be fired after the participating media elements have already been paused/played. If you then play them again in the event listener, it seems you're doing something weird, but at least it'll take all the same code paths as playing it again much later.

from mediasession.

Closing this issue since we are moving audio focus out to a separate API.

from mediasession.

@xxyzzzq isn't this for media controls?

from mediasession.

Sorry, it is.

from mediasession.

play and pause have been added.

from mediasession.