Intent to Remove: HTMLVideoElement-specific prefixed fullscreen API

727 views
Skip to first unread message

Philip Jägenstedt

unread,
Feb 24, 2014, 5:26:04 AM2/24/14
to blink-dev

Primary eng (and PM) emails

[email protected]


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

Jochen Eisinger

unread,
Feb 24, 2014, 5:44:30 AM2/24/14
to Philip Jägenstedt, blink-dev
LGTM

Darin Fisher

unread,
Feb 24, 2014, 12:16:05 PM2/24/14
to Jochen Eisinger, Philip Jägenstedt, blink-dev
LGTM2

Eric Seidel

unread,
Feb 24, 2014, 12:16:40 PM2/24/14
to Darin Fisher, Jochen Eisinger, Philip Jägenstedt, blink-dev
Wow. LGTM.

Anton Vayvod

unread,
Mar 5, 2014, 1:21:42 PM3/5/14
to Eric Seidel, Darin Fisher, Jochen Eisinger, Philip Jägenstedt, blink-dev
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

unread,
Mar 5, 2014, 10:04:56 PM3/5/14
to [email protected], Eric Seidel, Darin Fisher, Jochen Eisinger, blink-dev
On Thu, Mar 6, 2014 at 1:21 AM, Anton Vayvod <[email protected]> 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

unread,
Mar 5, 2014, 10:30:14 PM3/5/14
to Philip Jägenstedt, [email protected], Eric Seidel, Darin Fisher, Jochen Eisinger, blink-dev
On Wed, Mar 5, 2014 at 7:04 PM, Philip Jägenstedt <[email protected]> wrote:
On Thu, Mar 6, 2014 at 1:21 AM, Anton Vayvod <[email protected]> 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 [email protected].

Adam Barth

unread,
Mar 5, 2014, 11:32:12 PM3/5/14
to [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
On Wed Mar 05 2014 at 7:30:19 PM, Rik Cabanier <[email protected]> wrote:
On Wed, Mar 5, 2014 at 7:04 PM, Philip Jägenstedt <[email protected]> wrote:
On Thu, Mar 6, 2014 at 1:21 AM, Anton Vayvod <[email protected]> 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

unread,
Mar 6, 2014, 1:10:57 AM3/6/14
to Adam Barth, Rik Cabanier, [email protected], Anton Vayvod, Eric Seidel, Darin Fisher, Jochen Eisinger, blink-dev
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

unread,
Mar 6, 2014, 1:13:54 AM3/6/14
to [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
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

unread,
Mar 6, 2014, 1:17:53 AM3/6/14
to Adam Barth, Rik Cabanier, [email protected], Anton Vayvod, Eric Seidel, Darin Fisher, Jochen Eisinger, blink-dev
(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

unread,
Mar 6, 2014, 1:47:09 AM3/6/14
to Nico Weber, Adam Barth, Rik Cabanier, Philip Jägenstedt, Anton Vayvod, Eric Seidel, Darin Fisher, Jochen Eisinger, blink-dev
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

unread,
Mar 6, 2014, 3:38:29 AM3/6/14
to [email protected], Philip Jägenstedt, Eric Seidel, Darin Fisher, Jochen Eisinger, blink-dev
On Thu, 06 Mar 2014 04:04:56 +0100, Philip Jägenstedt <[email protected]>
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

unread,
Mar 6, 2014, 10:30:52 AM3/6/14
to Daniel Bratell, Philip Jägenstedt, Eric Seidel, Darin Fisher, Jochen Eisinger, blink-dev
On Thu, Mar 6, 2014 at 8:38 AM, Daniel Bratell <[email protected]> wrote:
On Thu, 06 Mar 2014 04:04:56 +0100, Philip Jägenstedt <[email protected]> wrote:

On Thu, Mar 6, 2014 at 1:21 AM, Anton Vayvod <[email protected]> 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

unread,
Mar 6, 2014, 1:19:34 PM3/6/14
to Nico Weber, Adam Barth, Rik Cabanier, [email protected], Anton Vayvod, Eric Seidel, Darin Fisher, Jochen Eisinger, blink-dev
>>> 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

unread,
Mar 6, 2014, 1:51:03 PM3/6/14
to Anton Vayvod, Eric Bidelman, Daniel Bratell, Philip Jägenstedt, Eric Seidel, Darin Fisher, Jochen Eisinger, blink-dev
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

unread,
Mar 6, 2014, 2:08:09 PM3/6/14
to Nico Weber, Adam Barth, Rik Cabanier, [email protected], Anton Vayvod, Eric Seidel, Darin Fisher, Jochen Eisinger, blink-dev
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

unread,
Mar 6, 2014, 5:37:16 PM3/6/14
to Ojan Vafai, blink-dev, Eric Bidelman, Philip Jägenstedt, Eric Seidel, Daniel Bratell, Darin Fisher, Jochen Eisinger

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

unread,
Mar 7, 2014, 8:44:13 AM3/7/14
to [email protected], Ojan Vafai, blink-dev, Eric Bidelman, Philip Jägenstedt, Eric Seidel, Daniel Bratell, Darin Fisher, Jochen Eisinger
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


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

unread,
Mar 7, 2014, 1:58:16 PM3/7/14
to Miguel Garcia, [email protected], Ojan Vafai, blink-dev, Eric Bidelman, Eric Seidel, Daniel Bratell, Darin Fisher, Jochen Eisinger
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

unread,
Mar 8, 2014, 5:15:06 AM3/8/14
to [email protected], Eric Seidel, Darin Fisher, Jochen Eisinger, Philip Jägenstedt, [email protected]
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

unread,
Mar 8, 2014, 12:41:35 PM3/8/14
to Si Robertson, blink-dev, Eric Seidel, Darin Fisher, Jochen Eisinger, Anton Vayvod
On Sat, Mar 8, 2014 at 5:15 PM, Si Robertson <[email protected]> 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

unread,
Mar 8, 2014, 2:03:05 PM3/8/14
to [email protected], Si Robertson, Eric Seidel, Darin Fisher, Jochen Eisinger, Anton Vayvod
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

unread,
Mar 8, 2014, 2:46:06 PM3/8/14
to Si Robertson, blink-dev, Eric Seidel, Darin Fisher, Jochen Eisinger, Anton Vayvod
On Sun, Mar 9, 2014 at 2:03 AM, Si Robertson <[email protected]> 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

unread,
Mar 9, 2014, 3:06:22 AM3/9/14
to [email protected], Si Robertson, Eric Seidel, Darin Fisher, Jochen Eisinger, Anton Vayvod
Understood. I appreciate the insight into this, thanks Philip :-)

Eric Seidel

unread,
Mar 9, 2014, 4:12:56 AM3/9/14
to Ojan Vafai, Anton Vayvod, Eric Bidelman, Daniel Bratell, Philip Jägenstedt, Darin Fisher, Jochen Eisinger, blink-dev
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

unread,
Mar 9, 2014, 5:15:38 AM3/9/14
to Eric Seidel, Ojan Vafai, Anton Vayvod, Eric Bidelman, Daniel Bratell, Darin Fisher, Jochen Eisinger, blink-dev
On Sun, Mar 9, 2014 at 3:12 PM, Eric Seidel <[email protected]> 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

unread,
Mar 9, 2014, 9:41:34 PM3/9/14
to Philip Jägenstedt, Eric Seidel, Ojan Vafai, Anton Vayvod, Eric Bidelman, Daniel Bratell, Darin Fisher, Jochen Eisinger, blink-dev
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

unread,
Mar 11, 2014, 7:31:19 AM3/11/14
to Yuta Kitamura, Philip Jägenstedt, Eric Seidel, Ojan Vafai, Eric Bidelman, Daniel Bratell, Darin Fisher, Jochen Eisinger, blink-dev
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

unread,
Mar 11, 2014, 9:08:42 AM3/11/14
to Anton Vayvod, Yuta Kitamura, Eric Seidel, Ojan Vafai, Eric Bidelman, Daniel Bratell, Darin Fisher, Jochen Eisinger, blink-dev
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

unread,
Mar 11, 2014, 9:33:33 AM3/11/14
to [email protected], Anton Vayvod, Yuta Kitamura, Eric Seidel, Ojan Vafai, Eric Bidelman, Daniel Bratell, Darin Fisher, Jochen Eisinger
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

unread,
Mar 11, 2014, 9:39:18 AM3/11/14
to Philip Jägenstedt, Yuta Kitamura, Eric Seidel, Ojan Vafai, Eric Bidelman, Daniel Bratell, Darin Fisher, Jochen Eisinger, blink-dev
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

unread,
Mar 11, 2014, 9:45:53 AM3/11/14
to Anton Vayvod, Philip Jägenstedt, Yuta Kitamura, Eric Seidel, Ojan Vafai, Eric Bidelman, Daniel Bratell, Darin Fisher, blink-dev
I think it's prudent to hold back the revert for now until we've fully understood the situation.

best
-jocehn

Philip Jägenstedt

unread,
Mar 11, 2014, 12:28:04 PM3/11/14
to Jochen Eisinger, Anton Vayvod, Yuta Kitamura, Eric Seidel, Ojan Vafai, Eric Bidelman, Daniel Bratell, Darin Fisher, blink-dev
On Tue, Mar 11, 2014 at 8:45 PM, Jochen Eisinger <[email protected]> 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

unread,
Mar 11, 2014, 4:38:24 PM3/11/14
to Si Robertson, blink-dev, Anton Vayvod, Yuta Kitamura, Eric Seidel, Ojan Vafai, Eric Bidelman, Daniel Bratell, Darin Fisher, Jochen Eisinger
​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 [email protected].

Si Robertson

unread,
Mar 11, 2014, 5:02:22 PM3/11/14
to [email protected], Si Robertson, Anton Vayvod, Yuta Kitamura, Eric Seidel, Ojan Vafai, Eric Bidelman, Daniel Bratell, Darin Fisher, Jochen Eisinger
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 <[email protected]> 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

unread,
Mar 11, 2014, 5:15:00 PM3/11/14
to Si Robertson, blink-dev, Anton Vayvod, Yuta Kitamura, Eric Seidel, Ojan Vafai, Eric Bidelman, Daniel Bratell, Darin Fisher, Jochen Eisinger
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.

unread,
Mar 11, 2014, 8:18:41 PM3/11/14
to Si Robertson, blink-dev, Anton Vayvod, Yuta Kitamura, Eric Seidel, Ojan Vafai, Eric Bidelman, Daniel Bratell, Darin Fisher, Jochen Eisinger
On Tue, Mar 11, 2014 at 2:02 PM, Si Robertson <[email protected]> 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

unread,
Mar 18, 2014, 1:16:23 PM3/18/14
to Tab Atkins Jr., Si Robertson, blink-dev, Yuta Kitamura, Eric Seidel, Ojan Vafai, Eric Bidelman, Daniel Bratell, Darin Fisher, Jochen Eisinger
An update from YouTube: the right fix was rolled out overnight and I verified the playback and closed the bug as fixed.

[email protected]

unread,
Apr 16, 2014, 10:05:11 AM4/16/14
to [email protected]

[email protected]

unread,
Apr 16, 2014, 10:05:11 AM4/16/14
to [email protected]
Reply all
Reply to author
Forward
0 new messages