Intent to remove window.webkitRequestAnimationFrame, webkitCancelAnimationFrame, webkitCancelRequestAnimationFrame

160 views
Skip to first unread message

Tanay

unread,
Dec 11, 2015, 5:55:11 AM12/11/15
to blink-dev
Contact emails


Link to “Intent to Deprecate” thread


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
  
Compatibility Risk

Low.Since the usage counters show low usage.  

Usage information from UseCounter

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

OWP launch tracking bug


Entry on the feature dashboard
none.

Tanay

Philip Jägenstedt

unread,
Dec 11, 2015, 6:18:14 AM12/11/15
to Tanay, blink-dev
There's a consequential typo or misreading of the use counters here.


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

unread,
Dec 11, 2015, 6:56:52 AM12/11/15
to blink-dev, tan...@samsung.com
Sorry, that was a  typo. 
Sure , I would like to do the analysis but I would need some guidance on the process. 

PhistucK

unread,
Dec 11, 2015, 7:20:14 AM12/11/15
to Tanay, blink-dev

Philip Jägenstedt

unread,
Dec 11, 2015, 9:33:50 AM12/11/15
to PhistucK, Tanay, blink-dev
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

unread,
Dec 11, 2015, 4:31:50 PM12/11/15
to Philip Jägenstedt, PhistucK, Tanay, blink-dev
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

unread,
Dec 11, 2015, 5:00:35 PM12/11/15
to Rick Byers, Philip Jägenstedt, PhistucK, Tanay, blink-dev
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

unread,
Dec 11, 2015, 5:41:49 PM12/11/15
to Joe Medley, Rick Byers, Philip Jägenstedt, Tanay, blink-dev
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

unread,
Dec 11, 2015, 5:46:46 PM12/11/15
to PhistucK, Rick Byers, Philip Jägenstedt, Tanay, blink-dev
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

unread,
Dec 11, 2015, 6:52:10 PM12/11/15
to Joe Medley, Rick Byers, Philip Jägenstedt, Tanay, blink-dev
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 -

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

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


PhistucK

Joe Medley

unread,
Dec 11, 2015, 7:08:23 PM12/11/15
to PhistucK, Rick Byers, Philip Jägenstedt, Tanay, blink-dev
Awesome! You saved me the trouble.

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

Mark Puffy

unread,
Dec 12, 2015, 12:30:27 AM12/12/15
to Tanay, blink-dev

Flack?!? :)

--

Ojan Vafai

unread,
Dec 14, 2015, 12:44:51 PM12/14/15
to Mark Puffy, Tanay, blink-dev

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

unread,
Dec 14, 2015, 12:48:38 PM12/14/15
to Ojan Vafai, Mark Puffy, Tanay, blink-dev
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

unread,
Dec 14, 2015, 12:58:43 PM12/14/15
to Joe Medley, Ojan Vafai, Mark Puffy, Tanay, blink-dev
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

unread,
Dec 14, 2015, 1:42:58 PM12/14/15
to Rick Byers, Joe Medley, Mark Puffy, Tanay, blink-dev
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

unread,
Dec 14, 2015, 1:45:24 PM12/14/15
to Rick Byers, Joe Medley, Ojan Vafai, Mark Puffy, Tanay, blink-dev
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

unread,
Dec 14, 2015, 2:57:36 PM12/14/15
to Ojan Vafai, Rick Byers, Joe Medley, Mark Puffy, Tanay, blink-dev
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:

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

unread,
Dec 14, 2015, 4:32:30 PM12/14/15
to Philip Jägenstedt, Ojan Vafai, Joe Medley, Mark Puffy, Tanay, blink-dev
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

unread,
Dec 15, 2015, 4:12:55 AM12/15/15
to Rick Byers, Philip Jägenstedt, Ojan Vafai, Joe Medley, Mark Puffy, Tanay, blink-dev
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

unread,
Dec 15, 2015, 1:47:31 PM12/15/15
to Anne van Kesteren, Rick Byers, Philip Jägenstedt, Joe Medley, Mark Puffy, Tanay, blink-dev
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

unread,
Dec 16, 2015, 1:46:59 AM12/16/15
to blink-dev, ann...@annevk.nl, rby...@chromium.org, phi...@opera.com, jme...@google.com, mrkp...@gmail.com, tan...@samsung.com
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

aps-adserving.min.js 149
 
However, since there are numerous unique sites and I have listed some common ones which seem to occur frequently.

PhistucK

unread,
Dec 16, 2015, 1:52:28 AM12/16/15
to Tanay, blink-dev, Anne van Kesteren, Rick Byers, Philip Jägenstedt, Joe Medley, Mark Puffy
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

unread,
Dec 16, 2015, 2:58:20 PM12/16/15
to PhistucK, Tanay, blink-dev, Anne van Kesteren, Rick Byers, Joe Medley, Mark Puffy
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

unread,
Dec 16, 2015, 3:53:26 PM12/16/15
to Philip Jägenstedt, PhistucK, Tanay, blink-dev, Anne van Kesteren, Joe Medley, Mark Puffy
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

unread,
Dec 16, 2015, 6:06:36 PM12/16/15
to blink-dev
Btw, Mozilla removed mozRequestAnimationFrame & friends with Firefox 42 (release  2015-11-03). Smooth delivery so far.

tanvir...@samsung.com

unread,
Sep 26, 2016, 5:50:04 AM9/26/16
to blink-dev, fri...@jeka.info
Is it the right time to remove webkitCancelRequestAnimationFrame .
As of now webkitCancelRequestAnimationFrame counter on 24th Sept 2016 is 0.017.

PhistucK

unread,
Sep 26, 2016, 6:15:11 AM9/26/16
to tanvir...@samsung.com, blink-dev, fri...@jeka.info
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

unread,
Sep 26, 2016, 6:20:50 AM9/26/16
to tanvir...@samsung.com, blink-dev, fri...@jeka.info
*are
Maybe more accurately, it breaks platform predictability.


PhistucK

Tanvir

unread,
Sep 26, 2016, 6:45:06 AM9/26/16
to blink-dev, tanvir...@samsung.com, fri...@jeka.info


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


Below are the usage counter for  these API's.

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

unread,
Sep 26, 2016, 6:59:29 AM9/26/16
to Tanvir, blink-dev, fri...@jeka.info
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

unread,
Sep 26, 2016, 8:49:32 AM9/26/16
to Tanvir, blink-dev, fri...@jeka.info
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.

Reply all
Reply to author
Forward
0 new messages