Open Bug 995020 Opened 10 years ago Updated 1 month ago

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

Categories

(Core :: Layout: Flexbox, defect)

defect

Tracking

()

People

(Reporter: rigdern, Unassigned)

References

Details

(Keywords: parity-chrome, testcase)

Attachments

(5 files)

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
Attached image expected.png
Attached image actual.png
Status: UNCONFIRMED → NEW
Component: Untriaged → CSS Parsing and Computation
Ever confirmed: true
Keywords: testcase
OS: Windows 8.1 → All
Product: Firefox → Core
Hardware: x86_64 → All
Version: 28 Branch → Trunk
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).
Component: CSS Parsing and Computation → Layout
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).
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.
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.)
Depends on: 939901
Summary: Incorrect sizing for nested flexboxes → intrinsic width of vertical multi-line flexbox is incorrect, when wrapping is needed
I filed https://code.google.com/p/chromium/issues/detail?id=362797 on Chrome's rendering of "testcase 3", FWIW.
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.
(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 )
Summary: intrinsic width of vertical multi-line flexbox is incorrect, when wrapping is needed → intrinsic width of vertical multi-line flexbox is incorrect, when wrapping is needed (with flex-flow: column wrap)
(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.
See Also: → 1055887
Severity: normal → S3
See Also: → 1735142
Duplicate of this bug: 1868056

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

Component: Layout → Layout: Flexbox
Duplicate of this bug: 1892561
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: