Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: dad0a7c279cdea927f7a07aef9acb6cfcf846ae7
https://github.com/WebKit/WebKit/commit/dad0a7c279cdea927f7a07aef9acb6cfcf846ae7
Author: Alan Baradlay <[email protected]>
Date: 2026-07-24 (Fri, 24 Jul 2026)
Changed paths:
M Source/WebCore/layout/formattingContexts/flex/FlexFormattingContext.cpp
M Source/WebCore/layout/integration/flex/FlexIntegrationUtils.cpp
M Source/WebCore/layout/integration/flex/FlexIntegrationUtils.h
Log Message:
-----------
[cleanup] Route FlexFormattingContext's last RenderFlexibleBox method calls
through FlexIntegrationUtils
https://bugs.webkit.org/show_bug.cgi?id=320196
Reviewed by Antti Koivisto.
Following 320193, FlexFormattingContext still reached into RenderFlexibleBox
directly
for three per-item cache/definiteness queries: flexItemContentLogicalHeight,
computeBlockAxisContentSizeForFlexItem, and the flexItemMainSizeIsDefinite
template.
Route these through FlexIntegrationUtils as well.
Unlike the mutations moved in 320193, these are proxies rather than
relocations: the
backing caches (m_contentLogicalHeights / m_blockAxisSize) are flex-container
state
read, written, and invalidated by ~8 non-FFC call sites (RenderBox's mid-layout
setFlexItemContentLogicalHeightIfNeeded, the scrollbar-relayout invalidation,
flexItemWillBeRemoved, etc.), and computeBlockAxisContentSizeForFlexItem chains
into the
other two internally. So the implementations and caches stay on
RenderFlexibleBox, and
FlexIntegrationUtils simply forwards to them in FlexLayoutItem terms. This
keeps the
external callers untouched and avoids RenderFlexibleBox calling back into the
integration
layer.
flexItemMainSizeIsDefinite is a template, so its proxy is a template too, with
the same
four explicit instantiations (FlexBasis / MinimumSize / MaximumSize /
PreferredSize) that
computeMainAxisExtentForFlexItem resolves through it. RenderFlexibleBox's own
template and
instantiations are unchanged; they now serve the proxy across translation units
instead of
FlexFormattingContext.
With this, FlexFormattingContext no longer calls any method on the
flex-container renderer:
m_flexBox survives only as an argument (inspector instrumentation, and the
containing block
handed to a flex item's own width resolution), never as a mid-layout state
round-trip. Its
remaining direct render-tree use is per-item flex-item reads.
* Source/WebCore/layout/formattingContexts/flex/FlexFormattingContext.cpp:
(WebCore::FlexFormattingContext::flexBaseSizeForFlexItem):
(WebCore::FlexFormattingContext::ensureBlockAxisContentSizeForFlexItemIfNeeded):
(WebCore::FlexFormattingContext::computeContentBasedMinMainSize):
(WebCore::FlexFormattingContext::computeMainAxisExtentForFlexItem):
(WebCore::FlexFormattingContext::flexItemIntrinsicLogicalHeight):
(WebCore::FlexFormattingContext::applyStretchAlignmentToFlexItem):
* Source/WebCore/layout/integration/flex/FlexIntegrationUtils.h:
* Source/WebCore/layout/integration/flex/FlexIntegrationUtils.cpp:
(WebCore::LayoutIntegration::FlexIntegrationUtils::flexItemContentLogicalHeight):
(WebCore::LayoutIntegration::FlexIntegrationUtils::computeBlockAxisContentSizeForFlexItem):
(WebCore::LayoutIntegration::FlexIntegrationUtils::flexItemMainSizeIsDefinite):
Canonical link: https://commits.webkit.org/317905@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
