[web-animations-2] [scroll-animations] should calling `play()` reset the start time of a scroll-driven animation?

[graouts]

The WPT test scroll-animations/scroll-timelines/play-animation.html has a "Playing a running animation resets a sticky start time" subtest that assumes that a running scroll-driven animation with an explicitly-set start time should reset its start time when play() is called:

promise_test(async t => {
  const animation = createScrollLinkedAnimation(t);
  animation.play();
  await animation.ready;
  animation.currentTime = CSSNumericValue.parse("10%");
  assert_percents_equal(animation.currentTime, 10);
  animation.play();
  await animation.ready;
  assert_percents_equal(animation.currentTime, 0);
}, 'Playing a running animation resets a sticky start time');

From my reading of the spec, when animation.currentTime is explicitly set, the animation's start time is resolved and the hold time is unresolved. At this stage, both Chrome and WebKit agree that:

• the animation is not pending,
• the play state is "running",
• the start time is -10%.

So upon animation.play() being called, the playing an animation procedure is called with the auto-rewind flag set to true. In step 3, has finite timeline will be set to true since the animation is associated with a scroll timeline. This means that in step 5, enable seek will be set to false. As a result, reading from the rest of the procedure, I don't see how either the animation hold time or start time is modified during this procedure and we abort the procedure in step 10.

What this test is doing seems fine to me, but it seems the spec does not support it at the moment.

[graouts]

Cc @kevers-google who seems to have authored this test, as well as @flackr, @andruud and @bramus.

[kevers-google]

The Blink implementation for playing-an-animation has deviated significantly from what is currently in the web-animations-2 spec. Not sure how updating the spec got overlooked (not seeing a correction in scroll-animations-1 either). The specced version does not accommodate view-timelines as we simply don't know what start time to use until layout and we know the start and end of the active range. To start, I can summarize the revised algorithm in Blink with an explanation of the rationale here, and then we can look into updating the spec:

1. Let aborted pause be a boolean flag that is true if animation has a pending pause task, and false otherwise.
2. Let has pending ready promise be a boolean flag that is initially false.
3. Let has finite timeline be true if animation has an associated timeline that is not monotonically increasing.
4. Let enable seek be true if auto-rewind is set and finite timeline is not set.
5. Let seek time be a time value that is initially unresolved.
6. Let previous current time be the animation’s current time
7. If reset current time on resume is set:
   * Set previous current time to unresolved.
   * Set the reset current time on resume flag to false.
8. Perform the steps corresponding to the first matching condition from the following, if any:
   * If animation’s effective playback rate > 0, the enable seek flag is true and either animation’s:
   * previous current time is unresolved, or
   * previous current time < zero, or
   * previous current time ≥ associated effect end,
   Set seek time to zero.
   * If animation’s effective playback rate < 0, the enable seek flag is true and either animation’s:
   * previous current time is unresolved, or
   * previous current time ≤ zero, or
   * previous current time > associated effect end,
   If associated effect end is positive infinity,
   throw an "InvalidStateError" DOMException and abort these steps.
   Otherwise,
   Set seek time to animation’s associated effect end.
   * If animation’s effective playback rate = 0 and animation’s current time is unresolved,
   Set seek time to zero.
9. If has finite timeline and auto rewind is enabled
   • reset the flag for auto-aligned start time
   • set hold time = previous current time
10. If seek time is resolved
    set hold time = seek time
11. If hold time is resolved
    ...

Rest of steps are in alignment with spec.

Recap of what has changed in Blink:

• Don't set start time when using a finite timeline since we don't necessarily know that the start time is. Calculation of the deferred start time should be covered in scroll-animations-1.
• Restrict rewinding to the start or end of the animation to time based animations.
• Checks with "auto rewind enabled" changed to "seek enabled" which has added constraint of being a monotonic timeline.
• Resets a sticky start time playing with a finite timeline and auto-rewind enabled.