Bug 208032

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:

Keywords:

InRadar

Version:

Safari Technology Preview

Hardware:

Unspecified

OS:

Unspecified

Attachments:

Description	Flags
Testcase	none
This isn't reliable in WTR either	none
Another flakey version	none
And another	none

Simon Fraser (smfr)

Reported 2020-02-20 14:43:41 PST

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.

Attachments
Testcase (2.73 KB, text/html) 2020-02-20 14:43 PST, Simon Fraser (smfr)	no flags	Details
This isn't reliable in WTR either (3.01 KB, text/html) 2020-02-20 15:10 PST, Simon Fraser (smfr)	no flags	Details
Another flakey version (3.01 KB, text/html) 2020-02-20 16:02 PST, Simon Fraser (smfr)	no flags	Details
And another (3.02 KB, text/html) 2020-02-20 16:04 PST, Simon Fraser (smfr)	no flags	Details
View All Add attachment proposed patch, testcase, etc.

Simon Fraser (smfr)

Comment 1 2020-02-20 14:44:55 PST

One extra setTimeout(, 0) fixes this.

Simon Fraser (smfr)

Comment 2 2020-02-20 14:46:23 PST

(In reply to Simon Fraser (smfr) from comment #1) > One extra setTimeout(, 0) fixes this. Actually no. Even a rAF is super flakey.

Simon Fraser (smfr)

Comment 3 2020-02-20 15:08:41 PST

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.

Radar WebKit Bug Importer

Comment 4 2020-02-20 15:09:03 PST

<rdar://problem/59646027>

Simon Fraser (smfr)

Comment 5 2020-02-20 15:10:13 PST

Created attachment 391340 [details] This isn't reliable in WTR either

Simon Fraser (smfr)

Comment 6 2020-02-20 16:00:10 PST

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.

Simon Fraser (smfr)

Comment 7 2020-02-20 16:02:29 PST

Created attachment 391351 [details] Another flakey version

Simon Fraser (smfr)

Comment 8 2020-02-20 16:04:47 PST

Created attachment 391352 [details] And another

Simon Fraser (smfr)

Comment 9 2020-02-20 16:32:41 PST

Hmm, I was testing with "CSS animations via web animations" turned off. Turn then on and things are better.

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