You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If a media element is in a background or minimized tab, the user agent may stop rendering media, not allow the media element to autoplay, or render the media muted, depending on user agent policies.
This issue tracks updating the spec to describe what happens when:
A playing, remoted media element is put into the background and the user agent would normally stop rendering entirely or mute audio
A background media element prompts for remote playback
The results will depend on the implementation of remote playback. For example an implementation based on flinging should be able to continue remote playback, while implementations based on streaming may not.
There might be other scenarios I'm missing.
The text was updated successfully, but these errors were encountered:
I don't think any of these optimisations are mentioned in specs. In practice, user agents will not pause a page that's playing audible media but it's possible that remoting a media that is inaudible would have weird side effects.
I think this could be resolved with a note at the moment given that it may be based on non-specified concepts. WDYT?
Basically, I think it's worth an implementation note in the spec that the user agent should consider the impact of policies like background media/autoplay muted on remote playbacks, and it doesn't require any normative spec change.
From https://www.w3.org/2018/05/17-webscreens-minutes.html#x03:
If a media element is in a background or minimized tab, the user agent may stop rendering media, not allow the media element to autoplay, or render the media muted, depending on user agent policies.
This issue tracks updating the spec to describe what happens when:
The results will depend on the implementation of remote playback. For example an implementation based on flinging should be able to continue remote playback, while implementations based on streaming may not.
There might be other scenarios I'm missing.
The text was updated successfully, but these errors were encountered: