Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: a4e7ab43ab8476e937f6deaea31285267a915f96
https://github.com/WebKit/WebKit/commit/a4e7ab43ab8476e937f6deaea31285267a915f96
Author: Alan Baradlay <[email protected]>
Date: 2026-04-20 (Mon, 20 Apr 2026)
Changed paths:
A
LayoutTests/fast/flexbox/quirks-percentage-height-in-flex-item-expected.html
A LayoutTests/fast/flexbox/quirks-percentage-height-in-flex-item.html
M Source/WebCore/rendering/RenderBox.cpp
M Source/WebCore/rendering/RenderFlexibleBox.cpp
M Source/WebCore/rendering/RenderFlexibleBox.h
Log Message:
-----------
Percentage height inside flex item should resolve in quirks mode
https://bugs.webkit.org/show_bug.cgi?id=312598
Reviewed by Antti Koivisto.
In quirks mode, when an element has a percentage height inside a flex item,
the browser needs to figure out what that percentage resolves against.
The quirks spec (section 3.5) has a special algorithm for this. It walks up the
containing block chain, skipping auto-height block containers, looking for
an ancestor with a definite height. Step 4 says to stop the walk when the
ancestor is "not a block container" - flex containers are not block
containers, so the walk stops there.
The problem was twofold:
1. Resolution: once the walk stopped at the flex container, we called
availableLogicalHeightForPercentageComputation() on it. This returned
nullopt because the flex container has auto height. But after cross-axis sizing,
the flex container's used content height IS known.
We now fall back to contentBoxLogicalHeight() in this case,
scoped to isInCrossAxisStretchLayout() so we only use it when the value is
final.
2. Relayout timing: the resolution above only works during the stretch
relayout pass (when isInCrossAxisStretchLayout() is true). The stretch
relayout check in applyStretchAlignmentToFlexItem used
block->hasPercentHeightDescendants(), which asks the flex item directly
"do you have percent-height descendants registered on you?" In quirks mode,
the answer is no since the percent height descendant is registered on the flex
container (see #1)
Using flexItemHasPercentHeightDescendants() instead asks the flex container
"do you have percent-height descendants that are under this flex item?" - which
correctly returns true, so the stretch
relayout fires.
Note: the deeply nested case (multiple wrapper divs between the flex item
and the percentage-height descendant) still does not work because the
stretch relayout only marks the flex item dirty (MarkOnlyThis), and layout
does not propagate through the clean intermediate ancestors down to the
descendant. That is a separate issue.
Test: fast/flexbox/quirks-percentage-height-in-flex-item.html
* LayoutTests/fast/flexbox/quirks-percentage-height-in-flex-item-expected.html:
Added.
* LayoutTests/fast/flexbox/quirks-percentage-height-in-flex-item.html: Added.
* Source/WebCore/rendering/RenderBox.cpp:
(WebCore::RenderBox::computePercentageLogicalHeightGeneric const):
* Source/WebCore/rendering/RenderFlexibleBox.cpp:
(WebCore::RenderFlexibleBox::applyStretchAlignmentToFlexItem):
* Source/WebCore/rendering/RenderFlexibleBox.h:
Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>
(WebCore::RenderFlexibleBox::isInCrossAxisStretchLayout const):
Canonical link: https://commits.webkit.org/311581@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
