704063 - Add unprefixed requestAnimationFrame

Status: VERIFIED FIXED

(Core :: Layout, defect)

Description

[Henri Sivonen (:hsivonen)]

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

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 [:bzbarsky]]

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 [:bzbarsky]]

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 [:bzbarsky]]

Er, I meant bug 704175.

Comment 5

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

The deps seem fixed, is anything else blocking us?

Comment 6

[Henri Sivonen (:hsivonen)]

IE10 has unprefixed requestAnimationFrame now.

Comment 7

[Boris Zbarsky [:bzbarsky]]

Yeah.  We should fix bug 753453 and add the unprefixed version.  Possibly both in this bug....

Comment 8

[kritphong]

Chrome has unprefixed requestAnimationFrame now.

Comment 9

[Michał Gołębiowski-Owczarek [:mgol]]

Not just Chrome, WebKit nightly, too. The parity-webkit flag should be added.

Comment 10

[Boris Zbarsky [:bzbarsky]]

Attachment: Add an unprefixed version of requestAnimationFrame.

Comment 11

[Olli Pettay [:smaug][[e-mail]]]

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 12

[Boris Zbarsky [:bzbarsky]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/1a7dac116295

Comment 13

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/1a7dac116295

Comment 14

[Lukas Blakk [:lsblakk] use ?needinfo]

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

[u279076]

Are there any high risk areas which need QA attention as we move into Firefox 23 Beta?

Comment 16

[Boris Zbarsky [:bzbarsky]]

"The web"?  Or at least sites using an old GWT (see discussion in bug 753453)....

Comment 17

[Mihai Morar, (:MihaiMorar)]

(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

[u279076]

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

[u279076]

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)]

(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)]

(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)]

(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 [:bzbarsky]]

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

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 [:bzbarsky]]

Jean-Yves, that's correct, yes.  Thank you!