| Summary: | Animations sometimes don't start before the next requestAnimationFrame | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Simon Fraser (smfr) <simon.fraser> | ||||||||||
| Component: | Animations | Assignee: | Nobody <webkit-unassigned> | ||||||||||
| Status: | RESOLVED INVALID | ||||||||||||
| Severity: | Normal | CC: | dino, graouts, simon.fraser, webkit-bug-importer | ||||||||||
| Priority: | P2 | Keywords: | InRadar | ||||||||||
| Version: | Safari Technology Preview | ||||||||||||
| Hardware: | Unspecified | ||||||||||||
| OS: | Unspecified | ||||||||||||
| Attachments: |
|
||||||||||||
One extra setTimeout(, 0) fixes this. (In reply to Simon Fraser (smfr) from comment #1) > One extra setTimeout(, 0) fixes this. Actually no. Even a rAF is super flakey. In general, it seems that we don't reliably start animations (and fire events) before the next rAF. This makes it really hard to write compatible animation code. Created attachment 391340 [details]
This isn't reliable in WTR either
I found that forcing layout after the document.body.classList.remove('changed'); makes things better; we seem to batch the document.body.classList.remove('changed')/document.body.classList.add('changed') and think nothing changed.
Created attachment 391351 [details]
Another flakey version
Created attachment 391352 [details]
And another
Hmm, I was testing with "CSS animations via web animations" turned off. Turn then on and things are better. |
Created attachment 391337 [details] Testcase Attached testcase shows that we don't always trigger animations before the next requestAnimationFrame. Chrome and Firefox do. Need two drop the testcase into LayoutTests/animations.