At the beginning of the flexbox algorithm, we need to get the computed size (possibly the shrinkwrapped size) of each child-frames, *without* taking min/max width/height into consideration.
We can't easily do this right now, though. nsIFrame::ComputeSize is the obvious method to use, but it applies min/max constraints to the returned values.
THEREFORE: I'd like to allow nsIFrame::ComputeSize to optionally ignore min/max. To do that, I'd like to replace the final |bool aShrinkWrap| ComputeSize argument with a "flags" bitfield (with eShrinkWrap being the first flag in that field).
 The flexbox algorithm starts with these sizes, _then_ assigns extra space based on flexibility, and _then_ clamps based on min/max constraints. If we apply min/max constraints too early, it'll produce different, incorrect behavior, since there will be a different amount of available space.
Created attachment 602516 [details] [diff] [review]
Not sure this is complete/correct, but it compiles. Will request review after a bit more sanity-checking.
Branch: mozilla-central => try
Try run started, revision 65c185a8ba68. To cancel or monitor the job, see: https://tbpl.mozilla.org/?tree=Try&rev=65c185a8ba68
Try run for 65c185a8ba68 is complete.
Detailed breakdown of the results available here:
Results (out of 6 total builds):
Builds (or logs if builds failed) available at:
Comment on attachment 602516 [details] [diff] [review]
I wonder if you should make the same conversion apply to ComputeAutoSize, though.
We should definitely use MOZ_OVERRIDE more aggressively in layout.
(In reply to David Baron [:dbaron] from comment #4)
> I wonder if you should make the same conversion apply to ComputeAutoSize,
I didn't do that yet because the one flag that I'm interested in adding (for "ignore min/max width/height properties") isn't needed in ComputeAutoSize. (That method already ignores min/max constraints.)
It might be good for consistency & future-proofing, though. Let me know if you'd like me to do that as part of this bug; otherwise I'll hold off on it for now.
> We should definitely use MOZ_OVERRIDE more aggressively in layout.
Agreed. I've just filed bug 733186 on that.