Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 3cd5e888a22018b0e47f98fcffc476e5eb1e77e8
https://github.com/WebKit/WebKit/commit/3cd5e888a22018b0e47f98fcffc476e5eb1e77e8
Author: Alan Baradlay <[email protected]>
Date: 2026-07-15 (Wed, 15 Jul 2026)
Changed paths:
M Source/WebCore/rendering/RenderFlexibleBox.cpp
M Source/WebCore/rendering/RenderFlexibleBox.h
Log Message:
-----------
[cleanup] Route the remaining flex item core-sizing leaves through
FlexLayoutItem
https://bugs.webkit.org/show_bug.cgi?id=318601
Reviewed by Antti Koivisto.
The flex-base and content-based-min sizing helpers already take a
FlexLayoutItem, but
the leaves they call still took the RenderBox directly. Route those last leaves
through
the struct too, so the entire core-sizing subgraph reached from
performFlexLayout accesses
flex-item renderers only through FlexLayoutItem.
computeMainAxisExtentForFlexItem, flexItemIntrinsicLogicalHeight,
flexItemIntrinsicLogicalWidth,
flexItemCrossSizeIsDefinite, and
flexItemHasComputableAspectRatioAndCrossSizeIsConsideredDefinite
now take a const FlexLayoutItem& and pull the renderer out only where they hand
it to
FlexLayoutUtils, a renderer method, or the percentage-resolution query.
canComputePercentageFlexBasis
and flexItemMainSizeIsDefinite keep taking a RenderBox: they are the public
percentage-resolution
query, reached during a flex item's own layout where no FlexLayoutItem exists.
No new field; no change in behavior.
* Source/WebCore/rendering/RenderFlexibleBox.cpp:
* Source/WebCore/rendering/RenderFlexibleBox.h:
Canonical link: https://commits.webkit.org/317229@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
