1915992 - abspos stacking order differs from Chrome, inside of `display:inline; position: relative` abspos containing block

Status: NEW

(Core :: Layout: Positioned, defect)

Description

[Daniel Holbert [:dholbert]]

Spinning this off as the platform bug for the behavioral difference that we're observing in bug 1895051, where browsers disagree about stacking order of abspos content with respect to other in-flow parts of the same subtree, within a position:inline element that's serving as an abspos containing block.

(I'm not sure yet which browser is correct, or if this is well-specified.)

In the particular testcases in bug 1895051, Gecko and WebKit agree (and differ from Chrome); but there are other cases I've found where all three browsers disagree, too. I'll post some testcases here.

This general issue is somewhat related to bug 489100; the main difference is that bug 489100; is focused on the size of the containing block, whereas here we're more concerned with the stacking order.

Comment 1

[Daniel Holbert [:dholbert]]

I'm attaching a series of testcases, where each testcase is of the form:

<div class="wrapper">
  <span class="inline-cb">
    <THING></THING>
    <div class="abspos-child"></div>
  </span>
</div>
<div class="wrapper">
  <span class="inline-cb">
    <THING></THING>
    <br>
    <div class="abspos-child"></div>
  </span>
</div>
<div class="wrapper">
  <span class="inline-cb">
    <div class="abspos-child"></div>
    <THING></THING>
  </span>
</div>
<div class="wrapper">
  <span class="inline-cb">
    <div class="abspos-child"></div>
    <br>
    <THING></THING>
  </span>
</div>

...where THING is the first child in the first half of the test (before the abspos element), vs. the last child in the second half of the test (after the abspos element); and there's a <br> separating the THING and the abspos element in the second and fourth subtests.

THING here will be: a block box, an inline-level <canvas>, and a span with some text.

Comment 2

[Daniel Holbert [:dholbert]]

Attachment: testcase 1: comparing stacking order of block box vs. abspos element, in a display:inline abspos-containing-block

Comment 3

[Daniel Holbert [:dholbert]]

Attachment: testcase 2: comparing stacking order of (inline) canvas vs. abspos element, in a display:inline abspos-containing-block

Comment 4

[Daniel Holbert [:dholbert]]

Attachment: testcase 3: comparing stacking order of (inline) span vs. abspos element, in a display:inline abspos-containing-block

Comment 5

[Daniel Holbert [:dholbert]]

There are some x/y positioning differences in these tests, but I'll set those aside for the moment since they're less-relevant to bug 1895051. For now I'm just focusing on whether the aqua-colored abspos element is in the foreground or not.

Testing Firefox Nightly 131 vs. WebKit-based Gnome Web 46.0 (epiphany) vs. Chrome dev 130: the abspos aqua box is in the foreground for these subtests in my just-posted testcases:

TESTCASE                 FIREFOX   WEBKIT   CHROME
testcase 1 (vs block):   Top 2     Top 2    All 4
testcase 2 (vs canvas):  Top 3     All 4    All 4
testcase 3 (vs span):    Top 3     All 4    All 4

Comment 6

[Daniel Holbert [:dholbert]]

Attachment: screenshot of testcase 1 (Firefox, WebKit, Chrome)

Comment 7

[Daniel Holbert [:dholbert]]

Attachment: screenshot of testcase 2 (Firefox, WebKit, Chrome)

Comment 8

[Daniel Holbert [:dholbert]]

Attachment: screenshot of testcase 3 (Firefox, WebKit, Chrome)

Comment 9

[Daniel Holbert [:dholbert]]

Testcase 1 is the most-relevant to bug 1895051; the other testcases are here for thoroughness.

I think https://drafts.csswg.org/css-position-3/#absolute-cb (linked by dbaron in bug 489100 comment 25) is the most relevant spec text here, specifically this part that talks about the ancestor-that-establishes-the-abspos-containing-block:

If the ancestor is an inline box, using the writing mode of that box,
the containing block is formed by forming a rectangle from the start-most content edges (in both axes) of the first box fragment of the ancestor, and the end-most content edges of the end-most box fragment(s) of the ancestor in each axis. If there are multiple fragments on the same line (e.g. due to bidi reordering), take the start-most fragment as the first fragment.

So the abspos containing block is supposed to be formed by the bounding-box of all the inline-box's fragments, essentially (all of its line-boxes). This implies that the stacking order of an an abspos element (vs. its in-flow neighbors) shouldn't be influenced by which of the inline-box's fragments we happen to be a part of.

I think this means chrome's stacking-order is the most-correct in comment 5 -- the aqua abspos element should be in the foreground in all 4 subtests, in each of the attached testcases.

This bug is probably a dupe of bug 489100 but I'll make it a dependency for now, since (per comment 0) bug 489100 is mostly focused on the x/y coordinate spaces rather than the stacking order. But most likely, a correct/complete fix for bug 489100 should fix this bug as well.