1950732 - Firefox fails WPT css/css-writing-modes/block-flow-direction-srl-057.xht

Status: NEW

(Core :: Layout, defect)

Description

[Daniel Holbert [:dholbert]]

We fail this WPT:
wpt.fyi: https://wpt.fyi/results/css/css-writing-modes/block-flow-direction-srl-057.xht
wpt.live: https://wpt.live/css/css-writing-modes/block-flow-direction-srl-057.xht

Failure annotation:
https://searchfox.org/mozilla-central/source/testing/web-platform/meta/css/css-writing-modes/block-flow-direction-srl-057.xht.ini

(That annotation points at bug 1244601 but I don't think that bug is actually relevant to the-way-in-which we fail this test at this point today.)

Brief analysis -- the test has vertical arrangements of yellow Ahem-font square glyphs, with spaces between them, wrapped in a div with blue background (and a blue border). These end up combining to render the word "PASS". In Firefox, the "P" and "A" seem to be missing their bottom stripe of blue.

I think this is from Firefox not including the trailing space character as part of the intrinsic inline-size of elements like this one:

<!-- The right-most line of "P" --> <div class="right-border">eeee&nbsp;&nbsp; </div>

Note the trailing space after the last   there -- I suspect that space (and whether it contributes to sizing) is responsible for our rendering difference vs. Chrome here.

[EDIT: This^ isn't actually the reason we differ from Chrome; see reduced testcase in comment 2 for a better visualization of the underlying behavior-difference that results in us failing here.]

Comment 1

[Daniel Holbert [:dholbert]]

(In reply to Daniel Holbert [:dholbert] from comment #0)

I think this is from Firefox not including the trailing space character as part of the intrinsic inline-size of elements like this one:

<!-- The right-most line of "P" --> <div class="right-border">eeee&nbsp;&nbsp; </div>

Hmm, so this^ is sort-of it -- at least, if I replace that trailing space with  , then we change our rendering and pass the test.

However, if I remove that trailing space (and its adjacent   spaces) from the testcase, it doesn't make a difference to Chrome's rendering -- so it's not that Chrome is honoring those spaces, but rather that Chrome is sizing all of these divs to the same height for other reasons, I think (filling the available space in the table-cell wrapper, I think).

Comment 2

[Daniel Holbert [:dholbert]]

Attachment: reduced testcase 1

Here's a reduced testcase that captures the actual difference here.

Chrome renders this testcase with all of the cyan elements having the same inline-size (so each "aaa/b/c" grouping is consistently sized).

Firefox renders all of the vertical ones as having content-shrink-wrapping sizes (so "aaa" is larger than "b " which is larger than "c"), though we render the horizontal one with consistent inline-sizes.