gecko-dev/testing/web-platform/tests/web-animations/timing-model/animations/pausing-an-animation.html
Brian Birtles 284e3445aa Bug 1466031 - Update test_animation-starttime.html; r=hiro
This patch updates the tests in this file as follows:

* startTime of a newly created (play-pending) animation is unresolved
  -> Covered by 'startTime of a play-pending animation is unresolved'
     in wpt/web-animations/interfaces/Animation/startTime.html

     However, it would be useful to have a test a new CSS animation is
     play-pending so I have extended the test in test_animation-playstate.html
     to cover this.

* startTime of a newly created (pause-pending) animation is unresolved
  -> Covered by 'startTime of a pause-pending animation is unresolved'
     in wpt/web-animations/interfaces/Animation/startTime.html

* startTime is resolved when running
  -> Covered by 'startTime is resolved when running'
     in wpt/web-animations/interfaces/Animation/startTime.html

* startTime is unresolved when paused
  -> Moved to wpt/web-animations/timing-model/animations/pausing-an-animation.html

* startTime while pause-pending and play-pending
  -> Moved to wpt/web-animations/timing-model/animations/pausing-an-animation.html

* startTime while play-pending from finished state,
  startTime while play-pending from finished state using finish()
  -> Merged and moved to wpt/web-animations/timing-model/animations/playing-an-animation.html

* Pausing should make the startTime become null
  -> Simplified and merged into the test for 'startTime is unresolved when
     paused' / 'Pausing clears the start time' test in
     wpt/web-animations/timing-model/animations/pausing-an-animation.html

* Sanity test to check round-tripping assigning to a new animation's startTime
  -> Updated and left.

* Skipping forward through animation
  -> This is really testing two things:
     (a) That you can seek a CSS animation using the start time.
         For this it makes sense to have a separate test that also checks that
         the computed style is updated (like we have for current time).
     (b) That seeking a CSS animation using the start time triggers
         dispatching events.

     This patch splits the above into two separate tests.

* Skipping backwards through animation,
  Redundant change, before -> active, then back,
  Redundant change, before -> after, then back,
  Redundant change, active -> before, then back,
  Redundant change, active -> after, then back,
  Redundant change, after -> before, then back,
  Redundant change, after -> active, then back
  -> All these tests are really just exercising event dispatch which is
     already covered by test_event-dispatch.html.

     Provided we have a test that checks that events are dispatched when
     setting the startTime we don't need to test each combination again since
     we have tests for each of these combinations already when using the
     currentTime to seek and we can assume UAs are following the same code
     path at this point.

     As a result this patch drops these tests.

* Setting startTime to null
  -> Covered by 'Setting an unresolved start time sets the hold time'
     in wpt/web-animations/timing-model/animations/setting-the-start-time-of-an-animation.html

* Animation.startTime after pausing
  -> Covered by the new 'Pausing clears the start time' test in
     wpt/web-animations/timing-model/animations/pausing-an-animation.html

* Animation.startTime after canceling
  -> Merged into
     wpt/web-animations/timing-model/animations/canceling-an-animation.html
     and made it follow the spec a little more closely (which requires
     clearing the start time and hold time).

--HG--
extra : rebase_source : 9bb3d82e18e5c2d9654576502a1d4263a1e46daa
2018-06-04 10:20:57 +09:00

93 lines
3 KiB
HTML

<!DOCTYPE html>
<meta charset=utf-8>
<title>Pausing an animation</title>
<link rel="help"
href="https://drafts.csswg.org/web-animations/#pausing-an-animation-section">
<script src="/resources/testharness.js"></script>
<script src="/resources/testharnessreport.js"></script>
<script src="../../testcommon.js"></script>
<body>
<div id="log"></div>
<script>
'use strict';
promise_test(async t => {
const animation = createDiv(t).animate(null, 100 * MS_PER_SEC);
await animation.ready;
const startTimeBeforePausing = animation.startTime;
animation.pause();
assert_equals(animation.startTime, startTimeBeforePausing,
'The start time does not change when pausing-pending');
await animation.ready;
assert_equals(animation.startTime, null,
'The start time is unresolved when paused');
}, 'Pausing clears the start time');
promise_test(async t => {
const animation = createDiv(t).animate(null, 100 * MS_PER_SEC);
await animation.ready;
animation.pause();
assert_not_equals(animation.startTime, null,
'The start time is resolved when pause-pending');
animation.play();
assert_not_equals(animation.startTime, null,
'The start time is preserved when a pause is aborted');
}, 'Aborting a pause preserves the start time');
promise_test(async t => {
const animation = createDiv(t).animate(null, 100 * MS_PER_SEC);
const promise = animation.ready;
animation.pause();
const promiseResult = await promise;
assert_equals(promiseResult, animation);
assert_equals(animation.ready, promise);
assert_false(animation.pending, 'No longer pause-pending');
}, 'A pending ready promise should be resolved and not replaced when the'
+ ' animation is paused');
promise_test(async t => {
const animation = createDiv(t).animate(null, 100 * MS_PER_SEC);
// Let animation start roughly half-way through
animation.currentTime = 50 * MS_PER_SEC;
await animation.ready;
// Go pause-pending and also set a pending playback rate
animation.pause();
animation.updatePlaybackRate(0.5);
await animation.ready;
// If the current time was updated using the new playback rate it will jump
// back to 25s but if we correctly used the old playback rate the current time
// will be >50s.
assert_greater_than(animation.currentTime, 50 * MS_PER_SEC);
}, 'A pause-pending animation maintains the current time when applying a'
+ ' pending playback rate');
promise_test(async t => {
// This test does not cover a specific step in the algorithm but serves as a
// high-level sanity check that pausing does, in fact, freeze the current
// time.
const animation = createDiv(t).animate(null, 100 * MS_PER_SEC);
await animation.ready;
animation.pause();
await animation.ready;
const currentTimeAfterPausing = animation.currentTime;
await waitForNextFrame();
assert_equals(animation.currentTime, currentTimeAfterPausing,
'Animation.currentTime is unchanged after pausing');
}, 'The animation\'s current time remains fixed after pausing');
</script>
</body>