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

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

From: Mounir Lamouri <mounir@lamouri.fr>
Date: Mon, 07 Dec 2015 11:42:25 +0000
Message-Id: <1449488545.2560020.460167417.4F514F3F@webmail.messagingengine.com>
To: "Kostiainen, Anssi" <anssi.kostiainen@intel.com>, Anton Vayvod <avayvod@google.com>
Cc: public-secondscreen@w3.org, Philip J├Ągenstedt <philipj@opera.com>, jer.noble@apple.com, Jonas Sicking <jonas@sicking.cc>
On Thu, 3 Dec 2015, at 11:52, Kostiainen, Anssi wrote:
> 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.

If `start()` were to work even if the attribute was set, I don't think
having a user warning would be useful. If `start()` is called, I would
expect that the websites has a UI that allows remote playback of the
video so the user and the website are clearly expecting the video to be
played remotely at that point.

I think one of the benefits of blocking remote playback is that such
"bug" in the website would be caught early because the remote playback
would fail consistently in all browsers. A website could easily remove
the attribute and call `start()` if they need to.

-- Mounir
Received on Monday, 7 December 2015 11:42:51 UTC

This archive was generated by hypermail 2.3.1 : Monday, 7 December 2015 11:42:52 UTC