1436896 - Flex item with child-percent-padding-imposed aspect-ratio & vertical WM isn't sized the same as in other browsers

Status: NEW

(Core :: Layout, defect, P3)

Description

[Daniel Holbert [:dholbert]]

Attachment: testcase 1 (from r.otten on bug 1223180)

[Spinning this bug off from bug 1223180 comment 4.]

STR:
 1. Load attached testcase.
 2. Resize textarea (by clicking on its bottom-right grabber & dragging up and down)

EXPECTED RESULTS:
The image should grow & shrink its width (up to a point, and then just grow its height).

ACTUAL RESULTS:
Before bug 1223180, the image's width doesn't change.
After bug 1223180, the image doesn't show up at all.


I'm guessing it's because we fall into one of the vertical writing-mode intrinsic-sizing "throw up our hands" spec-undefined pitfalls like https://dxr.mozilla.org/mozilla-central/rev/0ac953fcddf10132eaecdb753d72b2ba5a43c32a/layout/base/nsLayoutUtils.cpp#5523 -- that, or there's some subtle size-determination-ordering dependency in the testcase. Or a combination of the two.  (The testcase has a percent "padding-left" value on a child of a flex item, which in this case is a percent of the flex item's height since the flex item has a vertical WM.  And the flex item's height is dependent on the flex *container's* height, which is indefinite and really is derived from the other flex item...)

I think this is well defined in the spec, though... Section 9.8 subsection 3 says "Once the cross size of a flex line has been determined, items in auto-sized flex containers are also considered definite for the purpose of layout"
https://drafts.csswg.org/css-flexbox-1/#definite 

However, the cross size of the flex line here isn't determined until *after* we've locked in the items' main sizes (their widths in this case).  And up until we've locked in their widths, we're still working with indefinite heights, so the percent "padding-left" doesn't have anything useful to resolve against...  By the time we've got a height for it to resolve against, it's too late for it to have an influence on the width of its flex item.

In other words, this testcase has a circular dependency (which Chrome resolves somehow, but not in a way that I'm seeing any support for in the spec).

So I'm not clear what's correct here; but I'm filing anyway since there's a webcompat issue here regardless, and it's worth tracking that. But at this point, I think our post-bug-1223180 rendering is correct per spec.

Comment 1

[Daniel Holbert [:dholbert]]

Attachment: testcase 2 (with borders/backgrounds to visualize components a bit better)

Here's a variant of the original testcase. The top half has a horizontal writing-mode on the flex item; the bottom half has a vertical writing-mode on the flex item.

Comment 2

[Daniel Holbert [:dholbert]]

Also, I ran into a Chrome bug while working the testcase here, which gives me less confidence in Chrome's correctness -- I filed https://bugs.chromium.org/p/chromium/issues/detail?id=810607 for that issue.  I think that bug indicates they might be using the results of previous layouts as inputs for percent padding resolution in subsequent layouts (even when the size is technically indefinite at the point in the layout algorithm where it's being resolved against), or something like that -- which would be one explanation for how they're (hackily) breaking the circular dependency described in comment 0.)

Comment 3

[Jet Villegas (inactive)]

[ Triage 2017/02/20: P3 ]

Comment 4

[Elvis Stansvik]

I recently filed https://bugzilla.mozilla.org/show_bug.cgi?id=1592652 . While it is not this bug, I think it's similar (?). It's about a margin problem with vertical writing mode children of grid items (so not flex items), where the behavior in Chrome is different (and more what I'd expect). Just posting this here in case it could hold some clues..