Closed
Bug 1484901
Opened 7 years ago
Closed 7 years ago
Intermittent tier2 test-verify /web-animations/timing-model/animations/playing-an-animation.html | Resuming an animation from paused calculates start time from hold time - assert_less_than_equal
Categories
(Core :: DOM: Animation, defect, P5)
Core
DOM: Animation
Tracking
()
RESOLVED
FIXED
mozilla63
| Tracking | Status | |
|---|---|---|
| firefox63 | --- | fixed |
People
(Reporter: intermittent-bug-filer, Assigned: birtles)
Details
(Keywords: intermittent-failure)
Attachments
(1 file)
| Assignee | ||
Comment 1•7 years ago
|
||
> expected a number less than or equal to -49824.299358000004 but got -49824.299358
Some sort of floating point error :/
A few notes:
* test-verify only runs when the test is changed, so it might not be intermittent
* the float difference looks a lot like float vs. double accuracy, as though something was a float, then got converted to a double, and some calculations on the double then weren't completely accurate
| Assignee | ||
Comment 3•7 years ago
|
||
(In reply to David Baron :dbaron: 🏴 ⌚UTC-7 from comment #2)
> A few notes:
> * test-verify only runs when the test is changed, so it might not be
> intermittent
Yeah, I ran test-verify on OSX 10.10 before landing this: https://treeherder.mozilla.org/#/jobs?repo=try&revision=b81a22882fbec848257f380114b7b55db05af1b5 so hopefully it's not permafail, but given how soon this failed after adding the test in question, I expect it will be high frequency.
> * the float difference looks a lot like float vs. double accuracy, as
> though something was a float, then got converted to a double, and some
> calculations on the double then weren't completely accurate
We do one calculation using JavaScript Numbers and one using TimeDurations (64-bit integers whose units vary by platform). Normally though that shouldn't be a problem because this is a <= check where we expect it to be significantly less. In the failure case, though, I wonder if we're hitting a combination of vsync timer clamping (which is where the times can end up being equal) and this precision difference.
I'll probably just add some epilson to this check later today.
| Assignee | ||
Comment 4•7 years ago
|
||
This test appears to occasionally fail. The suspected cause is a combination of:
* timer clamping (due to vsync) resulting in the current timeline time after
resuming playback and the "ready time" being equal
* difference in floating-point precision used in calculating the two measures --
one calculation done in JS and one done using the UA's internal representation
of times.
Therefore this patch adds the standard tolerance for comparing time values to
this comparison.
| Assignee | ||
Updated•7 years ago
|
Assignee: nobody → bbirtles
Status: NEW → ASSIGNED
Comment 5•7 years ago
|
||
Comment on attachment 9002678 [details]
Bug 1484901 - Add tolerance for time comparison in playing-an-animation.html; r?hiro
Hiroyuki Ikezoe (:hiro) has approved the revision.
Attachment #9002678 -
Flags: review+
Pushed by bbirtles@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/58b3e7272104
Add tolerance for time comparison in playing-an-animation.html; r=hiro
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/12608 for changes under testing/web-platform/tests
Upstream web-platform-tests status checks passed, PR will merge once commit reaches central.
Comment 9•7 years ago
|
||
| bugherder | ||
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
status-firefox63:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla63
Upstream PR merged
| Comment hidden (Intermittent Failures Robot) |
You need to log in
before you can comment on or make changes to this bug.
Description
•