User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/115.0.0.0 Safari/537.36

Steps to reproduce:

Create an HTML layout with a flex parent element and set a direct child (flex item) also to display: flex;
Set the writing-mode of the children (flex items) of the nested flex element to a vertical value, e.g. to vertical-lr.

I set up a CodePen with the explained setup where the issue can be seen and tested:
https://codepen.io/glmvc/pen/LYdErxy

Tested in Firefox Version 116.0.2 (64-bit) and Firefox Developer Edition Version 117.0b1 on macOS Ventura (Version 13.4)

Actual results:

The layout described causes the nested flex element to have a calculated final size of 0(px).

Expected results:

The final size of the nested flex element is calculated correctly in other major browsers.

The Bugbug bot thinks this bug should belong to the 'Core::Layout' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Regression window:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=6480454995dae4a44c86887f4ae01dc998edb36f&tochange=e4c4c815992454d67e947beb0c18aa5202c26579

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

:dholbert, since you are the author of the regressor, bug 1454822, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

Attaching reduced test case.
Interestingly enough, padding: 0 is required to repro the exact behaviour, and toggling it in inspector results in the expected behaviour.

Also should be noted that if the padding was removed altogether in the testcase, ul size seems to make sense, but li contents are pushed out.

FWIW,
Regression window(with Reduced test case and use width: -moz-fit-content ):
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=6480454995dae4a44c86887f4ae01dc998edb36f&tochange=e4c4c815992454d67e947beb0c18aa5202c26579

Suspect: Bug 1454822

Thanks for linking to bug 1310551, dshin -- I think this is indeed a version of that bug, which happens to get inadvertently worked-around if we reflow the same frame several times.

Bug 1454822 was an optimization to remove some redundant reflows (or reflows that should be redundant, except in cases of known bugs like bug 1310551). So it makes sense that this would be an instance of bug 1310551, which was ~hidden until we landed bug 1454822.