Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 6c93b8ced48c62e201b957d849faf08cfc73ea91
https://github.com/WebKit/WebKit/commit/6c93b8ced48c62e201b957d849faf08cfc73ea91
Author: Richard Robinson <[email protected]>
Date: 2026-06-29 (Mon, 29 Jun 2026)
Changed paths:
M Source/WebKit/UIProcess/RemoteLayerTree/mac/RemoteScrollingTreeMac.mm
Log Message:
-----------
[Debug] UI process sometimes crashes after scroll to refresh
(ScrollingThread::isCurrentThread() assert under
RemoteScrollingTreeMac::hasNodeWithAnimatedScrollChanged())
https://bugs.webkit.org/show_bug.cgi?id=318100
rdar://179514078
Reviewed by Simon Fraser and Abrar Rahman Protyasha.
RemoteScrollingTreeMac::hasNodeWithAnimatedScrollChanged() asserted that it was
running on the scrolling thread, but it can also legitimately be reached on the
main thread. After a scroll-to-refresh driven reload, the scrolling tree is
committed on the main thread, and
ScrollingTreeScrollingNodeDelegateMac::updateFromStateNode()
restores the saved rubber-band state by synchronously starting a rubber-band
animation.
That calls setScrollAnimationInProgress(true), which toggles
ScrollingTree::m_treeState.nodesWithActiveScrollAnimations from empty to
non-empty and
invokes hasNodeWithAnimatedScrollChanged() — on the main thread, tripping
ASSERT(ScrollingThread::isCurrentThread()) in debug builds.
The assertion was overly strict. The mutated state is guarded by
m_treeStateLock,
which is held across the mutation regardless of the calling thread, and the
override body only does a RunLoop::mainSingleton().dispatch(), which is safe
from
any thread; the main-thread caller was therefore always correct.
Fix by removing the assertion.
* Source/WebKit/UIProcess/RemoteLayerTree/mac/RemoteScrollingTreeMac.mm:
(WebKit::RemoteScrollingTreeMac::hasNodeWithAnimatedScrollChanged):
Canonical link: https://commits.webkit.org/316068@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
