[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.