Bugzilla

I think this is a case where we need to activate this sort of code, and treat our "final reflow" as a BSize change for the purposes of relative-height descendants:
https://searchfox.org/mozilla-central/rev/d48b18fa27315206bf68d4dac82bc4e27a3f138e/layout/generic/nsFlexContainerFrame.cpp#5108-5111,5119-5121

That code has logic to handle the following scenario:
 (1) [Enter reflow for Flex Container A]
 (2) Flex container does "measuring reflow" of item, with unconstrained/indefinite BSize
 (3) flex item BSize is resolved
 (4) Flex container does "final reflow" of item, with known & "definite" BSize, with this reflow treated as a block-axis resize so that we'll be sure to reflow percent-height descendants even if they don't think they're dirty.
 (5) [Exit reflow for Flex Container A]

However, the logic doesn't handle scenarios where step (2) happens before step (1) -- i.e. where the "measuring reflow" happened in an **earlier call** into nsFlexContainerFrame::Reflow.  This is possible if we're several layers deep in nested flex containers.  In that scenario, the relevant nsFlexContainerFrame::Reflow call will a cached already-computed flex-item measurement, and it'll jump straight to the "final reflow" for this flex item, without needing to perform any measuring reflow this time.  So `aItem.HadMeasuringReflow()` will be false and we won't do `childReflowInput.SetBResize(true)`, even though we need to do so, because this is potentially the first time we're laying out this child with a definite height.

I think this is a case where we need to activate this sort of code, and treat our "final reflow" as a BSize change for the purposes of relative-height descendants:
https://searchfox.org/mozilla-central/rev/d48b18fa27315206bf68d4dac82bc4e27a3f138e/layout/generic/nsFlexContainerFrame.cpp#5108-5111,5119-5121

Currently, that^^ linked searchfox code has logic to handle the following scenario:
 (1) [Enter reflow for Flex Container A]
 (2) Flex container does "measuring reflow" of item, with unconstrained/indefinite BSize
 (3) flex item BSize is resolved
 (4) Flex container does "final reflow" of item, with known & "definite" BSize, with this reflow treated as a block-axis resize so that we'll be sure to reflow percent-height descendants even if they don't think they're dirty.
 (5) [Exit reflow for Flex Container A]

However, the logic doesn't handle scenarios where step (2) happens before step (1) -- i.e. where the "measuring reflow" happened in an **earlier call** into nsFlexContainerFrame::Reflow.  This is possible if we're several layers deep in nested flex containers.  In that scenario, the relevant nsFlexContainerFrame::Reflow call will a cached already-computed flex-item measurement, and it'll jump straight to the "final reflow" for this flex item, without needing to perform any measuring reflow this time.  So `aItem.HadMeasuringReflow()` will be false and we won't do `childReflowInput.SetBResize(true)`, even though we need to do so, because this is potentially the first time we're laying out this child with a definite height.

I think this is a case where we need to activate this sort of code, and treat our "final reflow" as a BSize change for the purposes of relative-height descendants:
https://searchfox.org/mozilla-central/rev/d48b18fa27315206bf68d4dac82bc4e27a3f138e/layout/generic/nsFlexContainerFrame.cpp#5108-5111,5119-5121

Currently, that^^ linked searchfox code has logic to handle the following scenario:
 (1) [Enter reflow for Flex Container A]
 (2) Flex container does "measuring reflow" of flex item, with unconstrained/indefinite BSize
 (3) Flex item BSize is resolved and is now considered definite
 (4) Flex container does "final reflow" of flex item, with known & "definite" BSize, with this reflow treated as a block-axis resize so that we'll be sure to reflow percent-height descendants inside the flex item, even if the height didn't change & they don't think they're dirty.
 (5) [Exit reflow for Flex Container A]

However, the logic doesn't handle scenarios where step (2) happens before step (1) -- i.e. where the "measuring reflow" happened in an **earlier call** into nsFlexContainerFrame::Reflow.  This is possible if we're several layers deep in nested flex containers.  In that scenario, the relevant nsFlexContainerFrame::Reflow call will a cached already-computed flex-item measurement, and it'll jump straight to the "final reflow" for this flex item, without needing to perform any measuring reflow this time.  So `aItem.HadMeasuringReflow()` will be false and we won't do `childReflowInput.SetBResize(true)`, even though we need to do so, because this is potentially the first time we're laying out this child with a definite height.

I think this is a case where we need to activate this sort of code, and treat our "final reflow" as a BSize change for the purposes of relative-height descendants:
https://searchfox.org/mozilla-central/rev/d48b18fa27315206bf68d4dac82bc4e27a3f138e/layout/generic/nsFlexContainerFrame.cpp#5108-5111,5119-5121

Currently, that^^ linked searchfox code has logic to handle the following scenario:
 (1) [Enter reflow for Flex Container A]
 (2) Flex container does "measuring reflow" of flex item, with unconstrained/indefinite BSize
 (3) Flex item BSize is resolved and is now considered definite
 (4) Flex container does "final reflow" of flex item, with known & "definite" BSize, with this reflow treated as a block-axis resize so that we'll be sure to reflow percent-height descendants inside the flex item, even if the height didn't change & the descendants don't think they're dirty.
 (5) [Exit reflow for Flex Container A]

However, the logic doesn't handle scenarios where step (2) happens before step (1) -- i.e. where the "measuring reflow" happened in an **earlier call** into nsFlexContainerFrame::Reflow.  This is possible if we're several layers deep in nested flex containers.  In that scenario, the relevant nsFlexContainerFrame::Reflow call will a cached already-computed flex-item measurement, and it'll jump straight to the "final reflow" for this flex item, without needing to perform any measuring reflow this time.  So `aItem.HadMeasuringReflow()` will be false and we won't do `childReflowInput.SetBResize(true)`, even though we need to do so, because this is potentially the first time we're laying out this child with a definite height.

I think this is a case where we need to activate this sort of code, and treat our "final reflow" as a BSize change for the purposes of relative-height descendants:
https://searchfox.org/mozilla-central/rev/d48b18fa27315206bf68d4dac82bc4e27a3f138e/layout/generic/nsFlexContainerFrame.cpp#5108-5111,5119-5121

Currently, that^^ linked searchfox code has logic to handle the following scenario:
 (1) [Enter reflow for Flex Container A]
 (2) Flex container does "measuring reflow" of flex item, with unconstrained/indefinite BSize. (So: percent-height descendants get laid out with percentages treated as auto.)
 (3) Flex item BSize is resolved and is now considered definite
 (4) Flex container does "final reflow" of flex item, with known & "definite" BSize, with this reflow treated as a block-axis resize so that we'll be sure to reflow percent-height descendants inside the flex item, even if the height didn't change & the descendants don't think they're dirty. (So: percent-height descendants will be forced to re-lay-out out with percentages resolved appropriately.)
 (5) [Exit reflow for Flex Container A]

However, the logic doesn't handle scenarios where step (2) happens before step (1) -- i.e. where the "measuring reflow" happened in an **earlier call** into nsFlexContainerFrame::Reflow.  This is possible if we're several layers deep in nested flex containers.  In that scenario, the relevant nsFlexContainerFrame::Reflow call will a cached already-computed flex-item measurement, and it'll jump straight to the "final reflow" for this flex item, without needing to perform any measuring reflow this time.  So `aItem.HadMeasuringReflow()` will be false and we won't do `childReflowInput.SetBResize(true)`, even though we need to do so, because this is potentially the first time we're laying out this child with a definite height.

I think this is a case where we need to activate this sort of code, and treat our "final reflow" as a BSize change for the purposes of relative-height descendants:
https://searchfox.org/mozilla-central/rev/d48b18fa27315206bf68d4dac82bc4e27a3f138e/layout/generic/nsFlexContainerFrame.cpp#5108-5111,5119-5121

Currently, that^^ linked searchfox code has logic to handle the following scenario:
 (1) [Enter reflow for Flex Container A]
 (2) Flex container does "measuring reflow" of flex item, with unconstrained/indefinite BSize. (So: percent-height descendants get laid out with percentages treated as auto.)
 (3) Flex item BSize is resolved and is now considered definite
 (4) Flex container does "final reflow" of flex item, with known & "definite" BSize, with this reflow treated as a block-axis resize so that we'll be sure to reflow percent-height descendants inside the flex item, even if the height didn't change & the descendants don't think they're dirty. (So: percent-height descendants will be forced to re-lay-out out with percentages resolved appropriately.)
 (5) [Exit reflow for Flex Container A]

However, the logic doesn't handle scenarios where step (2) happens before step (1) -- i.e. where the "measuring reflow" happened in an **earlier call** into nsFlexContainerFrame::Reflow.  This is possible if we're several layers deep in nested flex containers.  In that scenario, the relevant nsFlexContainerFrame::Reflow call ("Step 1" above) will find a cached already-computed flex-item measurement, and it'll jump straight to the "final reflow" for this flex item, without needing to perform any measuring reflow this time (skipping Step 2 above).  So `aItem.HadMeasuringReflow()` will be false and we won't get to the `childReflowInput.SetBResize(true)` call, even though we need to do so, because this is potentially the first time we're laying out this child with a definite height, which makes it effectively a block-axis resize from the perspective of percent-height descendants.