Bugzilla

The root cause is that we rely on `Animation::mPendingReadyTime` to change the animation's state from pending to non-pending. However, this is for time-based animation. In order to fix this, a better long-term way is to introduce the progress-based animation (spec issue: https://github.com/w3c/csswg-drafts/issues/4862). For example, in current Chrome Canary (version 98.xxx), `animation.currentTime` returns a percentage value, instead of a time value (so this doesn't match the current draft spec).

Using a fake duration may work but it doesn't match the spec issue. Besides, I noticed we shouldn't use a fixed specified timing for scroll animations. For example, in Chrome, `delay` works by calculating the percentage of `delay` and `duration`. e.g. if delay is 1s, duration is 5s, the scroll animation starts to move after we scroll 20% of scroll-range. And fill should work, based on the animation-fill property.

Besides, I also noticed there is some magic for handling `duration`, e.g. if `duration` is inf, Chrome doesn't create the scroll-linked animation [1]. This may be related to the comment in the spec issue.

[1] https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/animation/animation.cc;l=202-238;drc=fde2db9853cab5681586ea71d877f4cefd5eee13

So in this bug, we may have to update how we handle timing first, and then use some fake time value to make the animation change the pending status. (Obviously, the paused scroll animations are always in paused pending, so we never really pause the animation. And we have the similar issue for PlayPending and Play.)

The root cause is that we rely on `Animation::mPendingReadyTime` to change the animation's state from pending to non-pending. However, this is for time-based animation. In order to fix this, a better long-term way is to introduce the progress-based animation (spec issue: https://github.com/w3c/csswg-drafts/issues/4862). For example, in current Chrome Canary (version 98.xxx), `animation.currentTime` returns a percentage value, instead of a time value (so this doesn't match the current draft spec).

Using a fake duration may work but it doesn't match the spec issue. Besides, I noticed we shouldn't use a fixed specified timing for scroll animations. For example, in Chrome, `delay` works by calculating the percentage of `delay` and `duration`. e.g. if delay is 1s, duration is 5s, the scroll animation starts to move after we scroll 20% of scroll-range. And fill should work, based on the animation-fill property.

Besides, I also noticed there is some magic for handling `duration`, e.g. if `duration` is inf, Chrome doesn't create the scroll-linked animation [1]. This may be related to the comment in the spec issue.

[1] https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/animation/animation.cc;l=202-238;drc=fde2db9853cab5681586ea71d877f4cefd5eee13

So in this bug, a short-term way is: we may have to update how we handle timing first, and then use some fake time value to make the animation change the pending status. (Obviously, the paused scroll animations are always in paused pending, so we never really pause the animation. And we have the similar issue for PlayPending and Play.)

Let's introduce the progress-based animation later, after we get more information from the spec issue.

The root cause is that we rely on `Animation::mPendingReadyTime` to change the animation's state from pending to non-pending. However, this is for time-based animation. In order to fix this, a better long-term way is to introduce the progress-based animation (spec issue: https://github.com/w3c/csswg-drafts/issues/4862, chrome issue [1]). For example, in current Chrome Canary (version 98.xxx), `animation.currentTime` returns a percentage value, instead of a time value (so this doesn't match the current draft spec).

Using a fake duration may work but it doesn't match the spec issue. Besides, I noticed we shouldn't use a fixed specified timing for scroll animations. For example, in Chrome, `delay` works by calculating the percentage of `delay` and `duration`. e.g. if delay is 1s, duration is 5s, the scroll animation starts to move after we scroll 20% of scroll-range. And fill should work, based on the animation-fill property.

Besides, I also noticed there is some magic for handling `duration`, e.g. if `duration` is inf, Chrome doesn't create the scroll-linked animation [2]. This may be related to the comment in the spec issue.

[1] https://bugs.chromium.org/p/chromium/issues/detail?id=1140602
[2] https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/animation/animation.cc;l=202-238;drc=fde2db9853cab5681586ea71d877f4cefd5eee13

So in this bug, a short-term way is: we may have to update how we handle timing first, and then use some fake time value to make the animation change the pending status. (Obviously, the paused scroll animations are always in paused pending, so we never really pause the animation. And we have the similar issue for PlayPending and Play.)

Let's introduce the progress-based animation later, after we get more information from the spec issue.

The root cause is that we rely on `Animation::mPendingReadyTime` to change the animation's state from pending to non-pending. However, this is for time-based animation. In order to fix this, a better long-term way is to introduce the progress-based animation (spec issue: https://github.com/w3c/csswg-drafts/issues/4862, chrome issue: [1]). For example, in current Chrome Canary (version 98.xxx), `animation.currentTime` returns a percentage value, instead of a time value (so this doesn't match the current draft spec).

Using a fake duration may work but it doesn't match the spec issue. Besides, I noticed we shouldn't use a fixed specified timing for scroll animations. For example, in Chrome, `delay` works by calculating the percentage of `delay` and `duration`. e.g. if delay is 1s, duration is 5s, the scroll animation starts to move after we scroll 20% of scroll-range. And fill should work, based on the animation-fill property.

Besides, I also noticed there is some magic for handling `duration`, e.g. if `duration` is inf, Chrome doesn't create the scroll-linked animation [2]. This may be related to the comment in the spec issue.

So in this bug, a short-term way is: we may have to update how we handle timing first, and then use some fake time value to make the animation change the pending status. (Obviously, the paused scroll animations are always in paused pending, so we never really pause the animation. And we have the similar issue for PlayPending and Play.)

I'm not planning to introduce the progress-based animation until we get more information from the spec issue.

[1] https://bugs.chromium.org/p/chromium/issues/detail?id=1140602
[2] https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/animation/animation.cc;l=202-238;drc=fde2db9853cab5681586ea71d877f4cefd5eee13