Intent to Implement and Ship: HTMLMediaElement.disableRemotePlayback

[Mounir Lamouri]

Contact emails: ava...@chromium.org, mlam...@chromium.org

Spec:
https://w3c.github.io/remote-playback/

Summary:
This attribute allows websites to tell the UA that they do not wish for
a media element to be played remotely. The UA will prevent the element
from being played remotely and will not show any UI advertising remote
playback.

Note that this attribute is part of the more general Remote Playback API
but here we are asking to ship only the attribute. The full API reached
a general agreement about its use cases and usefulness but we are not
asking to implement nor ship it yet.

Motivation:
There are two main motivations:
1. Safari iOS has a similar prefixed attribute as part of a more general
proprietary Remote Playback API, see:
https://github.com/w3c/remote-playback/blob/gh-pages/use-cases.md#proprietary-apis
2. We want to ship the attribute before the rest of the API because it
might be convenient for websites that want to use the Presentation API
to have a better control over the experience (Presentation API enables a
richer experience compared to basic remote playback).

Compatibility Risk:
Firefox: No public signals -- but expressed interest in private
discussions.
Edge: No public signals
Safari: No public signals -- but have their own proprietary API to do
the same thing and also expressed interest.
Web developers: No signals

Given the current proprietary attribute implemented in Safari iOS, we
have reasons to believe this might actually improve general
compatibility on the Web if Safari implements it and as far as we know,
the attribute matches their requirements.

Ongoing technical constraints:
None

Will this feature be supported on all six Blink platforms (Windows, Mac,
Linux, Chrome OS, Android, and Android WebView)?
Yes. However, Chrome only do remote playback on Android at the moment so
it will be a no-op on other platforms.

OWP launch tracking bug:
https://crbug.com/542684

Link to entry on the Chrome Platform Status:
https://www.chromestatus.com/features/4938279812071424

Requesting approval to ship?
Yes

-- Mounir

[Elliott Sprehn]

disabledFoo attributes are not particularly extensible and aren't usually good api assign since you have to assign a true value to turn something off.

Could this be remoteplayback=disabled (or off to match other attributes) instead? :)

[Mounir Lamouri]

On Thu, 26 Nov 2015, at 20:42, Elliott Sprehn wrote:
> disabledFoo attributes are not particularly extensible and aren't usually
> good api assign since you have to assign a true value to turn something
> off.

disableFoo attributes are meant to be used as content attributes. The
property in this case and others is mostly there for convenience and
completeness/reflection. It's not rare for attributes meant to be used
as content attributes to be booleans. As an example, a lot of
HTMLMediaElement content attributes are booleans.

> Could this be remoteplayback=disabled (or off to match other attributes)
> instead? :)

I understand the feeling. However, I'm not sure this is better. An
attribute with 'enabled' and 'disabled' values has the potential to be
extended but it's only a potential and it might not be extended because
there is no need for it or because the extension doesn't match the
current values. Moreover, 'enabled'/'disabled' values tend to be unclear
regarding the default which confuses developers.

Interestingly, Safari's proprietary API used to be
x-webkit-airplay={enabled|disabled} and they switched to
x-webkit-wirelessvideoplaybackdisabled. Based on our research, it seems
that x-webkit-airplay was confusing to developers: we saw a lot of
"x-webkit-airplay" (with no assigned value) and a large majority of
websites use "x-webkit-airplay=enabled" even though it is enabled by
default.

-- Mounir

[Rick Byers]

It's a little concerning that we have no public signals from any other vendor on this API.  To what extent have you tried to reach out to them?  This is a tiny API so the risk is small, but in general in cases like this I think we should at least be trying to find out who on the WebKit projects owns their implementation of the proprietary API and explicitly asking them for feedback on our API before we ship (but of course we wouldn't block long waiting for a reply). They've got experience shipping an identical API, it would be a shame to find out only after we ship if they'd learned something about how they'd want to design the API better :-)

For small questions like this, I've had success just finding who landed/reviewed the relevant WebKit patches and sending them a private e-mail / and/or creating a WebKit bug (eg. "consider implementing ... as alias of existing ... API") and explicitly cc'ing those folks.

[Philip Jägenstedt]

I discussed this with Mounir, Anton and Renganathan at BlinkOn, and for full discolure I think we should spell out that there's something a bit odd about this API. The only new cross-browser thing it brings to the table is the ability to remove the cast button from the native <video controls>. Normally you would just implement custom controls, and if you don't want to use the future Remote Playback API you can just not use it, you don't need an attribute for that.

However, we also have an overlay cast button, one that's shown when there is no controls attribute and nothing overlaps that part of the video. When cast support was added, most videos would otherwise not be possible to cast. I suspect that most uses of disableRemotePlayback would be to get rid of this button, in case you implement custom controls that don't happen to overlap that area. (And yes, we should get rid of the overlay cast button, somehow.)

As for the attribute name, I know that Mounir has gone back and forth between different ideas, and I haven't seen a better idea yet. It's a bit like the <iframe allowfullscreen> attribute where you opt in to fullscreen, but here you must opt out. If disableremoteplayback will be an exact alias of x-webkit-wirelessvideoplaybackdisabled, that's great.

The biggest promise of this API is if Safari would quickly implement it, so that we don't get many years of split code paths for remote playback, like we have for fullscreen. Do you have any sense about how eager Eric Carlson and Jer Noble (WebKit's media experts) are to implement and ship this? If they endorse the API publicly and it seems credible that it will ship in Safari in <12 months, then I support shipping ASAP.

-- Mounir

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Mounir Lamouri]

Thank you for your suggestions Rick. We actually did a lot of reach out.
I didn't go into details because I thought that wasn't needed given the
small addition but I guess I can provide more information here.

Regarding the general API, it was discussed during the Second Screen WG
F2F at TPAC last month. It got general support and was added to the
Second Screen WG working items (in scope with the charter). For
information, among others, Apple, Mozilla and Intel are members of this
group. During the meeting Mozilla said that they see the need for the
API but will probably tackle it later. I was able to find the minutes so
I've updated their support as "public". FWIW, it matches what we were
told later in private discussions.

Given that we wanted to ship the attribute ASAP, we did some reach out.
Initially, the plan was to ship in M48. We talked to Microsoft, Apple
and Mozilla.
Edge just recently (last month) added remote playback support in Edge as
a browser feature. They didn't yet look into APIs to offer the feature
to websites.
Mozilla gave us the same feedback than the one we got at TPAC (though,
different person): they think it's interesting but they don't have the
resources to implement. Jonas Sicking even suggested that we could
specify the Safari API if it was used enough in the wild.
Apple had a lot of comments. Especially on the attribute. We did not
ship in M48 because we wanted to make sure we were shipping something
they are happy with. We resolved these issues and the current shape
(name/definition) of the attribute is a direct result of these
discussions. However, most of these discussions were private and you can
only see a reflection of them in the group's mailing list.

-- Mounir

[Mounir Lamouri]

On Fri, 27 Nov 2015, at 10:23, Philip Jägenstedt wrote:
> I discussed this with Mounir, Anton and Renganathan at BlinkOn, and for
> full discolure I think we should spell out that there's something a bit
> odd
> about this API. The only new cross-browser thing it brings to the table
> is
> the ability to remove the cast button from the native <video controls>.
> Normally you would just implement custom controls, and if you don't want
> to
> use the future Remote Playback API you can just not use it, you don't
> need
> an attribute for that.
>
> However, we also have an overlay cast button, one that's shown when there
> is no controls attribute and nothing overlaps that part of the video.
> When
> cast support was added, most videos would otherwise not be possible to
> cast. I suspect that most uses of disableRemotePlayback would be to get
> rid
> of this button, in case you implement custom controls that don't happen
> to
> overlap that area. (And yes, we should get rid of the overlay cast
> button,
> somehow.)

It's not entirely correct. This is the intended behaviour for Chrome
because of how we handle remote playback (though, I think we have an add
queuing behaviour that we might want to disable if the attribute is
present). However, Safari iOS has a different way of handling media
routes: you can change the default route of the device to be remote
instead of local and any video would end up being played remotely
instead of locally. The attribute will prevent that default behaviour:
it's no longer about controls but about behaviour.

> The biggest promise of this API is if Safari would quickly implement it,
> so
> that we don't get many years of split code paths for remote playback,
> like
> we have for fullscreen. Do you have any sense about how eager Eric
> Carlson
> and Jer Noble (WebKit's media experts) are to implement and ship this? If
> they endorse the API publicly and it seems credible that it will ship in
> Safari in <12 months, then I support shipping ASAP.

What are we talking about here? I don't think the attribute's only
benefit is if Apple ships it in Safari. We have strong use cases for it
regardless of Apple's shipping plans. This said, from talking to Jer, I
would think that Safari might ship this at some point. The entire API is
compatible with their own API. They told us that it wouldn't be hard for
them to ship it and they were interested to provide a standard API
instead of their proprietary API. We all know that Safari doesn't
usually talk about their shipping plans so I don't think we should
expect a strong public commitment.

-- Mounir

[Philip Jägenstedt]

This is now going into the more general territory of the Remote
Playback API, but it sounds like the spec needs to leave room for the
initial playback mode of media elements to be remote. Presumably
mediaElement.remote.state would start out as "connected" then. It
would be great if the conditions were 100% interoperable, but I agree
that a way to suppress such behavior sounds good even if it's not.

Also, when it comes to Media Session, we have toyed with the idea of
being able to cast from the playback notification, which would then be
a bit of UI to suppress that's entirely outside of the page.

> > The biggest promise of this API is if Safari would quickly implement it,
> > so
> > that we don't get many years of split code paths for remote playback,
> > like
> > we have for fullscreen. Do you have any sense about how eager Eric
> > Carlson
> > and Jer Noble (WebKit's media experts) are to implement and ship this? If
> > they endorse the API publicly and it seems credible that it will ship in
> > Safari in <12 months, then I support shipping ASAP.
>
> What are we talking about here? I don't think the attribute's only
> benefit is if Apple ships it in Safari. We have strong use cases for it
> regardless of Apple's shipping plans. This said, from talking to Jer, I
> would think that Safari might ship this at some point. The entire API is
> compatible with their own API. They told us that it wouldn't be hard for
> them to ship it and they were interested to provide a standard API
> instead of their proprietary API. We all know that Safari doesn't
> usually talk about their shipping plans so I don't think we should
> expect a strong public commitment.

I realize that strong public commitment is never going to happen, but
some public comment is better than nothing. If that just isn't
forthcoming, and your impression is that they will implement anyway,
then that'll have to do. Apple's involvement is uniquely important in
this case, I think.

Since this intent is only for the attribute, that would at worst
become another no-op in the long term, I think the trade-off is pretty
clear.

LGTM1

[Anton Vayvod]

If one needs more examples of outside-of-the-media-element remote playback UI which arguably shouldn't be hidden when the media doesn't have the controls attribute, there's a Cast button in the url bar of Firefox on Android and also the one in Chrome's desktop toolbar.

[Rick Byers]

Thanks for the details Mounir and sorry for my delay (lost track of this one).  Clearly you guys are doing a lot of collaboration with the other vendors (which is all I was really concerned about here).  +1 to everything Philip said.  LGTM2.

[Chris Harrelson]

LGTM3