Bug 97747 - width on a flexitem should not affect the min-width: auto constraint
Summary: width on a flexitem should not affect the min-width: auto constraint
Status: RESOLVED DUPLICATE of bug 111790
Alias: None
Product: WebKit
Classification: Unclassified
Component: Layout and Rendering (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
Depends on: 106143
Blocks: 62048
  Show dependency treegraph
Reported: 2012-09-26 18:08 PDT by Daniel Holbert
Modified: 2013-03-07 16:25 PST (History)
3 users (show)

See Also:

testcase 1 (958 bytes, text/html)
2012-09-26 18:19 PDT, Daniel Holbert
no flags Details
reference case 1 (905 bytes, text/html)
2012-09-26 18:29 PDT, Daniel Holbert
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Daniel Holbert 2012-09-26 18:08:08 PDT
Midori 0.4.3
Chrome Version 23.0.1271.6 dev
Comment 1 Daniel Holbert 2012-09-26 18:11:31 PDT
(sorry, accidentally bumped "enter" key while typing bug summary & filed bug prematurely)

The flexbox spec says that "min-width:auto" on a flex item is supposed to resolve to the min-content width.

However, when there's a "width" property-value specified on the item, webkit appears to be clamping to that width, instead of to the min-content width.

Testcases coming up.
Comment 2 Daniel Holbert 2012-09-26 18:19:03 PDT
Created attachment 165909 [details]
testcase 1

This testcase has a block with:
        flex: 1 1 0px;
        width: 1000px;
inside of a 50px-wide flexbox. (with -webkit and -moz prefixes on flex properties)

I believe the "width: 1000px" there should have no effect. It's not used as the flex-base, clearly, because we have "0px" in the flex specification.  It's also not part of the block's min-content width, unless I'm misunderstanding what the spec authors had in mind with "min-content width".
Comment 3 Daniel Holbert 2012-09-26 18:29:30 PDT
Created attachment 165910 [details]
reference case 1

Here's a reference case, with the "width: 1000px" removed.

I'd expect the testcase to render just like this reference case -- the 1000px shouldn't impact the minimum size that we clamp shrinkage at.

Relevant spec text:
  # auto
  #  When used as the value of a flex item's min main size property,
  # this keyword indicates a minimum of the min-content size, to help
  # ensure that the item is large enough to fit its contents.
  # It is intended that this will compute to the ‘min-content’ keyword
  # when the specification defining it (Writing Modes Appendix D) is
  # sufficiently mature. 

So "min-width: auto" is supposed to effectively compute to "min-width: min-content".

And when we resolve "min-width: min-content", I believe we're supposed to only use the contents of the block -- the computed value of "width" shouldn't affect the calculation.  (If it did, then "width: min-content" would have a circular dependency.)
Comment 4 Ojan Vafai 2012-09-26 21:15:20 PDT
Thanks for filing the bug! I think we just didn't test cases of setting both the flex-basis and the width to fixed values
Comment 6 Daniel Holbert 2013-01-28 15:34:53 PST
It's been ~4 months since the last comment here -- any updates / ETA for this?  Just want to make sure this doesn't fall off the radar, since I think this could lead to interop issues & developer confusion.

(I just received an email today regarding a testcase that rendered differently in Gecko vs. WebKit, and it ended up being due to this bug.)

Per comment 5, it seems like this should at least be upgraded from UNCONFIRMED to NEW or something. :)
Comment 7 Tony Chang 2013-01-28 15:38:32 PST
Ojan is working on this, he got side tracked by mathml :)
Comment 8 Ojan Vafai 2013-01-28 16:06:48 PST
Yup. I'm finally getting back to this. FWIW, I have been working on this and committing related patches. It's just that the fix requires rewriting a bunch of code. The final patch will be the one that fixes this as a one-liner. :) I'll try to get this done ASAP.
Comment 9 Ojan Vafai 2013-03-07 16:25:22 PST
The spec has changed and this will be fixed with bug 111790.

*** This bug has been marked as a duplicate of bug 111790 ***