Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 537cc2c75cc31a12535eb98b9bc6e597508a1405
https://github.com/WebKit/WebKit/commit/537cc2c75cc31a12535eb98b9bc6e597508a1405
Author: Sammy Gill <[email protected]>
Date: 2026-05-19 (Tue, 19 May 2026)
Changed paths:
A
LayoutTests/scrollbars/subtree-root-self-scrollbar-change-during-relayout-crash-expected.txt
A
LayoutTests/scrollbars/subtree-root-self-scrollbar-change-during-relayout-crash.html
M Source/WebCore/rendering/SubtreeScrollbarChangesState.cpp
Log Message:
-----------
ASSERTION FAILED: m_renderBlock.ptr() !=
subtreeScrollbarChangesState->subtreeRoot.ptr().
https://bugs.webkit.org/show_bug.cgi?id=315108
rdar://problem/177442629
Reviewed by Alan Baradlay.
When the destructor for SubtreeScrollbarChangesHandler runs and we end
up in the scenario where we are handling the changes at the subtree root
level (i.e. another descendant was not able to handle the scrollbar
changes), we end up relaying out the subtree root which includes
creating a LayoutScope before the call to layoutBlock.
The problem with that is that LayoutScope will create a
RelayoutScopeForScrollbarChange. In RelayoutScopeForScrollbarChange
detects a change in the scrollbar at that point we will end up deferring
the scrollbar handling to be done later by the renderer that initiated
the tracking. That is not right since *the renderer that initiated the
tracking is the one that gained a scrollbar* and that is what triggers
the assertion we added in 313323@main.
ASSERT(m_renderBlock.ptr() != subtreeScrollbarChangesState->subtreeRoot.ptr());
However, the inner LayoutScope is redundant. The outer LayoutScope in
RenderBlock::layout() already wraps the subtree root and runs after
SubtreeScrollbarChangesStateScope is destroyed, so any self-scrollbar change
that surfaces during the relayout flows through the regular (non-deferred)
self-relayout path in ~RelayoutScopeForScrollbarChange instead of trying to
re-enqueue itself onto a state that is about to disappear.
*
LayoutTests/scrollbars/subtree-root-self-scrollbar-change-during-relayout-crash-expected.txt:
Added.
*
LayoutTests/scrollbars/subtree-root-self-scrollbar-change-during-relayout-crash.html:
Added.
A regression test where an intrinsic-width subtree root (width: max-content,
overflow: auto, fixed height) has both a fixed-width descendant that gains a
horizontal scrollbar mid-layout and enough content to require its own
vertical scrollbar. Without the fix this asserts in debug builds.
* Source/WebCore/rendering/SubtreeScrollbarChangesState.cpp:
(WebCore::SubtreeScrollbarChangesHandler::~SubtreeScrollbarChangesHandler):
Drop the inner LayoutScope wrapping the subtree-root relayout (and the now
unused LayoutScope.h include). The outer LayoutScope in RenderBlock::layout()
runs after the SubtreeScrollbarChangesState is cleared and handles
updateScrollInfoAfterLayout for the subtree root through the normal path.
Canonical link: https://commits.webkit.org/313537@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
