Daniel Holbert 3555fe34a3 Bug 1105111 part 3: Add support for 'flex-basis:content' in layout. r=mats ...

BACKGROUND:
Early in flex layout, we have to resolve the 'flex-basis' value to produce the
"flex base size" (basically, the flex-basis resolved to an absolute length).

This resolution happens in two "phases" (which both happen within
nsFlexContainer::GenerateFlexItemForChild()):

First phase: we try to resolve the flex-basis by creating a ReflowInput for the
flex item (which gets us some other things as well).  Under the hood, we use
the flex-basis when resolving this ReflowInput's main-axis size.  The code for
this lives in nsFrame::ComputeSize (and in
nsFrame::ComputeSizeWithIntrinsicDimensions, via some frame classes' overrides of
ComputeSize).

Second phase: If the first phase didn't get us a definite size, then that means
we have to do reflow to measure the content size & produce a resolved flex base
size, which we do via ResolveAutoFlexBasisAndMinSize().

NOTES ON THIS PATCH:
To add 'flex-basis:content' support to layout, this patch only needs to modify
the first phase discussed above. If it turns out we also have some second-phase
work to do (i.e. if we need to do reflow to resolve 'flex-basis:content'), this
patch causes that reflow to happen by simply making us use eStyleUnit_Auto in
the main axis's nsStyleCoord in the first phase.  (And then, if that 'auto'
nsStyleCoord really does require reflow, then that first phase will end up
producing an unconstrained main-size in the flex item's ReflowInput, which will
automatically trigger the second phase.)

MozReview-Commit-ID: 2nH4Fh78C81

2018-04-02 04:30:38 +02:00

83 KiB

Raw Blame History

View Raw