Closed
Bug 1484901
Opened 6 years ago
Closed 6 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•6 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•6 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•6 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•6 years ago
|
Assignee: nobody → bbirtles
Status: NEW → ASSIGNED
Comment 5•6 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•6 years ago
|
||
bugherder |
Status: ASSIGNED → RESOLVED
Closed: 6 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
•