Increase animation duration in WPT animation-display-lock.html to make it more robust
Categories
(Core :: Layout, task)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox133 | --- | fixed |
People
(Reporter: dholbert, Assigned: dholbert)
References
Details
Attachments
(1 file)
Per bug 1895554 comment 21 and the test failure annotation:
- WPT animation-display-lock.html (wpt.fyi, wpt.live) intermittently fails on slowish platforms like TSAN and ASAN.
- The test has a hardcoded 1-second-long animation and transition, and the test manually advance the animation timeline (by setting
.currentTime); BUT, I'm pretty sure those animations can also just repeat/complete on their own before we advancecurrentTime(e.g. inside of calls likeawait waitForAnimationFrames(1);) - ...and I think that's essentially what's happening when we experience a test-timeout.
- I can reproduce similar test-timeouts on Chrome and Firefox if I reduce the animation durations to be
0.1s(which makes the animations more-readily complete on-their-own, without currentTime advancing, even in release builds). - So: these timeouts aren't a browser bug; they're just a hazard baked into the test that browsers can trip over if the 1s test-duration is too short relative to how long other things are taking to complete.
- ...and we can avoid the timeouts if we simply increase the animation durations (and the associated
currentTimevalues in the test, etc.)
I've got a patch on Try that makes this change and removes the test-failure annotation:
https://treeherder.mozilla.org/jobs?repo=try&revision=7de30cf2d1ed8c7cbf905b6385c53f83a363871a
Hoping that it passes...
|
Assignee | |
Comment 1•1 year ago
|
||
Before this change, some pieces of this test intermittently timed out or failed
to run, in the more-heavyweight Firefox configurations (e.g. TSAN/ASAN,
particularly with debugging enabled). These failures seem to be because the
animation/transition durations in this test were too short, such that the
animation/transition occasionally complete on their own before the test is
ready for them to complete (i.e. before the test explicitly advances to the end
of an animation by programmatically setting 'currentTime').
I can reproduce similar failures in release Firefox and Chrome builds if I
simply reduce the animation/transition durations (from 1s to 0.1s), so I think
these failures are an indication of a race condition in the test logic (a
fragile dependency on the animation taking "long enough" that it won't complete
on its own), rather than a browser bug.
This patch attempts to avoid these intermittent failures by increasing the
animation durations by 10x, so that they're much less likely to complete on
their own. Note that the standard WPT test-timeout is 10s, so it's reasonable
to expect that the test shouldn't take longer than that (and hence we won't
accidentally let these animations play to completion before the test logic has
a chance to advance them).
This patch also updates the logic/expectations to account for the new
duration. e.g. we now set currentTime to 19999 (19.999s) rather than 1.999
(1.99s), to advance to just before the end of the second repetition of our
animation. And this means we'll be slightly further through the animation, so
the test's assertions now expect an opacity of 0.9999 rather than just 0.999.
|
|
Assignee | |
Comment 2•1 year ago
|
||
(In reply to Daniel Holbert [:dholbert] from comment #0)
I've got a patch on Try that makes this change and removes the test-failure annotation:
https://treeherder.mozilla.org/jobs?repo=try&revision=7de30cf2d1ed8c7cbf905b6385c53f83a363871aHoping that it passes...
Try looks green, hooray!
|
||
Comment 5•1 year ago
|
||
| bugherder | ||
Description
•