Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 928daa1cfd842184684d3f14365f82c93352695f
https://github.com/WebKit/WebKit/commit/928daa1cfd842184684d3f14365f82c93352695f
Author: Ahmad Saleem <[email protected]>
Date: 2026-08-19 (Wed, 19 Aug 2026)
Changed paths:
A
LayoutTests/imported/w3c/web-platform-tests/scroll-animations/css/view-timeline-unresolved-current-time-at-effect-end-expected.txt
A
LayoutTests/imported/w3c/web-platform-tests/scroll-animations/css/view-timeline-unresolved-current-time-at-effect-end.html
M Source/WebCore/animation/AnimationEffectTiming.cpp
Log Message:
-----------
[scroll-animations] An unresolved progress-based timeline current time is
treated as a progress timeline boundary
https://bugs.webkit.org/show_bug.cgi?id=320882
rdar://183902668
Reviewed by Antoine Quint.
Step 3 of [1] sets "unlimited current time" from the timeline time when the
animation's
start time is resolved, and only otherwise falls back to the animation's
current time.
We additionally required the timeline time to be resolved before taking the
first
branch, so a resolved start time paired with an unresolved timeline time
silently took
the fallback.
That is wrong for an animation holding at its effect end: its hold time equals
the
timeline duration, so "effective timeline progress" is exactly 1 and we report a
boundary even though the timeline has no current time. Being at a boundary
suppresses
the after phase, so a "none" fill mode animation stays active and keeps
applying its
100% keyframe instead of reverting to its unanimated style. Per [1] an
unresolved
timeline time instead propagates to "effective timeline progress", which is then
neither 0 nor 1, so the procedure returns false. Return false on that branch,
leaving
the start-time-unresolved branch to use the animation's current time as [1]
specifies.
This is why animation-inactive-outside-range-test.html is flaky. Its "After
cover
phase" indicator is the only one of the four whose local time is held exactly
on its
active-after boundary, so it is the only one whose phase hinges on this
predicate
rather than on a strict inequality; one frame with an unresolved view timeline
current
time paints it green instead of grey.
[1] https://drafts.csswg.org/web-animations-2/#at-progress-timeline-boundary
Test:
imported/w3c/web-platform-tests/scroll-animations/css/view-timeline-unresolved-current-time-at-effect-end.html
*
LayoutTests/imported/w3c/web-platform-tests/scroll-animations/css/view-timeline-unresolved-current-time-at-effect-end-expected.txt:
Added.
*
LayoutTests/imported/w3c/web-platform-tests/scroll-animations/css/view-timeline-unresolved-current-time-at-effect-end.html:
Added.
* Source/WebCore/animation/AnimationEffectTiming.cpp:
(WebCore::AnimationEffectTiming::getBasicTiming const):
Canonical link: https://commits.webkit.org/319442@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
