The testcase demonstrates the problem. This bug makes the embStretch1 test fail: http://www.w3.org/Math/testsuite/build/main/Topics/EmbellishedOp/embStretch1-full.xhtml

First experiments to find where the problem comes from: the Stretch is called on the mo but the size passed seems incorrect. The size taken for the math element is given by aDesiredSize.mBoundingMetrics here: http://mxr.mozilla.org/mozilla-central/source/layout/mathml/nsMathMLContainerFrame.cpp#541 I don't know if it is related to bug 219873...

BTW, the bug can also be seen on the Webkit MathML Demo page (section Operator Stretching): http://www.webkit.org/demos/mathml/MathMLDemo.xhtml

Only nsMathMLContainerFrame knows (through GetPrefferedStretchSize) what size to use in stretching its children. Possible solutions might be: 1) Reimplementing nsMathMLmathBlockFrame using nsMathMLContainerFrame. The line-breaking provided by nsBlockFrame would typically not be very good anyway. 2) Or insert an nsMathMLmrowFrame under the nsMathMLmathBlockFrame. Perhaps this could be done with an anonymous mrow element, though don't know what consequences that might have.

I guess your suggestions apply to nsMathMLmathInlineFrame too? In both cases, it seems that it is going to break the line-breaking support for the direct children of the <math/> element...

Yes, and yes. Have you noticed line-breaking working effectively, anywhere?

(In reply to comment #6) > Yes, and yes. Have you noticed line-breaking working effectively, anywhere? If you mean whether line-breaking is implemented in other UAs, I don't know. However, I think our line-breaking implementation - even limited - is important for many pages that contain several inline formulas inside paragraphs of text. At least, I find line-breaking more important than this bug, which can be worked-around by users with the insertions of <mrow/> in their MathML sources.