To assist in validating that bug 1376536 is (soon) fixed, and to assist in diagnosing flexbox-related perf issues in the future: let's add some logging to warn for cases when flex items are reflowed multiple times. These may be somewhat spammy, so we can make them opt-in using the exiting MOZ_LOG stuff in nsFlexContainerFrame.cpp.

BTW, just to illustrate how this looks in the wild -- if I apply this patch and run > MOZ_LOG="nsFlexContainerFrame:5" ./mach run ...then I see lines like this go by while we're doing flex reflow for WhatsApp Web (the scenario in bug 1376536): > [Child 5560: Main Thread]: D/nsFlexContainerFrame [perf] MeasureAscentAndBSizeForFlexItem rejected cached value > [Child 5560: Main Thread]: D/nsFlexContainerFrame [perf] Flex item needed both a measuring reflow and a final reflow And when I apply one of the WIP patches on bug 1503660, the former line ("rejected cached value") goes away, as does a bunch of other logging for flex reflow inside the subtree that we no longer have to remeasure. The latter line ("needed both") still gets logged -- though that one's not really problematic in this case, I think, because the "measuring reflow" is actually a no-op because it's benefiting from having a cached value which we can use. (It's still worth it to report this second line though, IMO, because it's a signal that we *might* be reflowing an item multiple times.)

Pushed by dholbert@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/e9ac4160d051 Add MOZ_LOG logging to note when we reflow a flex item extra times. r=emilio