995020 - intrinsic width of vertical multi-line flexbox is incorrect, when wrapping is needed (with flex-flow: column wrap)

Status: NEW

(Core :: Layout: Flexbox, defect)

Description

[rigdern]

Attachment: nestedFlexboxRepro.html

User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:28.0) Gecko/20100101 Firefox/28.0 (Beta/Release)
Build ID: 20140314220517

Steps to reproduce:

Open the attached file (nestedFlexboxRepro.html)


Actual results:

The width of the inner flexbox (orange area) is 100 pixels


Expected results:

The width of the inner flexbox (orange area) is 200 pixels

Comment 1

[rigdern]

Attachment: expected.png

Comment 2

[rigdern]

Attachment: actual.png

Comment 3

[Daniel Holbert [:dholbert]]

This actually doesn't depend on there being nested flexboxes -- it's about how we compute the max-content intrinsic width of a column-oriented flexbox (which we do when it's a flex item, and also when it's floated, and also when it's an inline-flexbox).

Comment 4

[Daniel Holbert [:dholbert]]

Attachment: testcase 2 (without nesting, & using 'inline-flex')

Here's a reduced testcase, using "inline-flex" to get the intrinsic width instead of nesting.

Firefox renders this with the orange flex container being only wide enough to contain the first flex item (i.e. assuming no wrapping). Chrome renders it wide enough to contain both (i.e. assuming wrapping).

Comment 5

[Daniel Holbert [:dholbert]]

Attachment: testcase 3 (no wrapping necessary)

Here's a testcase (with a larger specified height) where our behavior produces a more sensible rendering than Chrome.  Firefox renders this with the orange area (the flex container) being only wide enough to hold the (single) column. Chrome renders it as 4 * the width of the column -- i.e. it assumes the 'worst-case' intrinsic width, if we had to wrap each item to its own (vertical) flex line.

Comment 6

[Daniel Holbert [:dholbert]]

So this is a discrepancy about how to calculate the max-content cross-size (of a column-oriented flex container).

The spec says the following about this value:
  # The min-content cross size and max-content cross size of
  # a flex container are the cross size of the flex container
  # after performing layout into the given available main-axis
  # space and infinite available cross-axis space.

In other words: we're supposed to render testcase 2 as fat, and testcase 3 as skinny. Neither Blink nor Gecko do this currently; not sure if IE11 does. (I'm on Linux right now & can't check.)

To get this right, I think we'd need to do a full run of the flexbox layout algorithm, before we even get to doing our *actual* reflow.  (We could potentially cache some of the trial-reflow information and reuse it when we get to doing our actual reflow, to avoid repeating work, so it doesn't necessarily have to be too expensive.)

Comment 7

[Daniel Holbert [:dholbert]]

I filed https://code.google.com/p/chromium/issues/detail?id=362797 on Chrome's rendering of "testcase 3", FWIW.

Comment 8

[Daniel Holbert [:dholbert]]

Note: the Chrome issue that I filed was actually a dupe of https://code.google.com/p/chromium/issues/detail?id=247963 , which I think has been fixed in Chrome dev channel.

With that fixed, they actually match our rendering on all 3 testcases on this bug now.

Comment 9

[Daniel Holbert [:dholbert]]

(That's not to say that this bug should be closed; the spec calls for something smarter than what Firefox, old-Chrome, & more-recent-Chrome do, per comment 6 here. Tony Chang (chromium hacker) seems to agree, per https://code.google.com/p/chromium/issues/detail?id=247963#c13 )

Comment 11

[Daniel Holbert [:dholbert]]

(In reply to Daniel Holbert [:dholbert] from comment #6)
> So this is a discrepancy about how to calculate the max-content cross-size
> (of a column-oriented flex container).

Note: this language has changed significantly. Bug 1055887 is about implementing the new language; it may end up fixing this bug here. Adding it to "see also" for now.

Comment 12

[Christian :Biesinger (don't email me, ping me on IRC)]

Note https://lists.w3.org/Archives/Public/www-style/2015Dec/0114.html

Comment 15

[Simon Pieters [:zcorpan]]

This seems to be the last remaining Flexbox bug in Firefox of the ones listed in https://github.com/philipwalton/flexbugs

Comment 17

[Stijn V]

What's the status here?

Comment 18

[Daniel Holbert [:dholbert]]

The status is that this is in our backlog and no one's currently working on it (we're a small team with lots of conflicting priorities).

There's a chance that this will be easier to fix once we've got the supporting pieces of bug 1310551 landed. This is a similar situation to that bug -- where we need to do a substantial amount of layout work on the children in order to compute the correct intrinsic inline-size (usually width) of the parent.

Comment 19

[Stijn V]

Okay is there a workaround other than using fixed width?