Bugzilla

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, sort-of.  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 correct on all 3 testcases that I've attached -- 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 than the stacking order -- but likely, a correct fix for bug 489100 will fix this bug as well.

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 correct on all 3 testcases that I've attached -- 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 than the stacking order -- but likely, a correct fix for bug 489100 will fix this bug as well.

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 than the stacking order -- but likely, a correct fix for bug 489100 will fix this bug as well.

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.