Define the UA behavior when the disableRemotePlayback attribute is added during the remote playback about remote-playback

[mounirlamouri]

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]

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]

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]

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

[jernoble]

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]

@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]

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]

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]

Addressed by #49.