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 the UA behavior when the disableRemotePlayback attribute is added during the remote playback #6

Closed
avayvod opened this issue Jan 18, 2016 · 9 comments

Comments

@avayvod
Copy link
Contributor

commented Jan 18, 2016

Currently the behavior when a page adds the disableRemotePlayback attribute to a media element that's being played remotely is undefined. Options are:

  1. leave it undefined
  2. define it so that the remote playback is stopped as soon as the attribute is added
  3. define it so that the attribute makes an effect on all subsequent attempts to playback the media element but not the one currently taking place

Option 2 seems like the most reasonable to me.

@mounirlamouri

This comment has been minimized.

Copy link
Member

commented Jan 18, 2016

I would be in favour of any of these options:

  • disableRemotePlayback is used in the play() algorithm and any change after play() steps are ran is ignored.
  • disableRemotePlayback is used like playbackRate or src and affects the playback (thus stops it if it is playing remotely).

@jernoble, do you have a preference? What would be the closest to Safari's behaviour?
@foolip, which solution would be the most consistent with the HTMLMediaElement spec?

@foolip

This comment has been minimized.

Copy link
Member

commented Jan 26, 2016

I think that looking at disableRemotePlayback only in play() (or potentially other points) and ignoring anything that happens after that sounds good. This would be consistent with the allowfullscreen attribute on iframes, which is checked when the iframe's browsing context is created, setting a flag, and removing the attribute after that point has no effect. (Blink/WebKit actually checks the attribute when requesting fullscreen, but still removing the attribute after that point has no effect.)

@avayvod

This comment has been minimized.

Copy link
Contributor Author

commented May 12, 2016

I'm not sure, why play() should look at the attribute at all, it should be agnostic from the Remote Playback API I think. If the element is in connected state, play is forwarded to the remote playback device, period.

How about the following (allowfullscreen-ish behavior):

  • once the attribute is present:
    • any call to getAvailability() rejects with an error
    • any call to connect() rejects with an error
    • user agent must not start remote playback as a result of any other event outside of the page control (default controls, external UI, system wide setting, etc)
  • when the attribute is added or removed, nothing changes w/r/t pending promises or existing availability objects or the current state of the element

Basically the page can keep observing availability and if the device selection or start remote playback algorithm has started, it can proceed.

If we want more like src-ish behavior, it could look like this (more complex so I prefer the former):

  1. Once the attribute is present:

    a) any call to getAvailability() rejects with an error
    b) any call to connect() rejects with an error

  2. When the attribute is added:

    a) in any state, all pending promises to connect() or getAvailability() get rejected with an error
    b) any existing availability objects returned by getAvailability() change their value to false
    c) if the state is connecting or connected, the user agent queues a task to stop remote playback if it hasn't already

  3. When the attribute is removed:

    a) if there's any availability objects alive and the state is "disconnected", start background monitoring of available remote playback devices
    b) if the state is not "disconnected", perform step 3a) when the state has changed to "disconnected" (see note below)

Note: when the stop remote playback algorithm is running, the user agent must reject all new returned promises from connect() or getAvailability(). So if the page starts remote playback, then adds and removes the attribute, it won't be able to start new remote playback or get availability until the current remote playback has finished. Maybe this restriction is too much though.

@mounirlamouri

This comment has been minimized.

Copy link
Member

commented May 13, 2016

FWIW, I think the first behaviour makes sense and is simple.

@jernoble

This comment has been minimized.

Copy link

commented May 23, 2016

Safari's current behavior for the equivalent feature is that the "x-webkit-wirelessvideoplaybackdisabled" attribute is "live"; setting it while a remote playback session is active will stop the session and return playback to the local device.

@avayvod

This comment has been minimized.

Copy link
Contributor Author

commented May 24, 2016

@jernoble would you say the second proposal from my comment above better matches the current Safari's behavior then? Would the first proposal be good enough?

@tidoust

This comment has been minimized.

Copy link
Contributor

commented May 24, 2016

Discussed at the F2F:
http://www.w3.org/2016/05/24-webscreens-minutes.html#item06

PROPOSED RESOLUTION: Use Anton's first proposal (no spec language to address this case). Add a non-normative note that existence of attribute is a hint for discovery.
PROPOSED RESOLUTION: Refine behavior of existing alg's for attribute, i.e. Promise rejections would reference it.

@foolip

This comment has been minimized.

Copy link
Member

commented Jun 1, 2016

To be clear, is it this one?

  1. Once the attribute is present:

    a) any call to getAvailability() rejects with an error
    b) any call to connect() rejects with an error

That sounds like what I was hoping for in #6 (comment) but it's quite different from what @jernoble says is Safari's current behavior.

@avayvod

This comment has been minimized.

Copy link
Contributor Author

commented Jul 11, 2016

Addressed by #49.

@avayvod avayvod closed this Jul 11, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.