1332555 - [writing-mode] Vertical writing-mode child results in wrong intrinsic size for the parent and thus the child doesn't fit later when reflowed

Status: NEW

(Core :: Layout: Block and Inline, defect, P3)

Description

[Mats Palmgren (inactive)]

Attachment: testcase

STEPS TO REPRODUCE
1. load the attached testcase

ACTUAL RESULTS
the button is on the second line, below the "A"

EXPECTED RESULTS
the button is on the same line and to the right of the "A"

Comment 1

[Mats Palmgren (inactive)]

Actually, this is way more generic than just buttons.
It affects all orthogonal frames.  The bug is this:
https://dxr.mozilla.org/mozilla-central/rev/3cedab21a7e65e6a1c4c2294ecfb5502575a46e3/layout/base/nsLayoutUtils.cpp#5079-5086
We simply return zero there and as a result the outer inline-block is too
small to fit the vertical child frame.

Jonathan, do we already have a bug on file for this?
Do we have some plan for how to fix this in general?

Comment 2

[Mats Palmgren (inactive)]

Attachment: testcase

This testcase works as expected in Chrome, fwiw.

Comment 3

[Jonathan Kew [:jfkthame]]

(In reply to Mats Palmgren (:mats) from comment #1)
> Jonathan, do we already have a bug on file for this?
> Do we have some plan for how to fix this in general?

I'm sure we've had other bugs that due are the same underlying problem, though I don't seem to have them at my fingertips right now.

We don't have a plan here (but obviously we need one...); basically, I guess we need to eagerly reflow the orthogonal child in order to determine its block-size.

Comment 4

[Koji Ishii]

https://bugzilla.mozilla.org/show_bug.cgi?id=1166120
?

Comment 5

[Gérard Talbot]

I went through each and all of the orthogonal-parent-shrink-to-fit-001 sub-tests you did, Koji, and we do not have a test that is or compares to Mats' attachment 8829067 [details] ...

Comment 6

[Gérard Talbot]

attachment 8829067 [details] is rendered as expected in Edge 13.

Comment 7

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(In reply to Jonathan Kew (:jfkthame) from comment #3)
> We don't have a plan here (but obviously we need one...); basically, I guess
> we need to eagerly reflow the orthogonal child in order to determine its
> block-size.

I'm really against doing reflow during intrinsic size computation, and I'd like us to push back on any spec that calls for doing so.

Comment 8

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(My work in progress on a proposed alternative is at https://dbaron.github.io/css-intrinsic-sizing-one-axis/ .)

Comment 9

[Koji Ishii]

FYI, dbaron, Blink doesn't do that either.

I first experimented Simon's approach in bug 116120, to change the width after layout using the overflow. This seemed to work in simple cases, as demonstrated by Simon in Gecko, but Blink reviewers did not like it very much.

The approach we took was to collect orthogonal subtree roots, and pre-layout them before we enter the normal layout phase. We may end up to lay them out again, but in most common cases, the width (logical height of orthogonal flows) we get during the pre-layout don't change.

This isn't perfect, but it's sticking for a year without too much problems.

Comment 10

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(In reply to Koji Ishii from comment #9)
> The approach we took was to collect orthogonal subtree roots, and pre-layout
> them before we enter the normal layout phase. We may end up to lay them out
> again, but in most common cases, the width (logical height of orthogonal
> flows) we get during the pre-layout don't change.

So is the result of that pre-layout used as the intrinsic size?  That sounds effectively like the same thing that I don't want to do...

Comment 11

[Koji Ishii]

(In reply to David Baron :dbaron: ⌚️UTC-8 from comment #10)
> So is the result of that pre-layout used as the intrinsic size?

Yes.

> That sounds
> effectively like the same thing that I don't want to do...

understood...but I hope you also understand that people wants to layout vertical table cells without overlaps, and without asking authors to define the parent size.

I guess we need to keep this as an item we would like to come up with ideas to make both sides happy, but I don't have other candidates atm...

Comment 12

[Daniel Holbert [:dholbert]]

We've got several versions/flavors of probably-the-same underlying issue filed (being unable to resolve "real" intrinsic sizes, in orthogonal flow scenarios, at least for the first reflow).

To keep them organized, I'm marking them all (including this one) as dependencies of bug 1166120 for now.  --> Pulling that bug from "see also" to be an actual dependency.

Comment 13

[Daniel Holbert [:dholbert]]

Attachment: testcase 2