W3C home > Mailing lists > Public > public-secondscreen@w3.org > December 2015

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

From: Kostiainen, Anssi <anssi.kostiainen@intel.com>
Date: Thu, 3 Dec 2015 11:52:02 +0000
To: Mounir Lamouri <mounir@lamouri.fr>, Anton Vayvod <avayvod@google.com>
CC: "public-secondscreen@w3.org" <public-secondscreen@w3.org>, Philip Jägenstedt <philipj@opera.com>, "jer.noble@apple.com" <jer.noble@apple.com>, Jonas Sicking <jonas@sicking.cc>
Message-ID: <AC681CE0-5256-4433-A806-195A1AF61F71@intel.com>
Hi,

[hat off]

> On 25 Nov 2015, at 23:20, Mounir Lamouri <mounir@lamouri.fr> wrote:
> 
> 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).

Thanks for the update, and sharing the results from the discussion.

> 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.

Sounds reasonable.

Does disableRemotePlayback as now specced mirror the behaviour of x-webkit-wirelessvideoplaybackdisabled?

Looking at this the other way: if the start() would not fail when the disableRemotePlayback attribute is set, what would a reasonable behaviour look like?

Just thinking on top of my head: would the UA e.g. inform the user that the remote playback of the content is disabled, but nevertheless allow the user to proceed with remote playback? A bit similarly to how a user gets a "confirm form resubmission" interstitial warning if trying to repost cached content.

I think explicitly rejecting the promise as suggested by Jer would be better for interoperability and would make for a more consistent UX too. And as a bonus, make the API more polyfillable.

> 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.

Shipping this in small yet functional pieces seems like a good idea.

Thanks,

-Anssi
Received on Thursday, 3 December 2015 11:53:41 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 3 December 2015 11:53:41 UTC