Re: [csswg-drafts] [scroll-animations][web-animations-2] rewinding a finished scroll-driven animation and playing it again (#11270)

If I recall correctly, this batch of tests was added prior to the introduction of auto-aligned start times, and was essentially a duplicate of equivalent tests with a document time.  The Blink implementation has changed considerably since the test was introduced.   The intent of the test was to verify that onfinish would fire each time we scroll to the end. I believe the test should read:

```
animation.onfinish = event => {
  window.requestAnimationFrame(() => {
    scroller.scrollTop = 0;
    window.requestAnimationFrame(() => {
      scroller.scrollTop = maxScroll;
      animation.onfinish = ...
    });
  });
}
```
The call to play() is not needed if we ensure that we have an animation tick with the reset scroll position.

This test is passing in Blink for another reason (likely requiring a spec tweak).  In Blink, explicit calls to play() reset any stickiness of the start time and force a new start time to be evaluated.  Stickiness in the timeline arises when explicitly setting the currentTime of a scroll-driven animation. This overrides the auto-aligned start time, at while point the animation progress is no longer strictly aligned with the calculated range.  In this example, the start time is not sticky, and it is arguable if play should simply abort as a no-op.  In the Blink implementation, any call to play with a scrollTimeline forces a new startTime to be evaluated.

As the test is currently written, play() is indirectly triggering the reset in UpdateFinishedState.  The reason for the change to UpdateFinishedState was that we cannot update the finished state while waiting on an deferred start time.  We should have a separate test for an explicit call to play resetting stickiness. I believe one already exists, but have not hunted it down.

-- 
GitHub Notification of comment by kevers-google
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11270#issuecomment-2501445432 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Tuesday, 26 November 2024 17:01:02 UTC