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.)
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.
Depends on: 647518
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...
And another breaking change: onBeforePaint needs to be called "sample" per current draft. I filed bug 704171 and bug 704063 respectively.
The deps seem fixed, is anything else blocking us?
IE10 has unprefixed requestAnimationFrame now.
Yeah. We should fix bug 753453 and add the unprefixed version. Possibly both in this bug....
Depends on: 753453
Chrome has unprefixed requestAnimationFrame now.
Not just Chrome, WebKit nightly, too. The parity-webkit flag should be added.
Whiteboard: [parity-IE][parity-webkit] → [need review][parity-IE][parity-webkit]
Attachment #738918 - Flags: superreview?(bugs)
Attachment #738918 - Flags: review?(roc) → review+
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
Attachment #738918 - Flags: superreview?(bugs) → superreview+
Target Milestone: --- → mozilla23
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
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.
Are there any high risk areas which need QA attention as we move into Firefox 23 Beta?
"The web"? Or at least sites using an old GWT (see discussion in bug 753453)....
(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?
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.
Mihai, can you make sure you test this with Firefox 23b1 candidate builds? We should have them in the next day or so.
QA Contact: mihai.morar
(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #19) Sure,hope tomorrow we will get FF 23b1 and then I'll test.
(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.
Status: RESOLVED → VERIFIED
(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
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).
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.
Jean-Yves, that's correct, yes. Thank you!
You need to log in before you can comment on or make changes to this bug.