UserAgent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:47.0) Gecko/20100101 Firefox/47.0

Example URL:
http://codepen.io/tshinnic/pen/LkAAJX

Steps to reproduce the problem:
1. Display linked codepen, note small pink background
2. Experiment with flexitem flex-basis using control at bottom

What is the expected behavior?
Contents of a flexitem should be able to size themselves
relative to the flexitem's height/width.  In the pen the
contained <div> is asking for "height: 100%".  In other
browsers the <div> expands, painting everything with its
pink background.

What went wrong?
Chrome only gives the contained <div> "content height",
just one line of text with a pink background.

Does it occur on multiple sites: N/A

Is it a problem with a plugin? No 

Did this work before? No 

Does this work in other browsers? Yes 

Chrome version: 54.0.2809.0  Channel: canary
OS Version: 10.0
Flash Version: Shockwave Flash 22.0 r0

Likely Blink>Layout>Flexbox

Tested browsers:
    Chrome  51.0.2704.106 m
    Chrome  52.0.2743.82 m
    Chrome  54.0.2809.0 canary (64-bit)
    FireFox 47.0.1
    Edge    25.10586.0
    IE      11.420.10586.0
'fails' in all 3 Chrome versions tested, works in the other 3 browsers.

The definitions of 'definite' and 'indefinite' in relation to the often
documented "flex: auto" have created problems in the past.  This report
is another perhaps related problem, but which is seen not in the container
or a flexitem, but in the contained box within the flexitem.

In the linked codepen the results with Chrome are different from three other
browsers.  Their interpretation seems the more 'useful' in that a 'natural'
usage of CSS "height: 100%" works, giving a full-height inner div.

Concretely stated, within consecutive nested divs using "flex-flow: column"
and then "flex: auto", a content box height requested as "100%" is undefined
and unavailable, only in Chrome.  Contained elements within the flexitem are
not permitted to know the enclosing height and so can not specify their own
height (e.g. "100%") in relation to that, in Chrome.

Using the following HTML,

    <div style="display: flex; flex-flow: column; height: 100%;" >
      <div style="flex: auto; background: white;" >

        <div style="height: 100%; background: pink;" >
          Content within flexitem
        </div>

      </div>
    </div>

under Chrome only the single line of text will have a pink background,
with the enclosing flexitem's white background occupying the rest of the
expanded space.

The white background makes obvious that the *flexitem* has expanded to
occupy the entire available area.  However the single line allocated
to the innermost div shows that the "inner main size" is not being passed
through to the contained <div>.  Requesting "height: 100%" gets you nil.

With the other browsers the white background does not show up at all, as
the innermost div receives the correct height for the requested "100%",
which can be defined as the size of the enclosing flexitem.

The linked pen permits changing the flexitem "flex-basis" to evaluate
the effects of each value.  The only significant difference seen is when
'auto' is selected running Chrome.

Replies to Chrome flexbox reports often mention using 'definite' values
for "flex-basis".  Indeed, using "flex-basis: 100%" produces uniformly
good results in all browsers.  Amazingly, "50%", "1%", or even "0%" are
treated the same in all browsers.  That an illogical, irrational value
like '0%' is better than the often suggested 'auto' is very bad for the
digestion of specs.

Chrome's current interpretation of 'auto' to mean 'indefinite' may be
arguably valid given certain readings of the specs, with the definition
of 'definite' vs. 'indefinite' sizes, and *when* they are in effect,
being at issue.  But for a flexitem to received the correct expanded
height yet report its height as 'unknown' to its contents seems wrong.

Consider the code above.  How is a contained element intended to
decide its actual height?  In particular, how can a contained element
expand to occupy the space of the 'auto' flexitem?  If requesting
"height: 100%" can't do that, WTHey?

In Chrome with this test, the 'auto' flexitem knows its own height, but
is simply not admitting what that value is to the flexitem's children.
That doesn't seem right, does it?

Perhaps this is yet another situation where the CSS WG needs to address
defining flexbox _behavior_, as concrete follow-on to defining terms 
like 'definite' and 'indefinite'.  And I see reference to this process
elsewhere, in text like
  "It is the CSSWG’s intention that browsers will converge on
   one of the behaviors, at which time the spec will be amended
   to require that."
 

Deleted: flexbox_height_within_flex_auto_firefox_47_0_1.png 15.7 KB

	flexbox_height_within_flex_auto_firefox_47_0_1.png 15.7 KB View Download

Deleted: flexbox_height_within_flex_auto_chrome_54.png 16.6 KB

	flexbox_height_within_flex_auto_chrome_54.png 16.6 KB View Download