Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 7c73eb8db19c7d1deb6a449f4bdf8aa0faafeee5
https://github.com/WebKit/WebKit/commit/7c73eb8db19c7d1deb6a449f4bdf8aa0faafeee5
Author: Alan Baradlay <[email protected]>
Date: 2026-07-28 (Tue, 28 Jul 2026)
Changed paths:
A
LayoutTests/imported/w3c/web-platform-tests/css/css-box/margin-trim/flex-inline-start-with-order-expected.html
A
LayoutTests/imported/w3c/web-platform-tests/css/css-box/margin-trim/flex-inline-start-with-order-ref.html
A
LayoutTests/imported/w3c/web-platform-tests/css/css-box/margin-trim/flex-inline-start-with-order.html
M Source/WebCore/layout/integration/flex/LayoutIntegrationFlexLayout.cpp
Log Message:
-----------
[Flex] margin-trim on a content-sized flex container ignores 'order'
https://bugs.webkit.org/show_bug.cgi?id=320397
Reviewed by Antti Koivisto.
Before the flex algorithm runs, RenderFlexibleBox trims the inline margins of
the items at the start and
end of the line, so that those margins stay out of the container's intrinsic
widths -- which
recomputeLogicalWidth needs before FlexLayout::layout has built anything. It
picked those two items with
firstInFlowChildBox and lastInFlowChildBox, i.e. in render tree order, but
which item starts a flex line
is decided by the used 'order' value.
So a container that sizes to its content reports a width computed from the
wrong item's margin. The items
themselves are placed correctly -- the algorithm sorts by 'order' and trims
from that -- so the symptom is
a container that is too wide or too narrow for the content it just laid out.
This has been the behaviour
since margin-trim for flexbox landed in 249208.
Pick the items the way buildFlexItemList will: the lowest and highest used
'order' value, with document
order breaking ties, which is what its stable sort produces. Scanning for the
two ends avoids having to
build the sorted list before the container has been sized.
That also fixes a smaller discrepancy with the same cause. firstInFlowChildBox
skips floating and
out-of-flow children, but not ones excluded from normal layout, so a fieldset's
legend could be picked as
the item to trim even though it is not a flex item and the algorithm never sees
it. The scan applies the
same filter buildFlexItemList does.
Tests:
imported/w3c/web-platform-tests/css/css-box/margin-trim/flex-inline-start-with-order-ref.html
imported/w3c/web-platform-tests/css/css-box/margin-trim/flex-inline-start-with-order.html
*
LayoutTests/imported/w3c/web-platform-tests/css/css-box/margin-trim/flex-inline-start-with-order-expected.html:
Added.
*
LayoutTests/imported/w3c/web-platform-tests/css/css-box/margin-trim/flex-inline-start-with-order-ref.html:
Added.
*
LayoutTests/imported/w3c/web-platform-tests/css/css-box/margin-trim/flex-inline-start-with-order.html:
Added.
* Source/WebCore/layout/integration/flex/LayoutIntegrationFlexLayout.cpp:
(WebCore::LayoutIntegration::FlexLayout::marginTrimItemsBeforeFlexLayout const):
Canonical link: https://commits.webkit.org/318100@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
