Flexbugs: Firefox 36 flex-basis `0%` in sized container

[ssorallen]

This example demonstrates the problem: http://codepen.io/anon/pen/xbmxjz

The button toggles between flex-basis: 0%; and flex-basis: 0px; on the element that has overflow content. In both Chrome 41 and Safari 8 toggling the class has no effect. In Firefox, the height of wrapper overflow: auto; element grows to the height of its content when the basis uses 0% instead of 0px.

This can probably be boiled down to an even smaller test case to put into a concise bug report. Seeing that Safari and Chrome have no problem and that 0% == 0px == 0 in all other CSS attributes this doesn't seem like correct behavior.

[ssorallen]

Using the unitless 0 similarly has no problem in Firefox.

This bug is problematic because flex: 1; is expanded to flex: 1 1 0%; in Firefox, and 0% is the apparent buggy case.

[philipwalton]

Hmmmm, this is definitely a bug, and I think it should be reported to FF, but I'm not sure it should be listed here. It seems pretty edge-casey to me.

It seems to _only_ happen with overflow and nested flex items _and_ when the nested item has content larger than its container. The workaround would be to _always_ use flex: 1 1 0px instead of flex: 1, but I'm not sure if that's worth it for a bug that only occurs in very specific situations.

Thoughts?

[ssorallen]

Agreed, the example is a rather specific test case. I dropped it here in case someone were to poke around and discover it was actually a more common bug.

I planned to use 1 1 0px in this case, but that contradicts the suggestion given in #4 to support IE by using 0% for flex-basis.

[ssorallen]

It's fine with me if you want to close this for now. I need to try some alternatives anyway, and so if I discover this is more general than my original test case I can re-open or open a new issue.

[philipwalton]

I planned to use 1 1 0px in this case, but that contradicts the suggestion given in #4 to support IE by using 0% for flex-basis.

That's true, but using 0px is only a problem if the minifier you're using strips the px unit.

I'll close this for now, but @ssorallen, can you report this bug to FF (https://bugzilla.mozilla.org) and then list it here so others can find it?

[ssorallen]

Thanks, I'll open a bug with them.

This turns out to be more generic than I thought and happens without modifying flex-basis: http://codepen.io/anon/pen/xbmxjz

A sized container with a nested container with overflow content.

[rmwxiong]

I've just run into a similar issue in Chrome 43. Have a rather complicated DOM structure, so can't seem to easily repro this in a sandbox, but essentially toggling between 0% and 0px is causing the element to use the height of its content.

[rmwxiong]

I should note that the issue appears for me with flex: 1, and goes away with flex: 1 0 0

[ssorallen]

I since ran into this problem again and discovered a change in Firefox 34 is what broke the test case in my latest post: https://developer.mozilla.org/en-US/Firefox/Releases/34/Site_Compatibility#CSS

Since Firefox 22, the initial value of the min-width and min-height properties has been 0 even on flex items. According to the latest CSS Flexible Box Layout Module spec, this value has been changed back to auto which will be calculated to the minimum item (min-content) size in a flexbox, while it's still 0 on non-flex items. If your style has any flex items, you may want to test the page with Firefox Aurora and explicitly define min-height:0 to keep the behavior as before.

Setting min-width: 0; on the .flx class in the CodePen (http://codepen.io/anon/pen/xbmxjz) makes the pen render as desired in Firefox.

[rmwxiong]

Managed to repro it! Haven't tested in other browsers, but it should repro in Chrome 43: http://codepen.io/MaxXiong/pen/RPKXvp

[rmwxiong]

It seems the Chrome guys have also just tackled that, if I'm reading this bug log correctly: https://code.google.com/p/chromium/issues/detail?id=426898