Closed Bug 1180559 Opened 5 years ago Closed 5 years ago

Enable Animation.playbackRate tests on android

Categories

(Core :: DOM: Animation, defect)

defect
Not set

Tracking

()

RESOLVED DUPLICATE of bug 1127380

People

(Reporter: hiro, Unassigned)

References

Details

The tests fail on android emulator.  We need to investigate the failure reason and enable the tests.

https://treeherder.mozilla.org/#/jobs?repo=try&revision=dd9b3fc5280f
155 INFO TEST-UNEXPECTED-FAIL | dom/animation/test/css-animations/test_animation-playbackrate.html | Test the effect of setting playbackRate on currentTime - Test the effect of setting playbackRate on currentTime: assert_approx_equals: animation.currentTime should be 10 times faster than timeline. expected 8999.999639999996 +/- 0.001 but got 1786.0272100000002


151 INFO TEST-UNEXPECTED-FAIL | dom/animation/test/css-animations/test_animation-playbackrate.html | Test the effect of setting playbackRate on currentTime - Test the effect of setting playbackRate on currentTime: assert_approx_equals: animation.currentTime should be 10 times faster than timeline. expected 28199.876300000014 +/- 0.001 but got 0
152 INFO TEST-UNEXPECTED-FAIL | dom/animation/test/css-animations/test_animation-playbackrate.html | Test the effect of setting playbackRate while playing animation - Test the effect of setting playbackRate while playing animation: assert_approx_equals: animation.currentTime should be the same speed as timeline now. expected 2819.9876300000014 +/- 0.001 but got 0 

I've confirmed that longer animation duration does solve the failure but I think it just hides the real reason.

https://treeherder.mozilla.org/#/jobs?repo=try&revision=68fd1bb369c5
(In reply to Hiroyuki Ikezoe (:hiro) from comment #0)
> The tests fail on android emulator.  We need to investigate the failure
> reason and enable the tests.
> 
> https://treeherder.mozilla.org/#/jobs?repo=try&revision=dd9b3fc5280f
> 155 INFO TEST-UNEXPECTED-FAIL |
> dom/animation/test/css-animations/test_animation-playbackrate.html | Test
> the effect of setting playbackRate on currentTime - Test the effect of
> setting playbackRate on currentTime: assert_approx_equals:
> animation.currentTime should be 10 times faster than timeline. expected
> 8999.999639999996 +/- 0.001 but got 1786.0272100000002

I could confirm this case.
In this case animation.currentTime was 10s, so the animation had been already finished at that time.
(In reply to Hiroyuki Ikezoe (:hiro) from comment #0)
> 151 INFO TEST-UNEXPECTED-FAIL |
> dom/animation/test/css-animations/test_animation-playbackrate.html | Test
> the effect of setting playbackRate on currentTime - Test the effect of
> setting playbackRate on currentTime: assert_approx_equals:
> animation.currentTime should be 10 times faster than timeline. expected
> 28199.876300000014 +/- 0.001 but got 0
> 152 INFO TEST-UNEXPECTED-FAIL |
> dom/animation/test/css-animations/test_animation-playbackrate.html | Test
> the effect of setting playbackRate while playing animation - Test the effect
> of setting playbackRate while playing animation: assert_approx_equals:
> animation.currentTime should be the same speed as timeline now. expected
> 2819.9876300000014 +/- 0.001 but got 0 

I can not reproduce this case yet. i.e. the difference between animation.currentTime and the prior animation.currentTime == 0. But I am now suspecting the animation had been already finished in the prior frame. So the difference must be zero.
(In reply to Hiroyuki Ikezoe (:hiro) from comment #1)
> I could confirm this case.
> In this case animation.currentTime was 10s, so the animation had been
> already finished at that time.

That sounds quite likely. The build machines can get really bogged down so sometimes there will be 10s between frames. We should make this animation 100s long.

(In reply to Hiroyuki Ikezoe (:hiro) from comment #2)
> (In reply to Hiroyuki Ikezoe (:hiro) from comment #0)
> > 151 INFO TEST-UNEXPECTED-FAIL |
> > dom/animation/test/css-animations/test_animation-playbackrate.html | Test
> > the effect of setting playbackRate on currentTime - Test the effect of
> > setting playbackRate on currentTime: assert_approx_equals:
> > animation.currentTime should be 10 times faster than timeline. expected
> > 28199.876300000014 +/- 0.001 but got 0
> > 152 INFO TEST-UNEXPECTED-FAIL |
> > dom/animation/test/css-animations/test_animation-playbackrate.html | Test
> > the effect of setting playbackRate while playing animation - Test the effect
> > of setting playbackRate while playing animation: assert_approx_equals:
> > animation.currentTime should be the same speed as timeline now. expected
> > 2819.9876300000014 +/- 0.001 but got 0 
> 
> I can not reproduce this case yet. i.e. the difference between
> animation.currentTime and the prior animation.currentTime == 0. But I am now
> suspecting the animation had been already finished in the prior frame. So
> the difference must be zero.

Yes that could happen if the animation had finished too since the currentTime doesn't change after it has finished.
(In reply to Brian Birtles (:birtles) from comment #3)
> (In reply to Hiroyuki Ikezoe (:hiro) from comment #1)
> > I could confirm this case.
> > In this case animation.currentTime was 10s, so the animation had been
> > already finished at that time.
> 
> That sounds quite likely. The build machines can get really bogged down so
> sometimes there will be 10s between frames. We should make this animation
> 100s long.

I am now thinking playbackRate should be also reduce to 2x.
(In reply to Brian Birtles (:birtles) from comment #3)
> (In reply to Hiroyuki Ikezoe (:hiro) from comment #1)
> > I could confirm this case.
> > In this case animation.currentTime was 10s, so the animation had been
> > already finished at that time.
> 
> That sounds quite likely. The build machines can get really bogged down so
> sometimes there will be 10s between frames. 

To be precise the value is 1s in this case because playbackRate was 10 there. I've been seeing that a frame takes sometimes 1s over while frame timing API tests on android emulator. So 10s is too short and 10x playbackRate is too big.
https://treeherder.mozilla.org/#/jobs?repo=try&revision=2891b5a0d90f

100s and 2x playbackRate seems perfect on try. And I confirmed that the mochitest with --run-until-failure --repeat 100 is also perfect on local android emulator.

I will post the patch to bug 1127380.
Fixed in the patch for bug 1127380!
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1127380
You need to log in before you can comment on or make changes to this bug.