Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: dfa75cece781498a85cb1c0a1ed00ef1aae428ae
https://github.com/WebKit/WebKit/commit/dfa75cece781498a85cb1c0a1ed00ef1aae428ae
Author: Alan Baradlay <[email protected]>
Date: 2026-05-08 (Fri, 08 May 2026)
Changed paths:
A
LayoutTests/imported/w3c/web-platform-tests/css/css-sizing/stretch/flex-item-height-001-expected.txt
A
LayoutTests/imported/w3c/web-platform-tests/css/css-sizing/stretch/flex-item-height-001.html
A
LayoutTests/imported/w3c/web-platform-tests/css/css-sizing/stretch/flex-item-height-002-expected.txt
A
LayoutTests/imported/w3c/web-platform-tests/css/css-sizing/stretch/flex-item-height-002.html
A
LayoutTests/imported/w3c/web-platform-tests/css/css-sizing/stretch/flex-item-height-003-expected.txt
A
LayoutTests/imported/w3c/web-platform-tests/css/css-sizing/stretch/flex-item-height-003.html
A
LayoutTests/imported/w3c/web-platform-tests/css/css-sizing/stretch/indefinite-5-expected.txt
A
LayoutTests/imported/w3c/web-platform-tests/css/css-sizing/stretch/indefinite-5.html
A
LayoutTests/imported/w3c/web-platform-tests/css/css-sizing/stretch/indefinite-6-expected.txt
A
LayoutTests/imported/w3c/web-platform-tests/css/css-sizing/stretch/indefinite-6.html
M Source/WebCore/rendering/RenderBox.cpp
M Source/WebCore/rendering/RenderFlexibleBox.h
Log Message:
-----------
REGRESSION (309405@main): wral.com has lots of blank areas
https://bugs.webkit.org/show_bug.cgi?id=314401
<rdar://176288044>
Reviewed by Antti Koivisto.
The problem:
height:stretch on a child of a flex item resolves to the viewport height
(e.g. 789px) instead of behaving as auto (0px) when the flex container
has no explicit height.
Why it happens:
The stretch implementation (309405@main) added a definiteness gate that
decides whether stretch should resolve or fall back to auto. The gate
had "!containingBlock->isFlexItem()" which unconditionally skipped the
check for any flex item containing block. This assumed all flex items
have a definite cross size, but that is only true when the flex
container itself has a definite cross size.
The assumption came from the old -webkit-fill-available semantics where
"fill" means "take whatever space exists" - there was no concept of
falling back to auto. 'stretch' is more restrictive per spec: when the
containing block height is indefinite, it must behave as auto. The bug
is applying fill-available logic (always resolves) where 'stretch' logic
(may not resolve) is required.
309405@main relied on availableLogicalHeight() to "figure out the right
value" for flex items. But availableLogicalHeight() always returns a
value - it never returns "indefinite." It recurses up through
containingBlockLogicalHeightForContent() until it reaches
RenderView::availableLogicalHeight() which unconditionally returns the
viewport size. It makes 'stretch' silently resolves against
the viewport (-webkit-fill-available behavior).
Why hasDefiniteLogicalHeight() didn't handle the case for flex items:
hasDefiniteLogicalHeight() is conditional depending on the flex box layout
state (see canUseByLayoutPhase())
During the "after main axis item sizing" phase (when flex items are laid out
with their final main sizes but
before cross-axis stretching), this returns false for row flex items.
This is correct for percentage resolution which needs the final value,
but wrong for the stretch definiteness question which only needs to know
"will there be a definite height?"
The fix:
hasDefiniteCrossSizeForFlexItem() answers "will the flex container give
this item a definite cross size?" based purely on style: the container
is single-line, the item has align-self:stretch, and the container's
cross size is definite (fixed or resolvable percentage). It does not
depend on the layout phase.
containingBlockHasDefiniteBlockSize() now uses
hasDefiniteCrossSizeForFlexItem() as a fallback when
hasDefiniteLogicalHeight() returns false for a flex item. The member
function was already called from isResolveableStretchSize() /
isUnresolveableStretchSize() (used by aspect-ratio, percentage
resolution, and replaced element sizing), so the change fixes all
callers - not just the Stretch handler (see test cases).
*
LayoutTests/imported/w3c/web-platform-tests/css/css-sizing/stretch/flex-item-height-001-expected.txt:
Added.
*
LayoutTests/imported/w3c/web-platform-tests/css/css-sizing/stretch/flex-item-height-001.html:
Added.
*
LayoutTests/imported/w3c/web-platform-tests/css/css-sizing/stretch/flex-item-height-002-expected.txt:
Added.
*
LayoutTests/imported/w3c/web-platform-tests/css/css-sizing/stretch/flex-item-height-002.html:
Added.
*
LayoutTests/imported/w3c/web-platform-tests/css/css-sizing/stretch/flex-item-height-003-expected.txt:
Added.
*
LayoutTests/imported/w3c/web-platform-tests/css/css-sizing/stretch/flex-item-height-003.html:
Added.
*
LayoutTests/imported/w3c/web-platform-tests/css/css-sizing/stretch/indefinite-5-expected.txt:
Added.
*
LayoutTests/imported/w3c/web-platform-tests/css/css-sizing/stretch/indefinite-5.html:
Added.
*
LayoutTests/imported/w3c/web-platform-tests/css/css-sizing/stretch/indefinite-6-expected.txt:
Added.
*
LayoutTests/imported/w3c/web-platform-tests/css/css-sizing/stretch/indefinite-6.html:
Added.
* Source/WebCore/rendering/RenderBox.cpp:
(WebCore::RenderBox::computeSizingKeywordLogicalContentHeightUsingGeneric
const):
(WebCore::RenderBox::containingBlockHasDefiniteBlockSize const):
* Source/WebCore/rendering/RenderFlexibleBox.h:
Canonical link: https://commits.webkit.org/312916@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
