Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 25cfac7b1b15dc8bf5d77b061075d49cbcc63d64
https://github.com/WebKit/WebKit/commit/25cfac7b1b15dc8bf5d77b061075d49cbcc63d64
Author: Alan Baradlay <[email protected]>
Date: 2026-07-28 (Tue, 28 Jul 2026)
Changed paths:
M Source/WebCore/layout/integration/flex/FlexIntegrationUtils.cpp
M Source/WebCore/layout/integration/flex/FlexIntegrationUtils.h
M Source/WebCore/layout/integration/flex/LayoutIntegrationFlexLayout.cpp
M Source/WebCore/layout/integration/flex/LayoutIntegrationFlexLayout.h
M Source/WebCore/rendering/RenderFlexibleBox.h
Log Message:
-----------
[cleanup] Stop reaching the flex integration layer through the renderer
https://bugs.webkit.org/show_bug.cgi?id=320493
Reviewed by Antti Koivisto.
FlexIntegrationUtils called back into LayoutIntegration::FlexLayout by fishing
it out of the renderer --
flexBox().flexLayout() -- to ask the CSS Flexbox 9.8 percentage-resolution
questions. The formatting context owns
the FlexIntegrationUtils it asks through, and FlexLayout owns the formatting
context, so that reach ran backwards
through the renderer to get at the layer above.
Those questions only need one piece of state: the FlexLayoutState the running
algorithm holds. flexItemMainSizeIsDefinite
is otherwise a function of its size argument and FlexFormattingUtils statics,
and the state is used two ways at the
bottom of the chain -- as the container's cached block-size definiteness, and
as the signal for whether the algorithm
is running at all (what isInLayout() answered).
So move the chain to FlexIntegrationUtils as statics taking a const
FlexLayoutState*, where nullptr means the
algorithm is not running. The flex container comes from the item's parent, as
it does throughout FlexFormattingUtils.
FlexIntegrationUtils already holds a reference to the very FlexLayoutState that
FlexLayout owns -- the formatting
context hands it over at construction -- so its instance wrappers pass that,
and FlexLayout passes its optional's
address or nullptr. The state moves from being reached for to being handed in.
FlexLayout keeps hasDefiniteSizeForPercentResolution, which is the one caller
that made this awkward: RenderFlexibleBox
asks it from layout passes with no formatting context on the stack, when no
FlexIntegrationUtils exists. It is now a
forwarder, and the three helpers behind it leave FlexLayout's surface along
with isInLayout().
That leaves RenderFlexibleBox::flexLayout() with no callers, so remove it.
Nothing can take the integration layer off
the renderer now.
* Source/WebCore/layout/integration/flex/FlexIntegrationUtils.cpp:
(WebCore::LayoutIntegration::FlexIntegrationUtils::computeBlockAxisContentSizeForFlexItem):
(WebCore::LayoutIntegration::FlexIntegrationUtils::flexItemMainSizeIsDefinite):
(WebCore::LayoutIntegration::FlexIntegrationUtils::isFlexBoxBlockSizeDefiniteForFlexItem):
(WebCore::LayoutIntegration::FlexIntegrationUtils::canResolvePercentAgainstContainerBlockSize):
* Source/WebCore/layout/integration/flex/FlexIntegrationUtils.h:
* Source/WebCore/layout/integration/flex/LayoutIntegrationFlexLayout.cpp:
(WebCore::LayoutIntegration::FlexLayout::hasDefiniteSizeForPercentResolution):
(WebCore::LayoutIntegration::FlexLayout::flexItemMainSizeIsDefinite): Deleted.
(WebCore::LayoutIntegration::FlexLayout::isFlexBoxBlockSizeDefiniteForFlexItem):
Deleted.
(WebCore::LayoutIntegration::FlexLayout::canResolvePercentAgainstContainerBlockSize):
Deleted.
* Source/WebCore/layout/integration/flex/LayoutIntegrationFlexLayout.h:
* Source/WebCore/rendering/RenderFlexibleBox.h:
(WebCore::RenderFlexibleBox::flexLayout): Deleted.
Canonical link: https://commits.webkit.org/318123@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
