Intent to Deprecate and Remove: -internal-media-controls-overlay-cast-button

[Mounir Lamouri]

Contact emails

mlam...@chromium.org

Summary

-internal-media-controls-overlay-cast-button will no longer be exposed to web contents. That means that the remote playback overlay icon (on top of content) will no longer be customizable in CSS.

Motivation

-internal-media-controls-overlay-cast-button should never have been exposed to web contents in the first place. Furthermore, we now have an API for websites to reimplement the cast button feature (using Remote Playback API) so a website that wants a custom cast button can use custom controls.

Compatibility And Interoperability Risk

The selector has been available for as long as Chrome Android supports video flinging (couple of years). Contrary to -internal-media-controls-cast-button, we believe that this selector might be used to hide the overlay, making the deprecation more visible and annoying to web developers.

Alternative implementation suggestion for web developers

For developers that meant to customise the experience, using custom controls with Remote Playback API to implement the cast button is the recommended way to work around this deprecation.

For developers that meant to hide the button, using the `disableRemotePlayback` attribute is the recommended way to work around this deprecation.

Usage information from UseCounter

Usage is low (0.0328%) but above the threshold. However, usage has been declining:

https://www.chromestatus.com/metrics/feature/timeline/popularity/1064

We will look at the data when M59 is around the corner. We expect the usage to go below threshold. We will also investigate if there are large websites using the feature in order to see how they can move away from it.

OWP launch tracking bug

https://crbug.com/678285

Entry on the feature dashboard

https://www.chromestatus.com/feature/5714245488476160

Requesting approval to remove too?

Yes. We would like to remove the selector support in M59.

[Jochen Eisinger]

lgtm1

[Chris Harrelson]

LGTM2

It looks like it jumped a lot in September 2016. That sounds like one large site. Please report back with findings about large sites when you have it.

lgtm1

--
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+unsubscribe@chromium.org.

[Mounir Lamouri]

On Tue, 17 Jan 2017, at 15:50, Chris Harrelson wrote:
> LGTM2
>
> It looks like it jumped a lot in September 2016. That sounds like one
> large
> site. Please report back with findings about large sites when you have
> it.

Based on internal tools, it seems that Walmart website uses this CSS
selector on a lot of pages. Given that Walmart isn't a media company, if
they are actually using the selector, I wouldn't worry about breaking
their experience. It's possible that there are other usage that the tool
did not find though.

If one knows of a better tool to find usage of a string on websites, I'm
listening :)

-- Mounir

[Dimitri Glazkov]

LGTM3.

[Mounir Lamouri]

To follow-up on this, instead of going down, the usage increased (by
100%). We know that a large website started to use the feature and we
will reach out to them.

One alternative solution we are looking into is to deprecate the overlay
as we believe that websites use this selector to hide the overlay, not
to customise it. A common pattern being that websites using the
Presentation API with custom controls want to remove the Cast overlay.
Unfortunately, we currently have conflicting signal with regards to the
usage of the overlay by Chrome users.

-- Mounir

On Tue, 17 Jan 2017, at 09:31, Dimitri Glazkov wrote:
> LGTM3.

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

[nekr....@gmail.com]

To be fair, the overlay is useful when you want to cast a video and video player doesn't support it because it's old or because they just didn't thought about that. Making casting completely opt-in with custom controls (by either RemotePlayback API or Presentation API) would hurt users as per mentioned use case.

вторник, 4 апреля 2017 г., 15:42:15 UTC+3 пользователь Mounir Lamouri написал:

[PhistucK]

I do not think this proposal makes it opt-in. It only removes the ability to hide a user-interface feature using CSS.

☆PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/a3a368d0-1123-4a92-a938-6beff4076e4d%40chromium.org.

[Arthur Stolyar]

I thought it removes that overlay button completely because it's gone in Canary. Also if it isn't going to be removed then it doesn't make since at all.

Right now there is 2 way to disable that button: the selector and MediaElement#disableRemotePlayback. Once the selector is gone (but not the overlay), then the only way to hide the overlay would be to use disableRemotePlayback. But thing is, disableRemotePlayback also makes MediaElement#remote unusable, i.e. disabled it. Why then have MediaElement#remote for custom controls at all?

--

@nekrtemplar

[PhistucK]

If you use custom controls, is the overlay still there (stable, not canary, not sure what is going on there)?

☆PhistucK

[Arthur Stolyar]

My situation:

I use custom controls. In Chrome Stable (not sure about Beta) there is the overlay (unless I hide it with the selector). In Chrome Canary there is no overlay even without hiding with selector. 

So right now I use Remote Playback API to implement custom "cast" control and use the selector to hide the overlay. I do **not** use disableRemotePlayback property since it will disable Remote Playback API.

Possible scenario with this the selector remove (I'm confused now too):

1. You remove only the selector but not the overlay: To hide the overlay when developing custom controls, developers will need to use disableRemotePlayback which will render Remote Playback API and hence the custom controls effort.
2. You remove both the selector and the overlay: Users won't be able to cast videos from players/controls not compatible with the casting (i.e. not explicitly opted-in by Remote Playback API)

Not sure if I explain everything clearly. 

--

@nekrtemplar

[Arthur Stolyar]

hmm.. I actually see the overlay now in Canary, but it becomes hidden in a few seconds if you don't interact with it and I wasn't able to bring it back anyhow except of by page reload. Weird.

--

@nekrtemplar

[Mounir Lamouri]

Regarding the overlay not showing up, please file a bug. We did a couple
of changes around it recently so maybe something regressed.

In general, your summary is correct and if we drop the selector, one
would have to use `disableRemotePlayback` which would indeed prevent the
usage of the Remote Playback API usage. There would be hackier solutions
without this downside though. The alternative is to drop the overlay
entirely. This is is something we are looking into. The overlay is in
general shown way more often than it is clicked. The CTR was around 2%
last time I checked. We have added some more metrics regarding the usage
of the overlay and might run some experiments. We want to make sure that
we are confident with whichever path we take.

-- Mounir

> >> ☆*PhistucK*

> >>
> >> On Mon, Jul 3, 2017 at 7:51 AM, Arthur Stolyar <nekr....@gmail.com>
> >> wrote:
> >>
> >>> I thought it removes that overlay button completely because it's gone in
> >>> Canary. Also if it isn't going to be removed then it doesn't make since at
> >>> all.
> >>>
> >>> Right now there is 2 way to disable that button: the selector and
> >>> MediaElement#disableRemotePlayback. Once the selector is gone (but not
> >>> the overlay), then the only way to hide the overlay would be to use
> >>> disableRemotePlayback. But thing is, disableRemotePlayback also makes
> >>> MediaElement#remote unusable, i.e. disabled it. Why then have
> >>> MediaElement#remote for custom controls at all?
> >>>
> >>> 2017-07-03 7:41 GMT+03:00 PhistucK <phis...@gmail.com>:
> >>>
> >>>> I do not think this proposal makes it opt-in. It only removes the
> >>>> ability to hide a user-interface feature using CSS.
> >>>>
> >>>>

> >>>> ☆*PhistucK*

> >>>>> an email to blink-dev+...@chromium.org.

> >>>>> To view this discussion on the web visit
> >>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/a
> >>>>> 3a368d0-1123-4a92-a938-6beff4076e4d%40chromium.org

> >>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/a3a368d0-1123-4a92-a938-6beff4076e4d%40chromium.org?utm_medium=email&utm_source=footer>
> >>>>> .
> >>>>>
> >>>>
> >>>>
> >>>
> >>>
> >>> --
> >>> @nekrtemplar <https://twitter.com/nekrtemplar>
> >>>
> >>
> >>
> >
> >
> > --
> > @nekrtemplar <https://twitter.com/nekrtemplar>
> >
>
>
>
> --
> @nekrtemplar <https://twitter.com/nekrtemplar>

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

> To view this discussion on the web visit

> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPAD5%2BD4vA1xz%2BobD2G3_NGxwDruQWrdfb5xeV%2BDDdCpP9r09A%40mail.gmail.com.