New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 42 users

Issue metadata

Status: Assigned
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 3
Type: Bug

Blocked on:
issue 591099

issue 588469

Sign in to add a comment

Issue 507397: Flex container width and height incorrectly calculated for `flex-flow: column wrap`

Reported by, Jul 6 2015 Project Member

Issue description

Chrome Version       : 45.0.2449.0 (Official Build) canary (64-bit)
URLs (if applicable) :
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
    Safari 8: FAIL
    Firefox 41: FAIL
    IE 7/8/9/10: FAIL
    Edge: OK

What steps will reproduce the problem?
1. Go to
2. Notice how the containing <ul> does not actually contain it's <li> children. It's size is being incorrectly calculated.

What is the expected result?

The <il> children should be contained no matter how they wrap and no matter how many children are present.
If you look at the demo in Edge, it renders correctly.

What happens instead?

The containing <ul> does not fully contain its children.

Please provide any additional information below. Attach a screenshot if
Screen Shot 2015-07-06 at 1.10.38 PM.png
515 KB View Download

Comment 1 by, Jul 7 2015

Labels: OS-All M-45
Status: Untriaged
Tested on Windows 7, Ubuntu 14.04 and Mac OS 10.10.4 using chrome - 45.0.2449.0 version by following steps mentioned below.

1. Navigated to
2. Observed that only one and two child is calculated

Tested the same on chrome older versions M35 - 35.0.1905.0 and observed the different behavior as seen in the screenshot.Nowhere I couldn't see the <ul> fully contains its children.

This is a non-regression issue,Hence marking it as untriaged.

Comment 2 by, Jul 7 2015

version 35.0.1905.0.JPG
87.5 KB View Download

Comment 3 by, Jul 7 2015

Labels: Cr-Blink-CSS

Comment 4 by, Jul 9 2015

Labels: -Cr-Blink-CSS Cr-Blink-Layout-Flexbox

Comment 5 by, Aug 27 2015

Status: Assigned

Comment 6 by, Oct 9 2015

So  bug 525051  fixed the vertical part of this sizing problem. Haven't looked into the horizontal part yet.

Comment 7 by, Oct 9 2015

Interestingly we match Firefox as far as calculating the width goes. However I think Edge is correct here, not us:
"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."

So this seems to imply that we do need to take the max-height into account for this computation (right?)

Comment 8 by, Oct 9 2015

Yup, I think Firefox is wrong here -- this sounds like

Comment 9 by, Oct 26 2015

 Issue 538927  has been merged into this issue.

Comment 10 by, Dec 2 2015

 Issue 562361  has been merged into this issue.

Comment 12 by, Dec 8 2015

Labels: allpublic

Comment 13 by, Dec 8 2015

Labels: -Pri-2 Pri-3

So we're matching the spec right now, afaict. And doing anything else is not really possible, because it makes preferred width calculations depend on layout :(

Lowering priority because we're doing what we can.

Comment 14 by, Dec 16 2015

Passes in Presto too (for those (like me) who cannot run Edge). :)

I guess we "simply" have to make LayoutFlexibleBox::computeIntrinsicLogicalWidths() flex line aware?

Comment 15 by, Dec 16 2015

So, we can't, at least not for column flexboxes, because that would require knowing the *height* of each flex item. And that requires layout.

Comment 16 by, Dec 17 2015

Right now we can't.

To avoid requiring layout, we could get the engine to calculate a hypothetical logical top and height that an object would get if maximum preferred width become the width we actually end up using. That will help us figure out which item goes on which line. I talked briefly about this hypothetical top/height here:

This is what is done in Presto, and it should improve the situation by quite a lot, if done in Blink too.

Am I right in assuming that the item widths (i.e. cross sizes in the test case) aren't affected by the flex container's width when flex-flow is "column wrap"? The spec seems to suggest this, and all browsers but Presto seem to follow it. Presto allows shrinking of the lines' cross size (i.e. width) if the flex container isn't wide enough.

Try this and make the window narrow:

<div style="display:flex; flex-flow:column wrap; height:70px;">
    <div style="height:30px;">Item 1. This text should never break.</div>
    <div style="height:30px;">Item 2. This text should never break.</div>
    <div style="height:30px;">Item 3. This text should never break.</div>
    <div style="height:30px;">Item 4. This text should never break.</div>

Tested IE, Blink, Gecko and Presto.
Only Presto will wrap the text if the flex container isn't wide enough. I hope this is a bug, or otherwise calculating preferred min/max widths will be a nightmare (probably impossible to calculate, when I think about it). BTW: If it's true that cross sizes don't depend on the flex container size in a multi-line (flex-wrap:wrap) situation, it means that minimum preferred width will always be the same as maximum preferred width in the "flex-flow:column wrap" case.

Comment 17 by, Dec 17 2015

Cc: - mails bounce.

Comment 18 by, Feb 3 2016

If this issue is not fixed, then "flex-flow: column wrap" is useless. And if something is useless just because it follows some spec, then the spec is wrong.

Comment 19 by, Feb 3 2016

Only useless for inline-flex or otherwise shrinkwrapped flexboxes.

Anyway, the spec now has wording that makes this work as you expect. However, it can't be implemented in Blink because it requires doing layout during preferred width calculation, afaict. Though I don't really understand parts of the text.

Comment 20 by, Feb 22 2016

Blocking: 588469

Comment 21 by, Mar 3 2016

In some instances, you may be able to workaround this issue by using vertical writing mode.

That is, instead of using "flex-direction: column;", use "flex-direction: row; writing-mode: vertical-lr;". Remember to reset to "writing-mode: initial;" in the children of the flexbox.

Came up with this in a discussion with domenic (thank you!)

Comment 22 by, May 13 2016

#21 - Unfortunately that doesn't work in FF so we'll need webdevs to set the explicit expected rows/columns widths/heights. Just an FYI.

Comment 23 by, May 16 2016

That's a silly workaround and I would prefer if webdevs didn't have to mess with writing-mode to make this work. If someone is messing with writing-mode like that, it may as well be Blink-internal code.

Comment 24 by, Jun 14 2016

Project Member
Labels: Hotlist-Google

Comment 25 by, Jul 15 2016

 Issue 407354  has been merged into this issue.

Comment 26 by, Jul 27 2016

 Issue 631155  has been merged into this issue.

Comment 27 by, Feb 10 2017

Labels: Hotlist-Interop
Some discussion:

Comment 28 by, Mar 1 2017

 Issue 696785  has been merged into this issue.

Comment 29 by, Mar 7 2017


Comment 30 by, Jul 7 2017

It's been about a year. Has there been work on this?

Comment 31 by, Jul 10 2017

 Issue 740551  has been merged into this issue.

Comment 32 by, Jul 11 2017

Blockedon: 591099
This won't be fixed until our layout engine rewrite (LayoutNG)

Comment 33 by, Aug 21 2017

Ugh, why is this still broken? There's no good workaround for this.

Comment 34 by, Sep 11

Can't find any good workaround for this, very upset with this bug

Sign in to add a comment