Allow websites to stop the remote playback

[avayvod]

Currently, the spec doesn't define how the remote playback is stopped. It could be some user agent provided UI that the user can trigger somehow or that can be shown when the page calls start() on the remote instance that's already in a connected state. However, it seems natural to allow the website to have a custom control on the media element that stops the remote playback.

partial interface RemotePlayback {
  Promise stop();
}

[mounirlamouri]

/cc @jernoble

I wonder if that would be compatible with the iOS routing system where Safari uses the system default route in which case, there is no such thing as stop(). Would something like reset() be more generic?

[hober]

There's no equivalent of stop() on iOS; we only have API to show the user the picker, and one of the options in the picker is to switch back to local playback.

[jernoble]

@hober, it occurs to me that, per issue #6, Safari effectively has an API for stop(), namely, the page can add a x-webkit-wirelessvideoplaybackdisabled attribute to the element to cause playback to return to the local device.

However, this is just a side effect, and we may not want to provide an explicit API to do this.

[avayvod]

Hm, the connect() looks more along the lines of selectPlaybackDevice() to me then.

[mounirlamouri]

It seems that a website might be interested to have a "remote" button for users to start remote playback and then have this button be used to disconnect. The same way, the fullscreen has an on and off switch.

What's the rationale to not expose a way to stop the remoting from script if we want adding disableRemotePlayback to the element to actually to exactly that?

[jernoble]

@mounirlamouri

It seems that a website might be interested to have a "remote" button for users to start remote playback and then have this button be used to disconnect

That would be a strange design pattern, as it would mean users would have to explicitly disable playback before picking a different remote device. UAs would always provide a "stop" option in the device picker, so why would a site ever switch out the "choose a device" button with a "stop" button?

[tidoust]

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

PROPOSED RESOLUTION: For issue #4, no "stop" method, add guidance that UA should provide a way to disconnect, and rename "connect" method into something like "showDevicePicker"

[mounirlamouri]

I suggest to name the method showPrompt() or prompt() so the content can be UA dependent.

The spec should recommend the UA to show a list of devices at least when not connected and propose a way to disconnect when connected.

[markafoltz]

Threre is already Window.prompt() [1] but I think this is one of those obsolete modal Web APIs that newer browsers may ignore. Not sure if there would be any concern for confustion.

[1] https://developer.mozilla.org/en-US/docs/Web/API/Window/prompt

[mounirlamouri]

It sounds to me that window.prompt() and video.remote.prompt() should hardly be confused but I really don't mind renaming if people believe that could be a concern.

[hober]

I think I'd like something a little more verbose than prompt. WebKit's method is showPlaybackTargetPicker, which might be too verbose, but it is very clear what it does.

[mounirlamouri]

@hober, the issue here is that the UI will require the prompt to show a list of devices when disconnected (ie. to connect) and a way to disconnect when currently connected. Safari implements the UI in both states the same way but it is reasonable for other implementation to be slightly different (not offer a way to pick a new device without disconnecting for example).

Is showPrompt() something you would be happy with? It sounds like showPicker() will be closer to the Safari model but I'm afraid it might be slightly too specific. I could live with it though.

[avayvod]

What would the Promise mean in the context of showPicker() or prompt()? How would the behavior be defined in the spec w/o biasing towards the existing implementations too much?

Seems like something along the following lines:

When showPrompt|Picker() is called, the user agent MAY present some UI so the user could start or stop the remote playback. The returned promise will be fulfilled with true if user's interaction with the UI ends up in a state change (disconnected to connecting or connected to disconnected), otherwise it will be fulfilled with false if the state change was cancelled by the user or rejected with an appropriate error. Either 'connect to the remote playback device' or 'stop remote playback' algorithm MUST be run after successful fulfillment of the promise correspondingly to the state change initiated by the user.

How does it sound?

How about requestStateChange() for the name to avoid any UI in the name? I can imagine some persistent permission model where user allows an origin to play remotely on the same device and then the user agent doesn't have to show any UI.

[avayvod]

@mounirlamouri @hober @jernoble WDYT?

[avayvod]

Mounir and I agreed on (well, we didn't discussed the name).

partial interface RemotePlayback {
    Promise<void> showUI();
}

The Promise returned is rejected if the UI cannot be shown for some reason, and otherwise fulfilled after it's closed. The page will then check the state to figure out if it's now connecting to a device or is disconnected.

I like changeState as the method name as it's clear what's happening from the page point of view while very flexible from the user agent point of view but showXXX probably gives better expectations to the developer.

[avayvod]

Addressed in #49. I went with prompt() as we didn't seem to have agreed on anything yet. We can rename later.