Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: ef84d011acd78015778c666d39ab2b8b788bd44f
https://github.com/WebKit/WebKit/commit/ef84d011acd78015778c666d39ab2b8b788bd44f
Author: Sammy Gill <[email protected]>
Date: 2026-08-28 (Fri, 28 Aug 2026)
Changed paths:
M LayoutTests/TestExpectations
A
LayoutTests/imported/w3c/web-platform-tests/css/css-overflow/abspos-relayout-with-scrollable-descendant-expected.txt
A
LayoutTests/imported/w3c/web-platform-tests/css/css-overflow/abspos-relayout-with-scrollable-descendant-vertical-lr-expected.txt
A
LayoutTests/imported/w3c/web-platform-tests/css/css-overflow/abspos-relayout-with-scrollable-descendant-vertical-lr.html
A
LayoutTests/imported/w3c/web-platform-tests/css/css-overflow/abspos-relayout-with-scrollable-descendant.html
M Source/WebCore/rendering/RenderBlock.cpp
M Source/WebCore/rendering/SubtreeScrollbarChangesState.cpp
Log Message:
-----------
GitHub.com: v2: emoji reaction overlaps code box in comment
https://bugs.webkit.org/show_bug.cgi?id=312152
rdar://183465635
Reviewed by Alan Baradlay.
In 314501@main we attempted this patch in order to fix the described
problem on GitHub.com. This ended up causing a regression on
flights.google.com so it ended up getting reverted. Here we are
reattempting the same patch but with a fix for the regression. This
commit message will focus on that regression fix almost the entirety of
this patch is the same as the original so I will defer the explanation
of the underlying architecture to that commit message.
The main difference in this patch is that instead of calling
setNeedsLayout() on the affected renderer and invalidating all the way
up the containing block chain we invalidate only between that renderer
and the subtree root.
Specifically, instead of having
```
if
(rendererScrollbarChange.sizesAffectedFromScrollbarChanges.contains(LogicalBoxAxis::Block))
renderer->setNeedsLayout();
```
we have
```
if
(rendererScrollbarChange.sizesAffectedFromScrollbarChanges.contains(LogicalBoxAxis::Block))
{
renderer->setNeedsLayout(MarkingBehavior::MarkOnlyThis);
renderer->markContainingBlocksForLayout(subtreeRoot.ptr());
}
```
Here is some markup from the reduced testcase that came out of
flights.google.com:
<span id="positionedInline"> position: relative
<span id="inlineBlock"> inline-block, width: 600px
<div id="flexContainer"> display: flex, width: 500px,
height: auto
<div id="flexItem"></div> width: 100px
<div id="positionedFlexItem"> position: relative, flex: 1
<div id="scroller"> position: absolute, width:
100%, overflow-x: auto
<div id="overflowingContent"> width: 300px
<span id="targetContainingBlock"> inline-block, position: relative
<div id="target"></div> position: absolute, height: 20px
#flexContainer is the subtree root: a block-level flex box with an auto
block-size, so
sizesAffectedByScrollbarsForSubtreeRoot() tracks its block axis. Widening
#flexItem to
450px shrinks #positionedFlexItem, and therefore #scroller, to 50px, so
#overflowingContent overflows and #scroller gains a horizontal scrollbar during
#flexContainer's layout.
The call to setNeedsLayout() on #scroller walks up the containing block chain
and dirties the renderers past #flexContainer.
For RenderBlock ancestors above the subtree root this is harmless.
Layout is descending through them, so they already carry the bit and the walk
early-outs, and
anything that does get set is cleared on the way back out. For
RenderInline this does not appear to be the case. Before we run inline
layout we run some invalidation via
RenderBlockFlow::markInlineContentDirtyForLayout().
In the above example we would call clearNeedsLayout on #positionedInline
before running layout on the inline block. Then during the inline
block's layout we end up dirtying #positionedInline again from the
resulting scrollbar handling code.
To get around this we can scope our invalidation only to the subtree
root that is handling the scrollbar change. This is much more precise
anyways since we know for sure we will be running layout again starting
at that renderer.
Canonical link: https://commits.webkit.org/320066@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
