Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: f157dd8681ebabd624b90a8069080b87c7938187
https://github.com/WebKit/WebKit/commit/f157dd8681ebabd624b90a8069080b87c7938187
Author: Alan Baradlay <[email protected]>
Date: 2026-08-14 (Fri, 14 Aug 2026)
Changed paths:
A
LayoutTests/fast/css/intrinsic-width-with-preserved-whitespace-and-block-level-box-on-a-line-expected.txt
A
LayoutTests/fast/css/intrinsic-width-with-preserved-whitespace-and-block-level-box-on-a-line.html
M Source/WebCore/layout/formattingContexts/inline/InlineLineBuilder.cpp
M Source/WebCore/layout/integration/LayoutIntegrationBoxGeometryUpdater.cpp
M Source/WebCore/layout/integration/LayoutIntegrationCoverage.cpp
M
Source/WebCore/layout/integration/LayoutIntegrationFormattingContextLayout.cpp
M Source/WebCore/layout/integration/LayoutIntegrationUtils.cpp
M Source/WebCore/layout/integration/inline/LayoutIntegrationLineLayout.cpp
Log Message:
-----------
[block-in-inline] IFC cannot compute intrinsic widths when a line holds a
block level box
https://bugs.webkit.org/show_bug.cgi?id=321594
Reviewed by Antti Koivisto.
canUseForIntrinsicWidthComputation walks the inline content and takes text,
line breaks, inline boxes, list
markers, an empty atomic inline level box and fixed width content. A block
level box on a line is none of those,
so the whole container falls back to the legacy walk in
computeInlineIntrinsicLogicalWidths, where the text around
the box is measured word by word rather than by the inline formatting context.
The box's own content is the render tree's to lay out, which is what
LineBuilder::handleBlockContent hands it back
for. Its intrinsic widths are the render tree's to answer for the same reason,
so ask for them there, for the
constraint the intrinsic width loop is running. That keeps the box out of the
box geometry, which is built for one
constraint only and is why this content was turned away in the first place.
Content inside such a box does not damage the lines around it, so the cached
minimum and maximum content sizes
have to go when the root's content widths are invalidated.
The width contribution the render tree answers with is a border box width, so
it has the space a scrollbar takes in
it already, while BoxGeometry::borderBoxWidth adds that space on top of the
content box. Nothing reaching this
before had a scrollbar, since the only box taken here without a fixed width was
an empty one, and an empty box has
nothing to overflow.
The widths in the test only move today because the legacy walk this stops using
is separately wrong about word
spacing wherever it measures text in pieces, so the test passes once either of
the two is fixed.
*
LayoutTests/fast/css/intrinsic-width-with-preserved-whitespace-and-block-level-box-on-a-line.html:
Added.
*
LayoutTests/fast/css/intrinsic-width-with-preserved-whitespace-and-block-level-box-on-a-line-expected.txt:
Added.
* Source/WebCore/layout/formattingContexts/inline/InlineLineBuilder.cpp:
(WebCore::Layout::LineBuilder::handleBlockContent):
* Source/WebCore/layout/integration/LayoutIntegrationCoverage.cpp:
(WebCore::LayoutIntegration::canUseForIntrinsicWidthComputation):
* Source/WebCore/layout/integration/LayoutIntegrationUtils.cpp:
(WebCore::Layout::IntegrationUtils::minContentLogicalWidthContribution):
(WebCore::Layout::IntegrationUtils::maxContentLogicalWidthContribution):
(WebCore::Layout::IntegrationUtils::minContentLogicalWidthContribution const):
(WebCore::Layout::IntegrationUtils::maxContentLogicalWidthContribution const):
* Source/WebCore/layout/integration/inline/LayoutIntegrationLineLayout.cpp:
(WebCore::LayoutIntegration::LineLayout::computeIntrinsicWidthConstraints):
* Source/WebCore/layout/integration/LayoutIntegrationBoxGeometryUpdater.cpp:
(WebCore::LayoutIntegration::BoxGeometryUpdater::updateLayoutBoxDimensions):
Canonical link: https://commits.webkit.org/319212@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
