Bug 115039

In the second pass of layout for auto-height regions, the flexbox container clears the overrideLogicalHeight for the autoHeight region before the overrideLogicalHeight (which stores the computed autoHeight value after the first phase) is transfered into the regions height.

Created attachment 199334 [details] test file 2 Here's another test file. In this case the region in the flex container is taking on the height of the container, but the second region isn't sizing correctly (there should be a black line around the second region's content - what you're seeing is overflow). If you take the border off the regions, the overflow in the second region disappears (perhaps this is a separate bug?)

The issue from the first test case has been fixed in #118057. (In reply to comment #2) > Created an attachment (id=199334) [details] > test file 2 > > Here's another test file. In this case the region in the flex container is taking on the height of the container, but the second region isn't sizing correctly (there should be a black line around the second region's content - what you're seeing is overflow). If you take the border off the regions, the overflow in the second region disappears (perhaps this is a separate bug?) The fact that the second region does not increases its size for fitting the content proved to be the correct behaviour according to the spec. The rfcb height resolution with auto-height regions inside flexboxes roughly works as follows: 1. layout document using height=0 for auto-height regions. This includes a full flexbox layout. 2. Layout flow thread content and compute the height of auto-height regions ignoring any constraints set by the flex container. 3. layout document using the computed heights from step 2, this time honoring the constraints set by the flex container. What this means is that, for test 2, the first region will compute a height equal to the flowthread's height and the second region will compute a height equal to zero (in step 2). In step 3 the flex container will apply constraints on the first region shrinking it and causing overflow. The overflow not being displayed unless the region with zero height has a border is another bug, indeed.

Closing this one as per the above discussion and the conclusion that the current behavior is spec-compliant. For the zero-height region issue, bug 98265 is already logged.