Ensure we always have a float manager during block-frame reflow.
Normally we shouldn't be starting reflow from a block that is not a BFC,
and so BlockNeedsFloatManager would return true for the reflow root.
What happens in the testcase here, though, is that we call PresShell::FrameNeedsReflow
for the
it's a BFC at that moment.
Then we restyle, and during restyling we remove the NS_BLOCK_BFC flag because the
newly-added element means that the
so we lose the
contain property that was previously set. So is no longera BFC, but we've already recorded it in the PresShell's mDirtyRoots.
We then call PresShell::FrameNeedsReflow for the foreignObject, which adds that
to mDirtyRoots as well.
And then we flush layout, reflowing first the foreignObject (because it is the
shallower of the two dirty-roots) and then the
that the reflow of the SVGForeignObject would fix things, because it would reflow
all its descendants (including ) safely, but there's an early-return in
SVGForeignObjectFrame::Reflow in the case where it is zero-sized (which it is here).
So the
block remains dirty, and PresShell::ProcessReflowCommands triesto reflow it directly even though it is no longer a BFC, and that's when we crash
due to not having a float manager.
Removing that early-return from SVGForeignObjectFrame::Reflow would avoid the crash,
but in any case I think we should make nsBlockFrame::Reflow handle this situation
as there may be other code-paths that potentially set up a similar scenario of
attempting to reflow from a root that has lost its BFC-ness.
Differential Revision: https://phabricator.services.mozilla.com/D228778
bugzilla-url: https://bugzilla.mozilla.org/show_bug.cgi?id=1928724
gecko-commit: 421d7bf240078ff30871183289ce376441fadb09
gecko-reviewers: layout-reviewers, emilio