Closed Bug 1484901 Opened Last year Closed Last year

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)

defect

Tracking

()

RESOLVED FIXED
mozilla63
Tracking Status
firefox63 --- fixed

People

(Reporter: intermittent-bug-filer, Assigned: birtles)

Details

(Keywords: intermittent-failure)

Attachments

(1 file)

> 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
(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.
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: nobody → bbirtles
Status: NEW → ASSIGNED
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.
https://hg.mozilla.org/mozilla-central/rev/58b3e7272104
Status: ASSIGNED → RESOLVED
Closed: Last year
Resolution: --- → FIXED
Target Milestone: --- → mozilla63
You need to log in before you can comment on or make changes to this bug.