704171 - Remove the no-argument form of requestAnimationFrame

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[Boris Zbarsky [:bzbarsky]]

It's not going to get specced, and I don't believe it's used much if at all.

Once that's done, we can work on canceling animation requests.

Comment 1

[Boris Zbarsky [:bzbarsky]]

https://mxr.mozilla.org/addons/search?string=requestAnimationFrame%28%29 says there are 4 addons using the no-argument form at the moment....  Could we proactively contact those?

Looks like in one of the 4 this lives in a test; the other 3 use the same animation manager library.

Comment 2

[Boris Zbarsky [:bzbarsky]]

I guess the other option is to not do this removal and instead just implement the unprefixed version without this capability (to deal with that library specifically), but then we have two different code paths and so forth....

Comment 3

[Boris Zbarsky [:bzbarsky]]

Looks like converting our existing consumers here will be simpler once bug 647518 is fixed.... but fixing that bug is simpler if the code in this bug is gone first.  So I'm going to do this first, then add cancelation, then go back and simplify the code here.

Comment 4

[Jorge Villalobos [:jorgev] (he/him)]

The Add-ons MXR isn't very reliable at the moment, so we should follow the normal validation -> compat bump process. I can request validation to be added for this when it hits the Aurora channel.

Comment 5

[Boris Zbarsky [:bzbarsky]]

Well, if we have something more reliable, can we do that check, please?  If there's a significant number of addons affected, I can change the implementation strategy to mitigate the compat impact, possibly, but it would be good to know that now and not in January!

Comment 6

[Jorge Villalobos [:jorgev] (he/him)]

(In reply to Boris Zbarsky (:bz) from comment #5)
> Well, if we have something more reliable

We don't. I've been trying to get the Add-ons MXR fixed on bug 663885, but it's taking a long time.

> If there's a significant number of addons affected, I can change the
> implementation strategy to mitigate the compat impact, possibly.

I doubt many add-ons use this function. If there are more than the ones brought up by MXR, they shouldn't be more than a handful.

Detecting a function call with no arguments is something we can easily do with our compatibility validation. So, if developers have an alternate way to do what they've been doing thus far, I say go for it.

Comment 7

[Boris Zbarsky [:bzbarsky]]

There will absolutely be an alternate way of doing things, especially once bug 647518 is also fixed.

Comment 8

[Boris Zbarsky [:bzbarsky]]

Attachment: part 1. Stop using the no-argument form of mozRequestAnimationFrame in our chrome.

Comment 9

[Boris Zbarsky [:bzbarsky]]

Attachment: part 2. Remove the no-argument form of mozRequestAnimationFrame.

Comment 10

[:Gavin Sharp [email: [e-mail]]]

Comment on attachment 576543 [details] [diff] [review]
part 1.  Stop using the no-argument form of mozRequestAnimationFrame in our chrome.

>diff --git a/layout/base/tests/test_bug607529.html b/layout/base/tests/test_bug607529.html

>-  var eventsHappening = false;
>   var callbacksHappening = false;

callbacksHappening can also be removed.

>diff --git a/toolkit/content/widgets/browser.xml b/toolkit/content/widgets/browser.xml

>+      <method name="sample">

Add a "nsIFrameRequestCallback implementation" comment right above this?

Comment 11

[Boris Zbarsky [:bzbarsky]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/2db300a6241d
https://hg.mozilla.org/integration/mozilla-inbound/rev/0d33f892f63a

Comment 12

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

https://hg.mozilla.org/mozilla-central/rev/2db300a6241d
https://hg.mozilla.org/mozilla-central/rev/0d33f892f63a

Comment 13

[Boris Zbarsky [:bzbarsky]]

I filed bug 706528 on cleaning up the remaining mozBeforePaint bits we have left.

Comment 14

[Eric Shepherd [:sheppy]]

Updated docs:

https://developer.mozilla.org/en/DOM/window.requestAnimationFrame

And mentioned on Firefox 11 for developers.