Intent to remove window.webkitRequestAnimationFrame, webkitCancelAnimationFrame, webkitCancelRequestAnimationFrame

[Tanay]

Contact emails

tan...@samsung.com

Link to “Intent to Deprecate” thread

https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/nNsZDn_utUc

Summary

'webkitRequestAnimationFrame' is vendor-specific. We should use standard 'requestAnimationFrame' instead.

These are non standard API's and deprecation phase is complete.

Motivation

In below link, it has been discussed to deprecate and remove these attributes

https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/nNsZDn_utUc

  

Compatibility Risk

Low.Since the usage counters show low usage.  

Usage information from UseCounter

webkitRequestAnimationFrame : https://www.chromestatus.com/metrics/feature/timeline/popularity/14: < 0.01%

webkitCancelAnimationFrame : https://www.chromestatus.com/metrics/feature/timeline/popularity/304 : < 0.01%

webkitCancelRequestAnimationFrame : https://www.chromestatus.com/metrics/feature/timeline/popularity/305 :  < 0.01% 

OWP launch tracking bug

https://code.google.com/p/chromium/issues/detail?id=146849

Entry on the feature dashboard

none.

Tanay

[Philip Jägenstedt]

There's a consequential typo or misreading of the use counters here.

https://www.chromestatus.com/metrics/feature/timeline/popularity/14 is at 0.07%, higher than most removals.

Also, I think use counters alone are not a good estimate of the risk here. It could be that there's one semi-popular library that looks for the prefixed API before the prefixed one, that hits the use counters but would not break. An analysis of httparchive data would be needed here. Are you interested in doing that?

P.S. Take care to include the colon in the subject, or https://bit.ly/blinkintents is not automatically updated. I have manually added this intent.

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

[Tanay]

Sorry, that was a  typo. 

Sure , I would like to do the analysis but I would need some guidance on the process. 

[PhistucK]

See this post for instructions -

https://www.igvita.com/2013/06/20/http-archive-bigquery-web-performance-answers/

☆PhistucK

[Philip Jägenstedt]

I have tested Edge using remote, and unsurprisingly they support webkitRequestAnimationFrame and webkitCancelAnimationFrame. However, they do not support webkitCancelRequestAnimationFrame, which means that we may want to treat that separately.

For webkitRequestAnimationFrame, there is some small benefit in removing it, since it's not just a plain alias, it also uses a different time base. If it were merely an alias, I would lean towards just spec'ing now that Edge has it, but the differences in behavior make that less fun.

To get a rough idea of the risk here, there are two things that I would do first:

1. Looks for pages containing the string "webkitRequestAnimationFrame" but not "requestAnimationFrame". How frequent are they, and is it actually code that would break the page? (Some code is unreachable, and some matches are in comments or documentation.)
2. For pages that containing both the strings "webkitRequestAnimationFrame" and "requestAnimationFrame", how common is it that webkitRequestAnimationFrame is called first? Would the requestAnimationFrame actually work, or are there typos or similar that would actually break the page if we remove webkitRequestAnimationFrame?

Hope that helps. I usually spend a lot of time categorizing the results, since most matches are usually from identical pieces of code, or the same code minified in different ways.

Given that the usage is still high (0.07%) the analysis needs to be very thorough, so if you didn't realize when sending the intent that this would be a special case, it would be OK to wait 6 months or so and see if usage hasn't dropped to half or less.

[Rick Byers]

Yeah this is going to be a tough one to remove any time soon (especially given that the benefit to removal isn't THAT high).  Basically we first have to effectively drive down usage (assuming the use counters are a good indicating of how page views would be broken in some way).  Here's some additional ideas for understanding / driving down the usage if someone is sufficiently motivated.

• Have a handful of people browse popular sites using an extension (or devtools-protocol-injected JS) that alerts when these APIs are used (and perhaps disables their functionality)
• The usage is high enough that I suspect it wouldn't be too hard to find a few popular sites still relying on it
• Then we can catagorize those by how breaking removal is.  If anecdotally >90% of sites "using" the API aren't materially affected by it not being available then that changes the discussion a lot!
• For those affected we can start outreach to try to get them updated - eg. popular libraries, specific sites (I'm happy to help with outreach to any google properties here)
• Search GitHub and submit pull requests to popular libraries

Personally, I'd want to see the use counters drop below at least 0.01% before seriously considering attempting a removal (unless we have evidence that a substantial majority of "usage" would be unaffected by removal).  That's still 1 in 10,000 page views, which is a LOT of page views to break every day!

Personally I suspect there's more return for investment to be had elsewhere, but I'd still love to see this get (responsibly) axed eventually :-)

Rick

[Joe Medley]

Did the unprefixed equivalents ever make it into Android Chrome or Android Webview? If so, what version?

Joe Medley | Technical Writer, DevPlat | jme...@google.com | 816-678-7195

[PhistucK]

Why would they not? About the same version of desktop Chrome (MDN indicates 24, but Chrome 19 - 24 were not released for Android, so Chrome 25 for Android), if I recall correctly. I do not remember anything exceptional about it.

Are you asking because you experienced something different? Or just because of the probably incomplete MDN compatibility table of the feature?

☆PhistucK

[Joe Medley]

I haven't tried it. I'm asking because not only is it missing from MDN, caniuse suggests it was added in Chrome 47. That didn't seem right.

Joe Medley | Technical Writer, DevPlat | jme...@google.com | 816-678-7195

[PhistucK]

Looks like caniuse just does not have the information, so it automatically just puts the last version.

See the history of the data from 8 days ago, for example - it has only Chrome 46 for Android listed as supported -

https://github.com/Fyrd/caniuse/blob/20de7b30c0d0dabbcd473dfee7c30d278d4f9158/features-json/requestanimationframe.json#L227

Anyway, I created a pull request to fix the data.

Unless someone hollers and it really is really not supported(?!).

☆PhistucK

[Joe Medley]

Awesome! You saved me the trouble.

Joe Medley | Technical Writer, DevPlat | jme...@google.com | 816-678-7195

[Mark Puffy]

Flack?!? :)

--

[Ojan Vafai]

Another change we could consider instead of removal would be to actually make the prefixed ones aliases for the unprefixed (i.e. use the same time base). That would be safer than removal I suspect and would reduce the cost of the prefixed APIs.

[Joe Medley]

I don't know how different the two feature are, if at all. In the abstract, I'd say that deprecation is better than aliasing because it has no risk for breaking existing code.

Joe Medley | Technical Writer, DevPlat | jme...@google.com | 816-678-7195

[Rick Byers]

It's been deprecated for a long time.  The choices now really are:

1) Remove

2) Un-deprecate (warning is spammy if we have no plan to actually remove)

3) Un-deprecate but make an alias of requestAnimationFrame

#3 sounds like an interesting idea to me.  I assume most uses of RAF ignore the callback argument, and so would be unaffected by this.  There's probably no easy way to measure this, right?  If others intuition is that this is unlikely to be breaking, I'd support giving it a shot.  That said, the different time base doesn't appear to add THAT much complexity to the code (just a handful of extra lines of boilerplate / plumbing, eg. here down).  So I doubt it's worth causing much real pain for this.

Rick

[Ojan Vafai]

On Mon, Dec 14, 2015 at 9:58 AM Rick Byers <rby...@chromium.org> wrote:

It's been deprecated for a long time.  The choices now really are:

1) Remove

2) Un-deprecate (warning is spammy if we have no plan to actually remove)

3) Un-deprecate but make an alias of requestAnimationFrame

#3 sounds like an interesting idea to me.  I assume most uses of RAF ignore the callback argument, and so would be unaffected by this.  There's probably no easy way to measure this, right?  If others intuition is that this is unlikely to be breaking, I'd support giving it a shot.

That's my intuition as well. I also don't know how we'd measure this. I think we'd just need to try it.

I don't have an opinion on which of the three options we should do.

[PhistucK]

I think the deprecation warning should state an actual version and remove it. In the worst case where things break badly (unlikely) in beta, it is reverted and either attempted later, or the warning is removed (and/or alias the standard version, if you will).

☆PhistucK

[Philip Jägenstedt]

On Mon, Dec 14, 2015 at 7:42 PM, Ojan Vafai <oj...@chromium.org> wrote:

On Mon, Dec 14, 2015 at 9:58 AM Rick Byers <rby...@chromium.org> wrote:

It's been deprecated for a long time.  The choices now really are:

1) Remove

2) Un-deprecate (warning is spammy if we have no plan to actually remove)

3) Un-deprecate but make an alias of requestAnimationFrame

#3 sounds like an interesting idea to me.  I assume most uses of RAF ignore the callback argument, and so would be unaffected by this.  There's probably no easy way to measure this, right?  If others intuition is that this is unlikely to be breaking, I'd support giving it a shot.

That's my intuition as well. I also don't know how we'd measure this. I think we'd just need to try it.

I don't have an opinion on which of the three options we should do.

It looks like Edge already uses the same time base for both, in this ad-hoc test the same value is passed to both callbacks:

http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3786

Given that, making webkitRequestAnimationFrame a plain alias of requestAnimationFrame seems like a good idea, unless it's going to be removed soonish. 

Philip

[Rick Byers]

Oh, great!  That's a good indication that the difference is unlikely to matter in practice (Edge has some great compat testing).  I support making it an alias.

What should we do about the deprecation warning in that case?   We could extrapolate from the usage curve and choose a date far in the future when we'd attempt removal?  Or we could just admit that once this is an alias, the cost of removal is unlikely to justify the tiny benefit anytime soon and just remove the warning (maybe spec the alternate name for the API in the compat spec?).  Personally I think the latter is more realistic.

Philip

[Anne van Kesteren]

On Mon, Dec 14, 2015 at 10:32 PM, Rick Byers <rby...@chromium.org> wrote:
> Or we could just admit that once this is an alias,
> the cost of removal is unlikely to justify the tiny benefit anytime soon and
> just remove the warning (maybe spec the alternate name for the API in the
> compat spec?). Personally I think the latter is more realistic.

If we end up having to standardize it, let's add it straight to the
HTML standard. The Compat standard is mostly there for specifications
that are harder to change directly. Like the Quirks Mode standard, it
would be ideal if it could just be rolled into the standards for the
relevant features over time.


--
https://annevankesteren.nl/

[Ojan Vafai]

On Tue, Dec 15, 2015 at 4:12 AM Anne van Kesteren <ann...@annevk.nl> wrote:

On Mon, Dec 14, 2015 at 10:32 PM, Rick Byers <rby...@chromium.org> wrote:
> Or we could just admit that once this is an alias,
> the cost of removal is unlikely to justify the tiny benefit anytime soon and
> just remove the warning (maybe spec the alternate name for the API in the
> compat spec?).  Personally I think the latter is more realistic.

My 2 cents: Cases where the prefixed version is actually just an alias and we have evidence that it breaks *any* content, we should try to get the prefix requirement into the spec. It's not worth breaking any content just to remove a prefix in my opinion and it's not too much to ask other browser vendors to implement it as it would make that content work in their browsers as well.

[Tanay]

Some initial results from httparchive

Query used:

| SELECT url FROM [httparchive:runs.2014_08_15_requests_body]

WHERE REGEXP_MATCH(body, r'webkitRequestAnimationFrame') 

AND NOT body CONTAINS "requestAnimationFrame" | 

1) There are 9968 sites returned by the query

2) Excluding 'jquery.min.js' there are 7480 sites

3) Excluding all '.js' there are 3207 sites

On some further analysis of 7480 sites:

jquery-1.6.min.js 144

jquery-1.6.2.min.js 846

jquery.js 540

.js 3589

jquery 2906

loader.js 4

common.js 17

skeleton.js 472

blueconic.net 17

ps-us.amazon-adsystem.com 138

aps-adserving.min.js 149

adsafeprotected.com 3760

 

However, since there are numerous unique sites and I have listed some common ones which seem to occur frequently.

[PhistucK]

You should analyze the result a bit (manually). For example, if the code contains window.requestAnimationFrame || window.webkitRequestAnimationFrame (or a reversed version of it), it is a safe usage that can be ignored.

Hopefully, most, if not all, of the usages are safe.

☆PhistucK

--

[Philip Jägenstedt]

Yesterday I also took a random sample of httparchive (20151201) and looked for "webkitRequestAnimationFrame" excluding "requestAnimationFrame". I got similar results as Tanay, with jQuery 1.6, 1.6.1 and 1.6.2 being in the top. Note that this falls back to setInterval, and the code was reverted to keep only that code path for a few years, so the jQuery cases are not a problem.

To make a better guess about the risk, one would have to make a similar analysis of all of the big buckets, and a random sample of the things that don't fall into a bucket.

[Rick Byers]

Regardless I see this as further evidence that the risk of removal is likely to be too large given the benefit (~7k sites excluding jQuery just in the top 500k is a LOT).

Oh and one other wrinkle: that http archive data is for sites served a desktop user agent string.  We can expect WebKit-specific issues to increase when looking at the sites served with a mobile UA string.

So what about just trying to make webkitRequestAnimationFrame an alias for requestAnimationFrame?  That sounds promising (yet still somewhat risky) to me...

[fri...@jeka.info]

Btw, Mozilla removed mozRequestAnimationFrame & friends with Firefox 42 (release  2015-11-03). Smooth delivery so far.

https://www.fxsitecompat.com/en-US/docs/2015/mozrequestanimationframe-and-related-apis-have-been-removed/

[tanvir...@samsung.com]

Is it the right time to remove webkitCancelRequestAnimationFrame .

As of now webkitCancelRequestAnimationFrame counter on 24th Sept 2016 is 0.017.

[PhistucK]

I do not think it makes sense to only remove the cancelling method if you keep the prefixed starting method. Half-implemented APIs (after being fully implemented) is worse for compatibility.

☆PhistucK

--

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.

[PhistucK]

*are

Maybe more accurately, it breaks platform predictability.

☆PhistucK

[Tanvir]

Sorry for mentioning only webkitCancelRequestAnimationFrame  API, precisely all these three API's.

Below are the usage counter for  these API's.

webkitRequestAnimationFrame : https://www.chromestatus.com/metrics/feature/timeline/popularity/14: = 0.049%

webkitCancelAnimationFrame : https://www.chromestatus.com/metrics/feature/timeline/popularity/304 : = 0.017%

webkitCancelRequestAnimationFrame : https://www.chromestatus.com/metrics/feature/timeline/popularity/305 : =  0.002% 

☆PhistucK

☆PhistucK

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

[Philip Jägenstedt]

I would probably support removing just webkitCancelRequestAnimationFrame at this time, because Edge doesn't implement it. Or possibly even all three, what's needed is a look at HTTP Archive data to see if anything would break. It's likely that a lot of the cases have fallbacks.

[PhistucK]

Judging just by those numbers, this cannot be removed (0.04 is larger than the usual limit of 0.02, if I remember correctly). But, yes, an HTTPArchive search and similar may yield safer results.

☆PhistucK

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