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

Issue 507397 link

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

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

Project Member Reported by, Jul 6 2015

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
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.

version 35.0.1905.0.JPG
87.5 KB View Download
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
So  bug 525051  fixed the vertical part of this sizing problem. Haven't looked into the horizontal part yet.
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
 Issue 538927  has been merged into this issue.
 Issue 562361  has been merged into this issue.
Labels: allpublic
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?
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.
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.
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.
Blocking: 588469
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!)
#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.
Project Member

Comment 24 by, Jun 14 2016

Labels: Hotlist-Google
 Issue 407354  has been merged into this issue.
 Issue 631155  has been merged into this issue.
Labels: Hotlist-Interop
Some discussion:
 Issue 696785  has been merged into this issue.

Comment 29 by, Mar 7 2017

It's been about a year. Has there been work on this? 
 Issue 740551  has been merged into this issue.
Blockedon: 591099
This won't be fixed until our layout engine rewrite (LayoutNG)
Ugh, why is this still broken? There's no good workaround for this.
Can't find any good workaround for this, very upset with this bug

Sign in to add a comment