Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 20aa31cf4f7e280ed5d31810bc553ae98175ca20
https://github.com/WebKit/WebKit/commit/20aa31cf4f7e280ed5d31810bc553ae98175ca20
Author: Claudio Saavedra <[email protected]>
Date: 2026-06-04 (Thu, 04 Jun 2026)
Changed paths:
A
LayoutTests/fast/scrolling/scroll-clamp-during-layout-with-pending-async-scroll-crash-expected.txt
A
LayoutTests/fast/scrolling/scroll-clamp-during-layout-with-pending-async-scroll-crash.html
M Source/WebCore/platform/ScrollView.cpp
Log Message:
-----------
ASSERTION FAILED: !m_deferredScrollDelta platform/ScrollView.cpp(504) :
virtual void WebCore::ScrollView::scrollTo(const WebCore::ScrollPosition &)
https://bugs.webkit.org/show_bug.cgi?id=250907
Reviewed by Simon Fraser.
scrollTo() defers updates during layout into a single-shot
m_deferredScrollDelta,
asserting nothing is already pending. But
AsyncScrollingCoordinator::applyScrollUpdate()
drains queued scrolling-thread updates before applying its own, and both passes
re-enter
scrollTo() via reconcileScrollingState(): the first defers, the second asserts.
The
assertion is wrong because a delta can legitimately already be pending; in
release the
second assignment silently overwrites the first, leaving layers at a bad offset.
Coalesce by summing instead, matching scrollContents()'s cumulative-delta
semantics and
the sibling m_deferredScrollOffsets handling.
Reachable wherever a layout is forced mid-pending-scroll: fullscreen enter,
pinch-zoom
(commitTransientZoom), or a layout-flushing DOM read like offsetWidth.
*
LayoutTests/fast/scrolling/scroll-clamp-during-layout-with-pending-async-scroll-crash-expected.txt:
Added.
*
LayoutTests/fast/scrolling/scroll-clamp-during-layout-with-pending-async-scroll-crash.html:
Added.
* Source/WebCore/platform/ScrollView.cpp:
(WebCore::ScrollView::scrollTo):
Canonical link: https://commits.webkit.org/314619@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
