STR:

1. Ensure you have about:config pref layout.css.grid-item-baxis-measurement.enabled set to true
2. Load attached testcase
3. Open console (ctrl shift k)
4. Type simpleRecreate()

ACTUAL RESULTS:
The logging shows an inconsistent height, before/after the page triggers a "reload" (nuke/restore the dom to force full relayout):

Height after style changes, before reload
#two 190
Height after reload
#two 95

EXPECTED RESULTS:
The height should be consistent.

If you set layout.css.grid-item-baxis-measurement.enabled to false, then the height is consistently 95. So this bug is specific to when we have that optimization enabled.

This testcase was generated by the Layout Quick Check fuzzer (with minor edits/simplification from me); see bug 1724999.

(Briefly: the testcase loads a simple document, and then when you run simpleRecreate(), it makes some dynamic changes, and then captures some layout measurements, and then forces a full relayout and captures the measurements again. And element #two ends up with a different height, before vs. after the full relayout.)

Set release status flags based on info from the regressing bug 1591366

This is only a regression in Nightly; bug 1591366's optimization is preffed off for all other channels for the time being, until we take action in bug 1732082 to let it ride the trains.

Apologies, it looks like I forgot to attach the testcase. Here it is.

Based on Matrix discussion with Sean, it sounds like this might be a case where we've got an existing table bug where table-row layout seems to be improperly stateful (e.g. for a given reflow, the initial row-sizes influence the space distribution, or something to that effect); and this bug may just be one way of demonstrating that statefulness (since we reflow the table a different number of times depending on the optimization).

(I do recall seeing LayoutQuickCheck generate a handful of bugs with table layout, so this might be one of those.)

It would ideally be good to find a non-grid-dependent testcase to confirm this; but assuming it's the case, then I think we can deprioritize this as a bug that would block shipping the grid optimization.

Just to provide some details.

All the frames (including the table frame) gets reflowed correctly first. And when the table frame gets reflowed, it uses a computed container BSize which was 5700 in my local environment. Then, the Trying layout3 code get executed which asks the grid frame to do the reflow again. Since we have cached measurement for the grid items, the table frame won't do any new reflows until the grid container start to reflow its child with the computed container BSize. We will reflow the table frame again here with the same container BSize. Since the container's BSize remains the same, we wouldn't reset the frame's existing BSize to 0, because BResize wasn't set. Finally, when distributeBSizeToRows gets executed, the final BSize becames the existing BSize + the new BSize, which literally doubles the correct value.

This isn't an issue if the grid optimization is turned off because, when Trying Layout3 asks the grid container to do the reflows, the grid items would reflow the table frame with an unconstrained container BSize, so when the table frame gets its final reflow with the computed container's BSize, the existing BSize gets reset to 0 first due to BResize.

It's quite challenging for me to generate a testcase without using grid, because there are lots of conditions.....Can you help me on this Daniel? Thanks!