1765664 - We might be incorrectly computing the static position of abspos frames in orthogonal flow

Status: RESOLVED INVALID

(Core :: Layout: Positioned, defect)

Description

[Daniel Holbert [:dholbert]]

STR:

1. Load attached testcase.
2. Compare the position of the top "Hello" vs. the other pink elements. Also, compare the position of all of the elements, when you tick/untick "position:absolute" in devtools.

ACTUAL RESULTS:

• The top pink box (with intrinsically sized "Hello") is positioned differently from all the others. (It's inside the blue box.) (Note: This part might be a version of bug 1166120.)
• The others are all positioned outside of the blue box.

EXPECTED RESULTS:

• All of the pink elements should be positioned at a consistent/understandable horizontal position.
• Maybe they should all be positioned inside the blue box? (at the position they end up if you remove position:absolute). At least, that's what the static position is supposed to represent, i think...

Comment 1

[Daniel Holbert [:dholbert]]

Attachment: testcase 1

Comment 2

[Daniel Holbert [:dholbert]]

Attachment: screenshot of testcase 1 in Firefox Nightly 101

Comment 3

[Daniel Holbert [:dholbert]]

Attachment: reference case 1

Here's a reference case -- I think we should expect testcase 1 to render like this.

(This is the same as testcase 1, except that in this reference, I'm using direction:rtl instead of writing-mode:vertical-rl on the containing block. We seem to handle this properly.)

Comment 4

[Daniel Holbert [:dholbert]]

Attachment: screenshot of reference case in Firefox Nightly 101

Comment 5

[Ian Kilpatrick [:iank]]

:dholbert - (sorry for poking in - randomly looking at bugs)

FF is currently correct here for everything but the first width:auto case.
(all the pink boxes should be out the RHS).

You want to compare it to if the abs-pos elements had "position: static", but also keep the containing-block (".horiz-parent") the same size.
E.g.
.horiz-parent { width: 0; }
.abspos { position: static; width: fit-content; }

Ian

Comment 6

[Daniel Holbert [:dholbert]]

Aha! Thanks, Ian - I forgot that the containing block here would be collapsing its size to 0 when the abspos thing is abspos.

I'll poke around with some more testcases today, and I'll either just reduce the scope to cover the first width:auto case, or more likely spin that off to a new bug for a fresh start.

Comment 7

[Daniel Holbert [:dholbert]]

I filed bug 1766530 for the first case in the attached testcase (the part with the width:auto abspos thing) where Firefox is getting things wrong. I included a clearer testcase over there.

Beyond that, this bug was me just misunderstanding things, for reasons discussed in comment 5 - comment 6. --> closing this out as INVALID.