A bunch of assertions in bug 307992 were due to a bug that wasn't the main problem there, which I (probably incorrectly) patched there instead of filing a new bug. However, my patch there really wasn't sufficient. We should really do a better job of making sure nsHTMLReflowState::mLineLayout is not propagated into reflow states that don't participate in the line. We now null it out both when reflowing a block frame and when going from box to non-box. However, I think we should probably do the reverse: only copy the mLineLayout member when we know it's appropriate, i.e., when we're reflowing an inline frame, BR frame, or text frame. (A more complicated alternative that we might want to try at some point would be to have a different Reflow signature for inline reflow that assumes a line layout. Then these frame classes could have a Reflow method that calls a ReflowBlock method on nsFrame that shares a bit of code with nsBlockFrame. However, it would probably be easier to just ensure in the frame constructor that these frames are always wrapped with a block frame.) In that bug I also suggested patching SVG and MathML the same way I patched XUL. It's worth noting that SVG doesn't have the problem, and I'm a little scared of patching MathML because it may participate in line layout (I need to investigate).

I don't have access to bug 307992. Care to cc: me to there? ATM, the block or inline container do the line-wrapping on behalf of MathML, e.g, either of these will wrap: <math display="block" xmlns="http://www.w3.org/1998/Math/MathML"> <mi>a</mi> <mi>b</mi> ... <mi>z</mi> </math> <math display="inline" xmlns="http://www.w3.org/1998/Math/MathML"> <mi>a</mi> <mi>b</mi> ... <mi>z</mi> </math> With that and those numerous/tiny text frames all over the place, it might be easier to view MathML frames as inline (that's what I have been doing all along). ------- Coincidentally, I am having a linelayout problem in bug 309120. Given a foreign frame that has crept in the math, I have to reflow it, and so must decide whether/which linelayout to provide: either null, a new one on the stack, or the propagated one. As it is murky to test against all possible foreign frames to figure out what to do, I have been considering passing a linelayout, not knowing the issue you had in bug 307992, and whether it is relevant in my case too.

This only propagates the line layout when we need it. Reftests pass (modulo three failures with nondeterministic image upscaling (random data around the edges) that only seem to happen on my machine).

Checked in to trunk.