Re: [remote-playback] How should disableRemotePlayback/hideRemoteControls behave?

Anton and I have some update about this. We met with Jer Noble (Apple)
two weeks ago and he gave us more details about about the behaviour on
iOS. A significant difference between Safari iOS behaviour and Chrome
Android behaviour is that when selecting a new route, it becomes the
default route. In other words, when a video is played remotely on one
website, when playing something on another website, it would also play
remotely, until the user changes the default route (AFAIUI).

Therefore, hideRemoteControls isn't the right attribute because we would
like to not use the default route but the local route when playing a
media element with the attribute. We decided to go with the name of
disableRemotePlayback. The spec has been updated accordingly.

Regarding the behaviour of the Remote Playback API when the attribute is
set, Jer wants media.remote.start() calls to fail. I'm not sure if we
should do that but I have no valid use case against it so we decided to
go that way unless someone comes with a strong use case. This change
isn't yet part of the specification because this part of the
specification isn't yet fleshed out.

Assuming no one objects to this change, Chrome might ship this attribute
(disableRemotePlayback) in the next release (Chrome 49). We believe that
the attribute is simple enough and offers values to websites which will
be able to disable the default remote playback behaviour if they want
to. The rest of the API will require more work obviously.

-- Anton & Mounir

On Thu, 5 Nov 2015, at 15:21, Mounir Lamouri wrote:
> Hi,
> 
> Anton and I are trying to define how disableRemotePlayback (or
> hideRemoteControl as currently named in the spec draft) should behave.
> After talking with a few parties, we believe that everybody agrees that
> we need such an attribute but it seems that there is a subtle difference
> in how it should behave.
> 
> So, these are the use cases we have in mind:
> - A website doesn't want the user to play the media remotely because the
> website doesn't want the content to be played remotely (content
> restrictions or secondary content, etc.)
> - A website doesn't want the UA to suggest to the user to play the media
> remotely because it is using the Presentation API.
> - A website wants to control the user experience and prevents the UA
> from showing any kind of browser UI for remote playback (url bar icon,
> notification icon, overlay icon, default controls icons, ...).
> 
> We believe that these use cases can be fulfilled by hinting the UA to
> disable its UI for remote playback. However, another approach would be
> to fully disable the remote playback ability, blocking the API -- it
> seems that Safari's x-webkit-wirelessvideoplaybackdisabled behaves like
> that. This approach doesn't fulfil the last use case.
> 
> These two approaches are very similar apart that if the website tries to
> use the Remote Playback API. In the former, the calls will be allowed
> while in the latter, the UA will reject them. We prefer the first
> approach because we believe it is more flexible and extensible: the
> website gives a hint to the UA but isn't limited in its behaviour
> afterwards.
> 
> If you have a preference over the behaviour, we would love to hear it.
> As long as we are at it, feel free to suggest better names ;)
> 
> Cheers,
> Anton & Mounir
>

Received on Wednesday, 25 November 2015 21:21:28 UTC