Last Comment Bug 704063 - Add unprefixed requestAnimationFrame
: Add unprefixed requestAnimationFrame
Status: VERIFIED FIXED
[need review][parity-IE][parity-webkit]
: dev-doc-complete
Product: Core
Classification: Components
Component: Layout (show other bugs)
: Trunk
: All All
: -- normal with 1 vote (vote)
: mozilla23
Assigned To: Boris Zbarsky [:bz]
: Mihai Morar, (:MihaiMorar)
Mentors:
Depends on: 647518 704175 753453 876282
Blocks: unprefix
  Show dependency treegraph
 
Reported: 2011-11-21 00:21 PST by Henri Sivonen (:hsivonen)
Modified: 2015-09-27 09:04 PDT (History)
21 users (show)
bzbarsky: in‑testsuite+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
23+


Attachments
Add an unprefixed version of requestAnimationFrame. (8.45 KB, patch)
2013-04-18 01:04 PDT, Boris Zbarsky [:bz]
roc: review+
bugs: superreview+
Details | Diff | Review

Description Henri Sivonen (:hsivonen) 2011-11-21 00:21:03 PST
The change so far made to mozRequestAnimationFrame (bug 588174) and the planned changes (bug 647517 and bug 647518) are all non-breaking changes--i.e. changes that wouldn't break or did not break existing usage. Thus the prefix isn't needed to protect against breakage.

OTOH, the prefix makes authors write more boilerplate and/or risks authors failing to support all browsers that have this feature in some form. Therefore, I suggest adding an unprefixed variant of requestAnimationFrame.

(Whether or when to remove the prefixed version is intentionally out of scope of what I wrote above.)
Comment 1 Masatoshi Kimura [:emk] 2011-11-21 01:29:37 PST
We shouldn't unprefix at least until we implement cancelRequestAnimationFrame.
Web authors workarounds the lacking of mozCancelRequestAnimationFrame by using a code as follows (with an expectation that we will implement mozCancelRequestAnimationFrame soon):
http://subtech.g.hatena.ne.jp/mayuki/20110821
If we unprefixed without cancelRequestAnimationFrame, the code will be broken.
Comment 2 Boris Zbarsky [:bz] 2011-11-21 04:42:53 PST
Actually, there's at least one pending change that's a breaking change (which may not have a bug filed on it): dropping the zero-argument version of mozRequestAnimationFrame.

But yes, in general, I think we should fix those issues and unprefix this.  Need to find time...
Comment 3 Boris Zbarsky [:bz] 2011-11-21 09:08:09 PST
And another breaking change: onBeforePaint needs to be called "sample" per current draft.

I filed bug 704171 and bug 704063 respectively.
Comment 4 Boris Zbarsky [:bz] 2011-11-21 09:10:11 PST
Er, I meant bug 704175.
Comment 5 :Ms2ger 2012-06-07 06:00:53 PDT
The deps seem fixed, is anything else blocking us?
Comment 6 Henri Sivonen (:hsivonen) 2012-06-07 06:59:14 PDT
IE10 has unprefixed requestAnimationFrame now.
Comment 7 Boris Zbarsky [:bz] 2012-06-07 07:33:43 PDT
Yeah.  We should fix bug 753453 and add the unprefixed version.  Possibly both in this bug....
Comment 8 kritphong 2013-03-08 15:47:11 PST
Chrome has unprefixed requestAnimationFrame now.
Comment 9 Michał Gołębiowski [:m_gol] 2013-03-11 11:09:17 PDT
Not just Chrome, WebKit nightly, too. The parity-webkit flag should be added.
Comment 10 Boris Zbarsky [:bz] 2013-04-18 01:04:27 PDT
Created attachment 738918 [details] [diff] [review]
Add an unprefixed version of requestAnimationFrame.
Comment 11 Olli Pettay [:smaug] 2013-04-18 05:30:08 PDT
Comment on attachment 738918 [details] [diff] [review]
Add an unprefixed version of requestAnimationFrame.

s/shoule/should/

And took awhile to understand the test since I hadn't
noticed bugmail about bug 753453
Comment 13 Ryan VanderMeulen [:RyanVM] 2013-04-25 18:57:22 PDT
https://hg.mozilla.org/mozilla-central/rev/1a7dac116295
Comment 14 Lukas Blakk [:lsblakk] use ?needinfo 2013-05-21 11:10:15 PDT
This has been noted in the Aurora 23 release notes:

http://www.mozilla.org/en-US/firefox/23.0a2/auroranotes/

If you would like to make any changes or have questions/concerns please contact me directly.
Comment 15 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2013-06-17 15:54:42 PDT
Are there any high risk areas which need QA attention as we move into Firefox 23 Beta?
Comment 16 Boris Zbarsky [:bz] 2013-06-17 18:43:38 PDT
"The web"?  Or at least sites using an old GWT (see discussion in bug 753453)....
Comment 17 Mihai Morar, (:MihaiMorar) 2013-06-21 06:22:14 PDT
(In reply to Boris Zbarsky (:bz) (reading mail, but on paternity leave) from comment #16)
> "The web"?  Or at least sites using an old GWT. 

Boris, I don't find any site that is using old Google Web Toolkit. Can you please attach a few so I can verify this fix?
Comment 18 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2013-06-21 14:12:32 PDT
Mihai, after parsing some of the information from the Chromium issue here are a couple you might try:

 * http://www.snae.net/anitest
 * http://tractionsoftware.com/

Apart from that we'll just have to hope to catch issues through our usual web compatibility testing during Beta.
Comment 19 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2013-06-24 17:00:09 PDT
Mihai, can you make sure you test this with Firefox 23b1 candidate builds? We should have them in the next day or so.
Comment 20 Mihai Morar, (:MihaiMorar) 2013-06-25 02:47:33 PDT
(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #19)

Sure,hope tomorrow we will get FF 23b1 and then I'll test.
Comment 21 Mihai Morar, (:MihaiMorar) 2013-06-26 01:05:16 PDT
(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #19)
> Mihai, can you make sure you test this with Firefox 23b1 candidate builds?
> We should have them in the next day or so.

http://tractionsoftware.com/ works as expected using requestAnimationFrame instead of mozRequestAnimationFrame

http://www.snae.net/anitest is not working :

404 Not Found

    Code: NoSuchKey
    Message: The specified key does not exist.
    Key: anitest
    RequestId: 4F68F675A95CBE65
    HostId: 0VOjh5++YlyByD/fLQnMSUzKUeWn+SukH9UbzA+VfQwpzlxkxzS1lio0NSH62DHA

This website is not working on Google Chrome too, but http://www.snae.net works fine on both browsers Firefox 23b1 and Chrome.

Based on these investigations mentioned above I can say this is fixed.
Comment 22 Mihai Morar, (:MihaiMorar) 2013-06-26 01:25:52 PDT
(In reply to Mihai Morar, QA [:MarioMi] from comment #21)

Verification Done on:

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:23.0) Gecko/20100101 Firefox/23.0
Mozilla/5.0 (X11; Linux i686; rv:23.0) Gecko/20100101 Firefox/23.0
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:23.0) Gecko/20100101 Firefox/23.0

Build ID: 20130625125232
Comment 23 Boris Zbarsky [:bz] 2013-08-29 05:34:12 PDT
Is this really dev-doc-complete?  It's not documented at https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/23 for example (instead there is documentation that makes it sounds like the behavior of requestAnimationFrame changed, whereas in reality the function was just added).
Comment 24 Jean-Yves Perrier [:teoli] 2013-09-15 00:46:29 PDT
Boris, sorry for the delay.
Before to update the doc, here is my understanding here:

1. Before (Gecko 22)
mozRequestAnimationFrame() with a callback returning a DOMTimeStamp as single argument.

2. After (Gecko 23)
mozRequestAnimationFrame() with a callback returning a DOMTimeStamp as single argument. (Deprecated,  but unchanged)
requestAnimationFrame with a callback returning a DOMHighResTimeStamp as single argument.

Is this correct?

Currently the Fx for 23 text is indeed a bit confusing.
There is entry for the addition of the unprefixed version and an entry for the change of the callback parameter in it: as both happened during the same cycle, I plan to merge both entries into the creation of the unprefixed version but with different parameters.
Comment 25 Boris Zbarsky [:bz] 2013-09-16 14:48:22 PDT
Jean-Yves, that's correct, yes.  Thank you!

Note You need to log in before you can comment on or make changes to this bug.