Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: fbc2ba96701566dec329231d24c888d5d1831ad3
https://github.com/WebKit/WebKit/commit/fbc2ba96701566dec329231d24c888d5d1831ad3
Author: Ahmad Saleem <[email protected]>
Date: 2026-09-01 (Tue, 01 Sep 2026)
Changed paths:
A
LayoutTests/imported/w3c/web-platform-tests/scroll-animations/css/view-timeline-scroll-range-source-content-resize-expected.txt
A
LayoutTests/imported/w3c/web-platform-tests/scroll-animations/css/view-timeline-scroll-range-source-content-resize.html
M Source/WebCore/animation/ViewTimeline.cpp
Log Message:
-----------
An animation attached to a view timeline's scroll range is not updated when
the scroll container's scrollable overflow changes
https://bugs.webkit.org/show_bug.cgi?id=322109
rdar://185328465
Reviewed by Antoine Quint.
ViewTimeline::cacheCurrentTime() left maxScrollOffset out of the metrics it
compares
against the previously cached data, so a change of the scroll container's
maximum
scroll offset alone would not call sourceMetricsDidChange().
That value is what defines the "scroll" view progress timeline range [1], whose
100%
is the endmost scroll position of the scroll container, ie. the scrollable
overflow
size minus the scroll container size [2]. Growing content that follows the
subject
moves that position while the subject's offset and size, the scroll container's
size,
the insets and the stickiness data are all unchanged, so an animation attached
to
that range kept using the range computed for the previous scrollable overflow
until
some unrelated metric happened to change. Updating the timeline's ranges here is
required by the event loop integration [3]:
After step 7.14 if any timelines' named timeline ranges have changed, these
timelines are added to the stale timelines set. If there are any stale
timelines, they now update their current time and associated ranges [...]
ScrollTimeline::cacheCurrentTime() already compares maxScrollOffset, and the
staleness
check in ScrollTimeline::updateCurrentTimeIfStale() does not cover view
timelines
since those never set m_source, so nothing else caught this.
Match Firefox and the specification by including maxScrollOffset in the
comparison.
[1]
https://drafts.csswg.org/scroll-animations-1/#valdef-animation-timeline-range-scroll
[2] https://drafts.csswg.org/scroll-animations-1/#scroll-timeline-progress
[3] https://drafts.csswg.org/scroll-animations-1/#event-loop
Test:
imported/w3c/web-platform-tests/scroll-animations/css/view-timeline-scroll-range-source-content-resize.html
*
LayoutTests/imported/w3c/web-platform-tests/scroll-animations/css/view-timeline-scroll-range-source-content-resize-expected.txt:
Added.
*
LayoutTests/imported/w3c/web-platform-tests/scroll-animations/css/view-timeline-scroll-range-source-content-resize.html:
Added.
* Source/WebCore/animation/ViewTimeline.cpp:
(WebCore::ViewTimeline::cacheCurrentTime):
Canonical link: https://commits.webkit.org/320244@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
