Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: b365c5770accef7f48e3864a032b5670edf19263
https://github.com/WebKit/WebKit/commit/b365c5770accef7f48e3864a032b5670edf19263
Author: Alan Baradlay <[email protected]>
Date: 2026-04-23 (Thu, 23 Apr 2026)
Changed paths:
M LayoutTests/TestExpectations
M
LayoutTests/imported/w3c/web-platform-tests/css/css-sizing/stretch/stretch-block-size-003-expected.txt
A
LayoutTests/imported/w3c/web-platform-tests/css/css-writing-modes/orthogonal-static-position-margin-expected.html
A
LayoutTests/imported/w3c/web-platform-tests/css/css-writing-modes/orthogonal-static-position-margin-ref.html
A
LayoutTests/imported/w3c/web-platform-tests/css/css-writing-modes/orthogonal-static-position-margin.html
M Source/WebCore/rendering/PositionedLayoutConstraints.cpp
M Source/WebCore/rendering/PositionedLayoutConstraints.h
Log Message:
-----------
Fix
imported/w3c/web-platform-tests/css/css-writing-modes/margin-collapse-vrl-022.xht
https://bugs.webkit.org/show_bug.cgi?id=313094
Reviewed by Antti Koivisto.
When an absolutely positioned element has auto inset (top/left/right/bottom),
we compute a "static position" - where the element would have been if it
weren't absolutely positioned. This works fine in most cases, but breaks when
the
parent has an orthogonal writing mode with a flipped axis (vs. the real
containing block).
For example, in vertical-rl the block axis runs right-to-left (flipped compared
to
horizontal-tb's top-to-bottom). When an absolutely positioned child inside
vertical-rl
uses static position, three things go wrong:
1. The static position is placed at the min edge (left), but it should be at
the max
edge (right) because vertical-rl's block axis starts from the right.
2. Margins are applied in the wrong direction - margin-right should push the
element
away from the right edge, but it's treated as a before-margin on the wrong
side.
3. After computing the position, there's an adjustment that subtracts the
element's
height (to convert from bottom-edge to top-edge positioning). This
adjustment is
wrong when we've already corrected the static position to come from the
right edge.
The fix adds isOrthogonalWithParentFlippedAxis() which detects when the
parent's axis
runs in the reverse direction. When it does: place the static position at the
max edge,
swap the before/after margins, and skip the height adjustment.
The same logic handles direction:rtl (inline-flipped) with orthogonal children.
Tests:
imported/w3c/web-platform-tests/css/css-writing-modes/orthogonal-static-position-margin-ref.html
imported/w3c/web-platform-tests/css/css-writing-modes/orthogonal-static-position-margin.html
* LayoutTests/TestExpectations:
*
LayoutTests/imported/w3c/web-platform-tests/css/css-sizing/stretch/stretch-block-size-003-expected.txt:
*
LayoutTests/imported/w3c/web-platform-tests/css/css-writing-modes/orthogonal-static-position-margin-expected.html:
Added.
*
LayoutTests/imported/w3c/web-platform-tests/css/css-writing-modes/orthogonal-static-position-margin-ref.html:
Added.
*
LayoutTests/imported/w3c/web-platform-tests/css/css-writing-modes/orthogonal-static-position-margin.html:
Added.
* Source/WebCore/rendering/PositionedLayoutConstraints.cpp:
(WebCore::PositionedLayoutConstraints::isOrthogonalWithParentFlippedAxis const):
(WebCore::PositionedLayoutConstraints::captureInsets):
(WebCore::PositionedLayoutConstraints::computeStaticPosition):
(WebCore::PositionedLayoutConstraints::adjustLogicalTopWithLogicalHeightIfNeeded
const):
* Source/WebCore/rendering/PositionedLayoutConstraints.h:
Canonical link: https://commits.webkit.org/311868@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
