Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: bb3059f4cb9f710b7b2408210c0c64f754c26814
https://github.com/WebKit/WebKit/commit/bb3059f4cb9f710b7b2408210c0c64f754c26814
Author: Alan Baradlay <[email protected]>
Date: 2026-07-26 (Sun, 26 Jul 2026)
Changed paths:
M Source/WebCore/layout/formattingContexts/flex/FlexLayoutState.h
M Source/WebCore/layout/integration/flex/FlexIntegrationUtils.cpp
M Source/WebCore/rendering/RenderFlexibleBox.cpp
M Source/WebCore/rendering/RenderFlexibleBox.h
Log Message:
-----------
[cleanup] Remove the unread PostFlexScrollbarLayout flex layout phase
https://bugs.webkit.org/show_bug.cgi?id=320291
Reviewed by Antti Koivisto.
PostFlexScrollbarLayout is not one of the flex algorithm's phases -- it marks
the scrollbar
reconciliation relayout that runs after the algorithm is done -- so it does not
belong in the phase
enum. It got there when 288521@main's m_inPostFlexUpdateScrollbarLayout bool
was folded into the
monotonic phase enum. Put the bool back and drop the enumerator.
This matters because m_flexLayoutState is currently scoped to all of
layoutBlock rather than to the
flex layout proper, so it is still engaged during that relayout. Both the flag
and its FIXMEs go
away once the state is scoped to m_flexLayout.layout(), where an unengaged
state answers "not in
flex layout" on its own.
While here, say what the remaining check actually decides. The lambda answers
"is percentage
resolution disabled in this phase", not "can we use this item", so name and
invert it, and turn the
>= chain into a switch over the phases the flex algorithm runs layout in.
canComputePercentageFlexBasis is likewise not about flex basis by the time most
callers reach it --
it asks whether a percentage resolves against the container's block size -- so
rename it and give it
an overload for the callers that only need the yes/no and were passing a dummy
percentage.
The switch enumerates the phases that reach it. Beyond the three the >= chain
distinguished, layout can
reach here in three more, all of which the chain answered but naming them makes
explicit:
- PreparingFlexItems: recomputeLogicalWidth runs inside the state's scope, so
the container measuring its
own intrinsic widths gets here before the algorithm has sized anything.
- MainAxisAlignment: multi-line column flow re-runs main-axis item sizing from
the alignment step, once the
container's main size is known
(distributeMainAxisFreeSpaceForMultilineColumnIfNeeded), and the phase is
monotonic so it cannot go back to MainAxisItemSizing.
- CrossAxisAlignment: the final phase, where both axes are settled.
Also give FlexIntegrationUtils::flexItemIntrinsicLogicalWidth the
FlexItemIntrinsicWidthComputationScope its
two siblings maxContentMainAxisExtentForFlexItem and
minContentMainAxisContributionForFlexItem already have.
It measures the item the same way, so a percentage resolved against the item
while measuring should answer
from the item's cross-size definiteness rather than from how far the algorithm
has got.
No change in behaviour.
* Source/WebCore/layout/formattingContexts/flex/FlexLayoutState.h:
* Source/WebCore/layout/integration/flex/FlexIntegrationUtils.cpp:
(WebCore::LayoutIntegration::FlexIntegrationUtils::flexItemIntrinsicLogicalWidth):
* Source/WebCore/rendering/RenderFlexibleBox.cpp:
(WebCore::RenderFlexibleBox::layoutBlock):
(WebCore::RenderFlexibleBox::canUseFlexItemForPercentageResolution):
(WebCore::RenderFlexibleBox::canResolvePercentAgainstContainerBlockSize):
(WebCore::RenderFlexibleBox::flexItemMainSizeIsDefinite):
(WebCore::RenderFlexibleBox::canComputePercentageFlexBasis): Deleted.
* Source/WebCore/rendering/RenderFlexibleBox.h:
Canonical link: https://commits.webkit.org/317941@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
