Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: b1c69511447cfc4d4e82e49dd5633edac8d09a55
https://github.com/WebKit/WebKit/commit/b1c69511447cfc4d4e82e49dd5633edac8d09a55
Author: Alan Baradlay <[email protected]>
Date: 2026-07-27 (Mon, 27 Jul 2026)
Changed paths:
M Source/WebCore/layout/integration/flex/FlexIntegrationUtils.cpp
M Source/WebCore/layout/integration/flex/LayoutIntegrationFlexLayout.cpp
M Source/WebCore/layout/integration/flex/LayoutIntegrationFlexLayout.h
M Source/WebCore/rendering/RenderFlexibleBox.cpp
M Source/WebCore/rendering/RenderFlexibleBox.h
Log Message:
-----------
[cleanup] Move the flex percentage-resolution definiteness checks off
RenderFlexibleBox
https://bugs.webkit.org/show_bug.cgi?id=320333
Reviewed by Antti Koivisto.
canUseFlexItemForPercentageResolution answered two separate questions in one
function: whether the flex
algorithm has produced the item's height yet, and whether CSS Flexbox 9.8
considers the resulting size
definite. Only the first is about RenderFlexibleBox. The second is spec logic
over the item's style plus
the container's block-size definiteness, both of which the flex formatting
context already owns.
Split them. FlexLayout gains isFlexItemHeightDefiniteInLayoutPhase for the
phase question, returning
std::optional so that "the flex algorithm is not running" stays distinguishable
from a yes or a no --
outside of layout only the container knows which of its own passes is in play.
It also takes the 9.8 rules
(hasDefiniteSizeForPercentResolution), flexItemMainSizeIsDefinite and both
canResolvePercentAgainstContainerBlockSize overloads; the latter reads and
writes the block-size
definiteness the layout state carries, which FlexLayout owns since 320299. That
removes two function
templates and their four explicit instantiations from RenderFlexibleBox, and
lets FlexIntegrationUtils
forward to FlexLayout rather than bouncing through the renderer.
What is left on RenderFlexibleBox is the part that is genuinely about the
renderer's own layout passes:
m_inFlexItemIntrinsicWidthComputation, m_inSimplifiedLayout and the subtree
layout root check. Those are
not flex algorithm state, so they stay where the flags live.
The phase check reads the opposite way round now -- it answers "is the height
definite" rather than "is
percentage resolution disabled" -- so that both halves are positive and can be
combined with &&. The
short-circuit is deliberate: canResolvePercentAgainstContainerBlockSize
memoizes into the layout state, so
it must not run when the phase check has already said no.
No change in behaviour.
* Source/WebCore/layout/integration/flex/FlexIntegrationUtils.cpp:
(WebCore::LayoutIntegration::FlexIntegrationUtils::computeBlockAxisContentSizeForFlexItem):
(WebCore::LayoutIntegration::FlexIntegrationUtils::flexItemMainSizeIsDefinite):
* Source/WebCore/layout/integration/flex/LayoutIntegrationFlexLayout.cpp:
(WebCore::LayoutIntegration::FlexLayout::isFlexItemHeightDefiniteInLayoutPhase
const):
(WebCore::LayoutIntegration::FlexLayout::hasDefiniteSizeForPercentResolution):
(WebCore::LayoutIntegration::FlexLayout::flexItemMainSizeIsDefinite):
(WebCore::LayoutIntegration::FlexLayout::canResolvePercentAgainstContainerBlockSize):
* Source/WebCore/layout/integration/flex/LayoutIntegrationFlexLayout.h:
* Source/WebCore/rendering/RenderFlexibleBox.cpp:
(WebCore::RenderFlexibleBox::canUseFlexItemForPercentageResolution):
(WebCore::RenderFlexibleBox::canResolvePercentAgainstContainerBlockSize):
Deleted.
(WebCore::RenderFlexibleBox::flexItemMainSizeIsDefinite): Deleted.
* Source/WebCore/rendering/RenderFlexibleBox.h:
Canonical link: https://commits.webkit.org/317990@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
