1558332 - Incorrect layout where it depends on reflowed block-size of an orthogonal flow [was: text-orientation makes document not render properly]

Status: NEW

(Core :: Layout, defect, P3)

Description

[masondeanm]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/74.0.3729.169 Safari/537.36

Steps to reproduce:

https://codepen.io/ursi/pen/qzWzXO

Actual results:

Basically, when using text-orientation, the outer div does not get sized properly. Toggling certain css properties (noted in the codepen) will cause it to work properly from that point forward.

Expected results:

The outer div should be sized to fit the inner div. (This is what happens on chrome).

Comment 1

[Emilio Cobos Álvarez [:emilio]]

Hmm, on which version were you testing this? On Nightly I get the expected results in https://codepen.io/ursi/full/qzWzXO.

Comment 2

[Alice0775 White]

Attachment: reproduce html

On Firefox: layout is incorrect when initial load.
layout becomes correct after toggle css text-orientation property.

Comment 3

[masondeanm]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #1)

Hmm, on which version were you testing this? On Nightly I get the expected results in https://codepen.io/ursi/full/qzWzXO.

I was on 67.0.1 when I posted this. I just updated to 67.0.2 and the bug is still there.

Comment 4

[Emilio Cobos Álvarez [:emilio]]

Yeah, Alice's test-case makes it clear. Thanks both!

Comment 5

[Jonathan Kew [:jfkthame]]

The text-orientation property isn't really relevant here; the issue is that we don't know the width of the vertical writing-mode block before we've reflowed it, and so we compute the left: 100% offset based on a width of zero. Toggling the text-orientation property causes a reflow, and then we recompute left: 100% based on the width of the previously-reflowed block.

(That still isn't necessarily right, actually, it just happens that in this case the result turns out OK. But if text-orientation were affecting the width of the block, we'd still be getting a stale value based on the previous reflow.)

You can also "fix" the rendering of the testcase just by zooming in and out, as this triggers a reflow for the new scale (but the size in CSS px terms doesn't change, so we get the correct offset).

I think we have other bugs on file that have a similar root cause: we need to eagerly reflow the orthogonal child in order to know its block-size, which is what's needed to correctly compute the percentage-based offset here. Currently this happens in the wrong order: we compute that offset before reflowing the child, so we use a stale value (initially zero).