Intent to Remove: HTMLVideoElement-specific prefixed fullscreen API

[Philip Jägenstedt]

Primary eng (and PM) emails

phi...@opera.com

Link to “Intent to Deprecate” thread

https://groups.google.com/a/chromium.org/d/msg/blink-dev/DULRMEUkeJw/9HXn55X1gj4J

Summary

Remove these APIs on HTMLVideoElement:

readonly attribute boolean webkitSupportsFullscreen;

readonly attribute boolean webkitDisplayingFullscreen;

void webkitEnterFullscreen();

void webkitExitFullscreen();

// Note the different capitalization of the "S" in FullScreen.

void webkitEnterFullScreen();

void webkitExitFullScreen();

Motivation

The API has been deprecated for a release cycle to give developers a heads up. Usage is low.

Usage information from UseCounter

PrefixedVideoSupportsFullscreen: 0.009200893528

PrefixedVideoDisplayingFullscreen: 0.001510093115

PrefixedVideoEnterFullscreen: 0.0003490447336

PrefixedVideoExitFullscreen: 0.0003053643543

PrefixedVideoEnterFullScreen: 0.00002037975147

PrefixedVideoExitFullScreen: 0.00001725972437

Source: https://groups.google.com/a/chromium.org/d/msg/blink-dev/ze27T2M682w/SM3hGfQpKnoJ

Compatibility Risk

When removed, sites that use *only* this API with no fallback will simply stop supporting fullscreen. Given the usage counts this does not seem catastrophic, and it's likely that at least some of the current pages using this would fall back to another code path if the APIs were removed.

Row on feature dashboard?

http://www.chromestatus.com/metrics/feature/timeline/popularity/166

http://www.chromestatus.com/metrics/feature/timeline/popularity/167

http://www.chromestatus.com/metrics/feature/timeline/popularity/168

http://www.chromestatus.com/metrics/feature/timeline/popularity/169

http://www.chromestatus.com/metrics/feature/timeline/popularity/170

http://www.chromestatus.com/metrics/feature/timeline/popularity/171

[Jochen Eisinger]

LGTM

[Darin Fisher]

LGTM2

[Eric Seidel]

Wow. LGTM.

[Anton Vayvod]

This removal rendered at least one very popular site unusable in Chrome for Android: https://code.google.com/p/chromium/issues/detail?id=347922 (I reverted the patch locally and confirm that it fixes the issue).

Could it be that the usage counters were wrong?

[Philip Jägenstedt]

On Thu, Mar 6, 2014 at 1:21 AM, Anton Vayvod <ava...@chromium.org> wrote:
> This removal rendered at least one very popular site unusable in Chrome for
> Android: https://code.google.com/p/chromium/issues/detail?id=347922 (I
> reverted the patch locally and confirm that it fixes the issue).

The site is YouTube, for those who didn't follow the link. Has someone
reached out to YouTube yet? It should be a simple fix.

> Could it be that the usage counters were wrong?

They were implemented in the most ordinary manner, so I don't think
they're more wrong than any other counter. However, I don't know how
different products are weighted together, if something is hit on 100%
of sites on Android but 0% elsewhere, how would that show up in the
aggregate value?

Philip

[Rik Cabanier]

On Wed, Mar 5, 2014 at 7:04 PM, Philip Jägenstedt <phi...@opera.com> wrote:

On Thu, Mar 6, 2014 at 1:21 AM, Anton Vayvod <ava...@chromium.org> wrote:
> This removal rendered at least one very popular site unusable in Chrome for
> Android: https://code.google.com/p/chromium/issues/detail?id=347922 (I
> reverted the patch locally and confirm that it fixes the issue).

The site is YouTube, for those who didn't follow the link. Has someone
reached out to YouTube yet? It should be a simple fix.

Since we can't trust the useCounter, it's unlikely that it is just YouTube that is affected.

Maybe it's best to revert the change until we're sure that this doesn't a lot of broken video sites.

 

> Could it be that the usage counters were wrong?

They were implemented in the most ordinary manner, so I don't think
they're more wrong than any other counter. However, I don't know how
different products are weighted together, if something is hit on 100%
of sites on Android but 0% elsewhere, how would that show up in the
aggregate value?

Philip

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Adam Barth]

On Wed Mar 05 2014 at 7:30:19 PM, Rik Cabanier <caba...@gmail.com> wrote:

On Wed, Mar 5, 2014 at 7:04 PM, Philip Jägenstedt <phi...@opera.com> wrote:

On Thu, Mar 6, 2014 at 1:21 AM, Anton Vayvod <ava...@chromium.org> wrote:
> This removal rendered at least one very popular site unusable in Chrome for
> Android: https://code.google.com/p/chromium/issues/detail?id=347922 (I
> reverted the patch locally and confirm that it fixes the issue).

The site is YouTube, for those who didn't follow the link. Has someone
reached out to YouTube yet? It should be a simple fix.

Since we can't trust the useCounter, it's unlikely that it is just YouTube that is affected.

Maybe it's best to revert the change until we're sure that this doesn't a lot of broken video sites.

I wouldn't draw the conclusion that we can't trust data from UseCounter until someone has looked at the data and understood the issue.

Adam

 

[Nico Weber]

Huh, since this was removed based on use counter data and then broke _YouTube_, isn't a better conclusion that UserCounter data can't be trusted until has looked at the data and understood the issue?

 

Adam

 

[Adam Barth]

I feel like your message is largely argumentative.  For my part, I'd like to understand the situation better before jumping to conclusions.

Adam

[Nico Weber]

(Not sure what this means.)

 

 For my part, I'd like to understand the situation better before jumping to conclusions.

Oh, I guess I misunderstood your "I wouldn't draw the conclusion that we can't trust data from UseCounter". I thought it meant "we can still trust UserCounter", but based on your reply I guess you mean "we don't know if UseCounter can be trusted or not"?

 

Adam

[Elliott Sprehn]

I believe Youtube doesn't have the HTML player turned on for most users and uses the Flash based one instead. We should contact someone at YouTube and see what percentage of page views are serving the HTML player.

[Daniel Bratell]

On Thu, 06 Mar 2014 04:04:56 +0100, Philip Jägenstedt <phi...@opera.com>
wrote:

I think this is the interesting question.

Does Chrome on Android report usage data or do we only get usage data from
desktop computers?

/Daniel

[Anton Vayvod]

On Thu, Mar 6, 2014 at 8:38 AM, Daniel Bratell <bra...@opera.com> wrote:

On Thu, 06 Mar 2014 04:04:56 +0100, Philip Jägenstedt <phi...@opera.com> wrote:

On Thu, Mar 6, 2014 at 1:21 AM, Anton Vayvod <ava...@chromium.org> wrote:

This removal rendered at least one very popular site unusable in Chrome for
Android: https://code.google.com/p/chromium/issues/detail?id=347922 (I
reverted the patch locally and confirm that it fixes the issue).

The site is YouTube, for those who didn't follow the link. Has someone
reached out to YouTube yet? It should be a simple fix.

Yes, the Chromium bug mentions the issue filed against YouTube in the internal bug tracker. As far as I can see, the fix was submitted but it has to be rolled out to production which might take some time (a couple of days?)

 

Could it be that the usage counters were wrong?

They were implemented in the most ordinary manner, so I don't think
they're more wrong than any other counter. However, I don't know how
different products are weighted together, if something is hit on 100%
of sites on Android but 0% elsewhere, how would that show up in the
aggregate value?

I think this is the interesting question.

Does Chrome on Android report usage data or do we only get usage data from desktop computers?

I think it does. The issue should only affect phones since on tablets YouTube plays embedded while on phones it only plays in the full screen mode due to the display size.

 

/Daniel

[Julien Chaffraix]

>>> Huh, since this was removed based on use counter data and then broke
>>> _YouTube_, isn't a better conclusion that UserCounter data can't be trusted
>>> until has looked at the data and understood the issue?
>>
>>
>> I feel like your message is largely argumentative.
>
>
> (Not sure what this means.)
>
>>
>> For my part, I'd like to understand the situation better before jumping
>> to conclusions.
>
>
> Oh, I guess I misunderstood your "I wouldn't draw the conclusion that we
> can't trust data from UseCounter". I thought it meant "we can still trust
> UserCounter", but based on your reply I guess you mean "we don't know if
> UseCounter can be trusted or not"?

I think we shouldn't trust UseCounter plain and simple, based on this
report and the following issues.

I looked at some of the data some time ago [1] and noticed some
anomalies in them (e.g. [2] which makes no sense). Unfortunately I
didn't follow up on this so don't know where it comes from.

Having looked at the UseCounter code several times to simplify it, *no
one* understands where the Document we require for counting exactly
comes from. More concerning, we don't have any testing for the feature
so we don't know what we measure (and if someone breaks it). An
example of the lack of testing is that no one noticed that we don't
count pages that are not followed by a navigation [3] (which would be
my hunch for how our data got skewed against Youtube).

Julien

[1] https://groups.google.com/a/chromium.org/d/msg/blink-dev/6Hnl2pg7ogo/Lf3tVALqh7wJ
[2] https://crbug.com/293006
[3] https://crbug.com/292996

[Ojan Vafai]

Here are the numbers for the latest stable Android release. The original numbers were desktop + android. These numbers are much higher.

PrefixedVideoSupportsFullscreen: 0.04274067971

PrefixedVideoDisplayingFullscreen: 0.20405662243

PrefixedVideoEnterFullscreen: 0.01697920768

PrefixedVideoExitFullscreen: 0.00434704942

PrefixedVideoEnterFullScreen: 0.01596530432

PrefixedVideoExitFullScreen: 0.05012209208

Unfortunately we should probably revert this change. These numbers are a bit too high for me to be comfortable removing them. In the meantime, we can hope that most of this is just youtube and that we'll be able to remove these in the next release since youtube is being fixed.

What I've learned from this is that, when we're talking about usage numbers for prefixed APIs, that we should make sure to get the Android numbers as well. Eric, how hard would it be to expose the Android numbers on chromestatus.com? I don't think we need to go fully general and let you look at all the different platforms. Android is a special case.

[Julien Chaffraix]

Adam pointed out offline that most of my arguments were talking about
the CSS side of UseCounter (the CSS properties counting). This thread
is talking about a JavaScript API which uses a completely different
code path and doesn't suffer from the issues that I pointed out.

Thus my objections and arguments are invalid and should just be
ignored. The root cause is still to be found and I will let people who
know better dig into it.

Julien

[Anton Vayvod]

YouTube team should roll out the fix tonight PST time. Our QA haven't found any other sites being broken yet so maybe we can avoid reverting the change.

[Miguel Garcia]

We have however found several sites that change the behavior (the switch to using the full screen api on the video tag). So the resulting user experience is different (you get a bubble telling you are in full screen now for example). The user counters probably don't measure that.

Some site that exibit that behavior

- BBC News (e.g. http://m.bbc.co.uk/news/uk-26445887)

- MSNBC (e.g. http://www.msnbc.com/taking-the-hill/watch/for-war-vet-big-sarge-exercise-helps-heal-125459011660)

- National Geographic (e.g. http://adventure.nationalgeographic.com/adventure/videos-zero-to-60)

- Revision3 (e.g. http://revision3.com/rev3gamesreviews/south-park-the-stick-of-truth)

- style.com (e.g. http://video.style.com/watch/fashion-shows-dries-van-noten-fall-2014-ready-to-wear)

- Wired (e.g. http://video.wired.com/watch/inside-innovation-brass-monkey-reinventing-multiscreen-gaming-experiences)

- Engadget (e.g. http://www.engadget.com/2014/03/04/apple-carplay-ferrari-ff-hands-on/)

Full disclosure we happened to notice about these because we cannot cast videos yet when using the full screen api. That's obviously something we are working on anyway but the interesting thing here is that many sites seem to have  fallbacks that actually change the behavior which is not taken into account when deciding to remove a prefixed feature.

[Philip Jägenstedt]

In case this needs to be reverted in a hurry, I've prepared a CL:
https://codereview.chromium.org/191273002/

The numbers for Android are not far above the usual threshold for
removal, with the exception of PrefixedVideoDisplayingFullscreen.
However, webkitDisplayingFullscreen being undefined is usually going
to end up in the same code path as when it was false, so the main
breakage is probably with "exit fullscreen" buttons. Not trivial, but
also not throwing exceptions and breaking everything.

Since we still have ~3 weeks until the next branch point, it would be
interesting to wait to see if the YouTube change pushes the use
counter numbers for Android stable down enough to make this fly again.
If people prefer reverting first, that's fine too.

Philip

[Si Robertson]

Surely that problem is down to bad development practices on the part of the website developers? No one should be relying on the existence of vendor-prefixed APIs in production code, and I honestly don't believe Google should be basing their decisions to drop prefixed APIs based on the usage of those APIs. If an API prefix can be dropped (for example, if a W3C specification is stable enough) then the prefix should be dropped without hesitation assuming the standardized API exists.

[Philip Jägenstedt]

On Sat, Mar 8, 2014 at 5:15 PM, Si Robertson <retrom...@gmail.com> wrote:
> Surely that problem is down to bad development practices on the part of the
> website developers? No one should be relying on the existence of
> vendor-prefixed APIs in production code, and I honestly don't believe Google
> should be basing their decisions to drop prefixed APIs based on the usage of
> those APIs. If an API prefix can be dropped (for example, if a W3C
> specification is stable enough) then the prefix should be dropped without
> hesitation assuming the standardized API exists.

I do love deleting proprietary APIs, but what you suggest is pretty
far from the current process:

http://www.chromium.org/blink#TOC-Launch-Process:-Deprecation

It's unfair to blame Web developers for depending on proprietary APIs,
for a very long time that was the only way to use new features.
Regardless of who is at fault, just removing prefixed APIs that have
been standardized is going to leave you with a very broken browser. As
an example, I recently implemented Element.matches(selectors), but we
still have Element.webkitMatchesSelector(selectors). Remove the
prefixed API and up to 25% of pages will be affected:

http://www.chromestatus.com/metrics/feature/timeline/popularity/217

Philip

[Si Robertson]

Would the following be flagged as a use of webkitMatchesSelector?

if( Element.prototype.matches === undefined ) {

  Element.prototype.matches = Element.prototype.webkitMatchesSelector;

}

document.body.matches('body');

Here is another basic example with AudioContext.

try {

  context = new AudioContext();

} catch( err ) {

  context = new webkitAudioContext();

}

I'm just curious to know how the usage stats are determined. If matches and AudioContext are available, webkitMatchesSelector and webkitAudioContext won't actually be used (or needed) in those examples, and the code won't break if the vendor prefixes are removed.

[Philip Jägenstedt]

On Sun, Mar 9, 2014 at 2:03 AM, Si Robertson <retrom...@gmail.com> wrote:
> Would the following be flagged as a use of webkitMatchesSelector?
>
> if( Element.prototype.matches === undefined ) {
> Element.prototype.matches = Element.prototype.webkitMatchesSelector;
> }
> document.body.matches('body');
>
>
> Here is another basic example with AudioContext.
>
> try {
> context = new AudioContext();
> } catch( err ) {
> context = new webkitAudioContext();
> }
>
>
> I'm just curious to know how the usage stats are determined. If matches and
> AudioContext are available, webkitMatchesSelector and webkitAudioContext
> won't actually be used (or needed) in those examples, and the code won't
> break if the vendor prefixes are removed.

Functions are only counted if they are called, so pages that correctly
use the unprefixed function when available won't be counted. One
problem with webkitMatchesSelector in particular is that people
assumed that the unprefixed function would be matchesSelector, but
that didn't happen. I've submitted fixes to some popular libraries,
but I'd be surprised if we can remove webkitMatchesSelector within 5
years, if ever.

Philip

[Si Robertson]

Understood. I appreciate the insight into this, thanks Philip :-)

[Eric Seidel]

Are we still questioning UseCounter data, or do we believe this
Android/Desktop skew for fullscreen is sufficient to explain this
issue? How can we come to closure on this question?

If we're still questioning UseCounter data, we are going to need to
consider reverting other removals (like showModalDialog) which are
already on their way through Dev/Beta.

[Philip Jägenstedt]

On Sun, Mar 9, 2014 at 3:12 PM, Eric Seidel <ese...@chromium.org> wrote:
> Are we still questioning UseCounter data, or do we believe this
> Android/Desktop skew for fullscreen is sufficient to explain this
> issue? How can we come to closure on this question?

I don't see any particular reason to think there's anything more to it
than Android vs. Desktop usage. In the future we should look at both
independently, in particular when touching APIs which one can suspect
have skewed usage on Mobile vs. Desktop sites.

Philip

[Yuta Kitamura]

I somewhat worry about country/locale-based skew (e.g. if 5% of page views from one country get broken, that probably will be an issue), since browsing patterns of people in different countries could be drastically different. But I'm not sure how practical it is to collect locale-based data and make consistent decisions with that data.

Thanks,

Yuta

[Anton Vayvod]

Can we revert the change for now since YouTube's fix is still not ready? We can land it back once the fix is in.

[Philip Jägenstedt]

OK, I've submitted the review to revert that I mentioned earlier:
https://codereview.chromium.org/191273002/

Perhaps the conservative thing to do is to let the API be deprecated
for another release cycle, i.e. wait until after the next branch point
before attempting to remove this again. By that time I hope the
YouTube fix is deployed and reflected in the use counter data.

Philip

[Si Robertson]

Are you guys are seriously considering reverting this change because one website has not implemented a fallback? IMO, the popularity and ownership of the website in question should be irrelevant when it comes to decisions like this, the change is/was definitely a step in the right direction. The JS timeline metrics show the usage of the webkit-prefixed APIs listed in the original post at less than 0.01 percent, most of them less than 0.001 percent, and that should be the deciding factor here.

I apologise if this reply sounds rant-esque but I am honestly surprised this reversion has a real possibility of happening.

[Anton Vayvod]

Thanks Philip! I still hope the fix will be deployed sooner rather than later. Will keep the public bug and this thread updated.

[Jochen Eisinger]

I think it's prudent to hold back the revert for now until we've fully understood the situation.

best

-jocehn

[Philip Jägenstedt]

On Tue, Mar 11, 2014 at 8:45 PM, Jochen Eisinger <joc...@chromium.org> wrote:
> I think it's prudent to hold back the revert for now until we've fully
> understood the situation.

OK, I've closed the review again. Since I removed this API I feel
responsible for sorting this out, but I don't know that there's
actually anything I can do at this point. Maybe the OWNERS can discuss
the situation a bit and decide on a course of action so that we don't
flip-flop our way forward?

Philip

[PhistucK]

​If an extremely popular website is broken, this means a lot of users will have a broken experience, so this is a good reason to hold back a removal for a short while (a release or so, which is what is proposed here), until the situation can be remedied.​

However, until the branch point for the next release happens, there is plenty of time to test this change or let YouTube fix their implementation, which is why it is good that the rollback is not immediate.

☆PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Si Robertson]

I'm curious to know if this discussion would still be happening if the website in question wasn't affiliated with Google :-)

On Tuesday, 11 March 2014 20:38:24 UTC, PhistucK wrote:

​If an extremely popular website is broken, this means a lot of users will have a broken experience, so this is a good reason to hold back a removal for a short while (a release or so, which is what is proposed here), until the situation can be remedied.​

However, until the branch point for the next release happens, there is plenty of time to test this change or let YouTube fix their implementation, which is why it is good that the rollback is not immediate.

☆PhistucK

On Tue, Mar 11, 2014 at 3:33 PM, Si Robertson <retrom...@gmail.com> wrote:

Are you guys seriously considering reverting this change because one website has not implemented a fallback? IMO, the popularity and ownership of the website in question should be irrelevant when it comes to decisions like this, the change is/was definitely a step in the right direction. The JS timeline metrics show the usage of the webkit-prefixed APIs listed in the original post at less than 0.01 percent, most of them less than 0.001 percent, and that should be the deciding factor here.

[PhistucK]

I assume it would. A browser is good for experiencing websites. If a website is broken in a certain browser and not in a different browser (in this example, the native browser - the Android browser) - the user will choose the other one. While both of the browsers are maintain by Google, the goal of Chrome is to be the best browser for the user. Not being able to use a popular website (be it a Google property, or Facebook or whatever else that is popular) is hard hit for a browser.

☆PhistucK

[Tab Atkins Jr.]

On Tue, Mar 11, 2014 at 2:02 PM, Si Robertson <retrom...@gmail.com> wrote:
> I'm curious to know if this discussion would still be happening if the
> website in question wasn't affiliated with Google :-)

Yes. We're paying attention to it because it's a HUGE site, not
because it's a Google site.

~TJ

[Anton Vayvod]

An update from YouTube: the right fix was rolled out overnight and I verified the playback and closed the bug as fixed.

[colej...@gmail.com]

[colej...@gmail.com]