IF the following conditions are satisfied, for a flex container: (1) Only one flex item is flexible (the others all have "flex-grow:0; flex-shrink:0", e.g. from "flex:none") (2) The one flexible flex item has *both* flex-grow & flex-shrink values that are >= 1 (e.g. from "flex:auto" = "1 1 auto") (3) The one flexible flex item has a 'flex-basis' that requires content-measurement. (e.g. it's "auto", and our container is vertical, and the item also has "height:auto") THEN: We can just behave as if the flex-basis is 0, and skip any content measurement that we technically should be doing to honor (3). This is because regardless of where we start its flex-basis, we'll end up with the flexible flex item immediately absorbing all of the free space (or negative space). So the exact value of the flex basis doesn't impact our actual layout. (Case in point: Bug 1162725 gives us a ~20% speedup on TreeHerder, for exactly such a case. We fixed it by optimizing the TreeHerder CSS, but we could also pretty easily detect & optimize this case in Gecko.)

(We still may have to do content measurement to honor "min-height:auto", though -- if that's the case, this optimization won't help. In bug 1162725, we didn't need to measure content for "min-height:auto", because the item had "overflow-y:auto", which makes its "min-height:auto" resolve to 0, per a special case in the flexbox spec.)