Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 05c8899231202b50589166d9b02a851f3e6a7178
      
https://github.com/WebKit/WebKit/commit/05c8899231202b50589166d9b02a851f3e6a7178
  Author: Antoine Quint <[email protected]>
  Date:   2026-02-20 (Fri, 20 Feb 2026)

  Changed paths:
    M LayoutTests/platform/ios/TestExpectations
    M LayoutTests/platform/mac-wk2/TestExpectations
    A 
LayoutTests/webanimations/threaded-animations/scroll-driven-animation-failed-assertion-in-scroll-timeline-expected.txt
    A 
LayoutTests/webanimations/threaded-animations/scroll-driven-animation-failed-assertion-in-scroll-timeline.html
    M Source/WebCore/animation/AnimationTimeline.cpp
    M Source/WebCore/animation/AnimationTimeline.h
    M Source/WebCore/animation/DocumentTimeline.h
    M Source/WebCore/animation/ScrollTimeline.cpp
    M Source/WebCore/animation/ScrollTimeline.h

  Log Message:
  -----------
  [threaded-animations] failed assertion 
`ASSERT(sourceScrollableArea->scrollingNodeID())` in 
`ScrollTimeline::computeProgressResolutionData()`
https://bugs.webkit.org/show_bug.cgi?id=308303
rdar://168255217

Reviewed by Anne van Kesteren.

We use `ScrollTimeline::canBeAccelerated()` to determine that a timeline can be 
accelerated in `AcceleratedEffectStackUpdater::takeTimelinesUpdate()`
and guard calls to `ScrollTimeline::updateAcceleratedRepresentation()` and, 
under it,  `ScrollTimeline::computeProgressResolutionData()`,
letting those methods assume that they have a source with a scrolling node ID.

However, `ScrollTimeline::canBeAccelerated()` is not live and returns the 
cached result of `ScrollTimeline::computeCanBeAccelerated()` computed when
`AnimationTimeline::runPostRenderingUpdateTasks()` is called (so that we can 
determine when that status changes one per animation frame).

What `computeCanBeAccelerated()` returns can change between those two call 
chains because the former happen as the layer tree is being committed
and the latter during the page rendering update.

We change `canBeAccelerated()` to be live and rename the flag where we cache 
the value to clarify its purpose.

Finally, we had to make the `canBeAccelerated()` override to be public rather 
than private because it's called specifically on downcast
`ScrollTimeline` instance in 
`AcceleratedEffectStackUpdater::takeTimelinesUpdate()`.

Note that this test hits another failed assertion when run across several 
iterations, we mark it as a flaky crash. This will be dealt with
in a separate patch for bug 308304.

Test: 
webanimations/threaded-animations/scroll-driven-animation-failed-assertion-in-scroll-timeline.html

* LayoutTests/platform/ios/TestExpectations:
* LayoutTests/platform/mac-wk2/TestExpectations:
* 
LayoutTests/webanimations/threaded-animations/scroll-driven-animation-failed-assertion-in-scroll-timeline-expected.txt:
 Added.
* 
LayoutTests/webanimations/threaded-animations/scroll-driven-animation-failed-assertion-in-scroll-timeline.html:
 Added.
* Source/WebCore/animation/AnimationTimeline.cpp:
(WebCore::AnimationTimeline::AnimationTimeline):
(WebCore::AnimationTimeline::runPostRenderingUpdateTasks):
* Source/WebCore/animation/AnimationTimeline.h:
(WebCore::AnimationTimeline::canBeAccelerated const):
(WebCore::AnimationTimeline::computeCanBeAccelerated const): Deleted.
* Source/WebCore/animation/DocumentTimeline.h:
* Source/WebCore/animation/ScrollTimeline.cpp:
(WebCore::ScrollTimeline::canBeAccelerated const):
(WebCore::ScrollTimeline::computeCanBeAccelerated const): Deleted.
* Source/WebCore/animation/ScrollTimeline.h:

Canonical link: https://commits.webkit.org/307965@main



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications

Reply via email to