Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Define in greater detail what effect setting playbackState has #177

Closed
foolip opened this issue Jan 12, 2017 · 3 comments
Closed

Define in greater detail what effect setting playbackState has #177

foolip opened this issue Jan 12, 2017 · 3 comments
Assignees
Labels

Comments

@foolip
Copy link
Member

foolip commented Jan 12, 2017

Related to #175

https://wicg.github.io/mediasession/#playback-state-model says "playback state is a hint from the page and and MAY be overridden by the user agent"

The setter definition in https://wicg.github.io/mediasession/#dom-mediasession-playbackstate doesn't clearly say what to do. It would be good if as much of the normative requirements as possible were in the algorithms reachable from API entry points, not in the model description.

https://wicg.github.io/mediasession/#media-session-routing doesn't reference playback state, so it's not clear if it should have any impact at all.

Concretely, what happens when the hint doesn't match the actual state?

  • If no media is playing or has been playing, does setting playbackState to "paused" do anything?
  • If some media was playing but is now paused, does setting playbackState to "playing" do anything?
  • If media is playing, does setting playbackState to "none" or "paused" do anything?

If the API ever has any effect, it does look like a miniature audio focus API, or have I misunderstood?

@xxyzzzq
Copy link
Contributor

xxyzzzq commented Jan 12, 2017

The playbackState has nothing to do with https://wicg.github.io/mediasession/#media-session-routing, nor audio focus. It is only used to help the UA decide whether to show a play button or pause button.

It could be useful to make the behavior consistent when different UAs have their own way of deciding whether a page is playing. For example:

  • The UA considers seeking or loading media as "not playing", but the page expects it to be interrupted by pause.
  • The UA does not have ability to decide whether the page is playing or not.
  • The page just want to do some preparation before media plays but it expects it could be interrupted by pause.

WDYT?

@xxyzzzq
Copy link
Contributor

xxyzzzq commented Jan 12, 2017

Original issue & PR discussing about adding playbackState attribute: #139, #141

@xxyzzzq xxyzzzq self-assigned this Jan 12, 2017
@foolip
Copy link
Member Author

foolip commented Jan 13, 2017

Thanks for that extra context, I had totally the wrong idea about this was. In addition to examples, there are a few things in the spec text I think would be useful:

  • Define in more detail how actual playback state is calculated. It would presumably be "playing" or "paused" if that's set, or calculated based on media elements and their states if not. People will reach for playbackState when the default is wrong, so it's best if browsers agree on what that default is.
  • Editorial: Define "playback state" as an internal concept of MediaSession alongside metadata and use that to define the playbackState attribute and the "actual playback state".

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants