1730125 - New wpt failures in /css/CSS2/abspos/abspos-in-block-in-inline-in-relpos-inline.html

Status: NEW

(Core :: Layout: Block and Inline, defect)

Description

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Syncing wpt PR 30476 found new untriaged test failures in CI

Tests Affected

New Tests That Don't Pass

/css/CSS2/abspos/abspos-in-block-in-inline-in-relpos-inline.html
position:absolute should be sized by the right ancestor: FAIL (Chrome: PASS, Safari: FAIL)

CI Results

Gecko CI (Treeherder)
GitHub PR Head

Notes

These updates will be on mozilla-central once bug 1729951 lands.

Note: this bug is for tracking fixing the issues and is not
owned by the wpt sync bot.

This bug is linked to the relevant tests by an annotation in
https://github.com/web-platform-tests/wpt-metadata. These annotations
can be edited using the wpt interop dashboard
https://jgraham.github.io/wptdash/

If this bug is split into multiple bugs, please also update the
annotations, otherwise we are unable to track which wpt issues are
already triaged. Resolving as duplicate or closing this issue should
be cause the bot to automatically update or remove the annotation.

Comment 1

[Daniel Holbert [:dholbert]]

Our test-failure here is a "near miss" - assert_equals: expected 100 but got 105

The 5px difference there is from the width of a space character, I think. The setup is a relatively-positioned display:inline element, which has a 100px-wide in-flow child, and a 100%-width abspos descendant. The test is expecting the abspos descendant to be 100px wide, but we end up making the abspos containing block (and hence the 100% width) a little bit wider as a result of whitespace inside the inline-level element (after the 100px-wide thing)

Comment 2

[Daniel Holbert [:dholbert]]

Attachment: testcase 1 (which, if the WPT is correct, should render as a square)

Here's a targeted static testcase to highlight the behavior difference here. Chrome renders this as a 100px square; Firefox renders it a bit wider.

Comment 3

[Daniel Holbert [:dholbert]]

Attachment: reference case (just deleted all whitespace after the inline-block)

Here's a "reference case" which Firefox does indeed render as a square.

It's identical to the testcase except I deleted the whitespace between the end of the inline-block and the </span> close tag.

Comment 4

[Daniel Holbert [:dholbert]]

This looks like a real bug. It looks like we set mRect for the nsInlineFrame twice here, but we neglect to inform its abspos descendants.

• When it completes its reflow, it has aDesiredSize.Width() set to its width including the space character (which is 7445 app units i.e. ~124px in my attached testcase)
• It calls nsIFrame::ReflowAbsoluteFrames which uses that as the containing block width, for the purposes of laying out the abspos descendants.
• Then it completes its reflow and gets that size committed into its mRect.
• Then, in the parent block's nsBlockFrame::PlaceLine() function, we reach nsLineLayout::VerticalAlignLine which calls pfd->mFrame->SetRect() on the inline frame to update its mRect to be 6000 app units wide (i.e. 100px) in my testcase.
• ...but we neglect to inform the abspos descendants of this change-of-size.

Comment 5

[Daniel Holbert [:dholbert]]

Notes for anyone debugging this in the future: set a watchpoint on the nsInlineFrame's mRect.width member var. That should get hit twice (for the two assignments noted in comment 4); but the second one doesn't result in any change/relayout for the abspos descendant.