Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: e7c20293ca2afa594467c3684db0583fa114dbd2
https://github.com/WebKit/WebKit/commit/e7c20293ca2afa594467c3684db0583fa114dbd2
Author: Alan Baradlay <[email protected]>
Date: 2026-08-10 (Mon, 10 Aug 2026)
Changed paths:
A
LayoutTests/imported/w3c/web-platform-tests/css/cssom-view/scroll-width-with-over-constrained-block-in-inline-expected.txt
A
LayoutTests/imported/w3c/web-platform-tests/css/cssom-view/scroll-width-with-over-constrained-block-in-inline.html
M
Source/WebCore/layout/formattingContexts/inline/display/InlineDisplayLineBuilder.cpp
M
Source/WebCore/layout/integration/inline/LayoutIntegrationInlineContentBuilder.cpp
Log Message:
-----------
[block-in-inline] A block level box on a line contributes its margin box to
its container's overflow
https://bugs.webkit.org/show_bug.cgi?id=321302
Reviewed by Antti Koivisto.
A block level box nested in an inline box sits on a line, and the line is made
as wide as that box's margin
box so the box occupies the inline space it needs
(InlineFormattingUtils::inlineItemWidth, and
Line::appendBlock which sets the line's content width to it). That is the right
width for laying out the
line. It is not the right width for the container's overflow, and it was being
used for both.
The two disagree because the inline formatting context and the render tree
resolve the box's margins
differently. The render tree resolves an over-constrained block level box by
adjusting its end margin, which
can go negative, and layoutOverflowRectForPropagation() then adds max(0,
marginEnd), so an over-constrained
box's overflow ends at its border box. The inline formatting context does not
run that resolution - it is
sizing a line, not placing a block sibling - so its margin box keeps the
specified end margin.
<div style="width: 100px; overflow: hidden">
<div>text<span><div style="width: 150px; margin-right:
20px"></div></span></div>
</div>
reports scrollWidth 170 instead of 150. The used end margin is 100 - 150 = -50
and extends nothing, but the line is 170 wide and hands that to the container.
Ink overflow needs the same treatment for a different reason. It was based on
the line's scrollable
overflow, and scrollable overflow is meant to enclose the box - you can scroll
to it. Visual overflow is
not: RenderBox::addOverflowFromChild() returns early for a child with a self
painting layer, so a composited
block level box must contribute nothing. Using the scrollable rect bypassed
that, and the container's
composited bounds grew to enclose a layer it does not paint. A line whose
content is a block level box paints
nothing itself, so start its ink overflow empty and let the box's own
contribution be collected, which
already happens only when the box is not self painting.
*
Source/WebCore/layout/formattingContexts/inline/display/InlineDisplayLineBuilder.cpp:
(WebCore::Layout::InlineDisplayLineBuilder::collectEnclosingLineGeometry const):
*
Source/WebCore/layout/integration/inline/LayoutIntegrationInlineContentBuilder.cpp:
(WebCore::LayoutIntegration::InlineContentBuilder::adjustDisplayLines const):
*
LayoutTests/imported/w3c/web-platform-tests/css/cssom-view/scroll-width-with-over-constrained-block-in-inline.html:
Added.
*
LayoutTests/imported/w3c/web-platform-tests/css/cssom-view/scroll-width-with-over-constrained-block-in-inline-expected.txt:
Added.
Canonical link: https://commits.webkit.org/318906@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
