Created attachment 285314 [details] Testcase Jacques Distler reported the following issue: 'The "big fraction" of https://golem.ph.utexas.edu/wiki/instiki/show/Sandbox is summarily truncated'. It seems that the overflow is hidden for MathML formula in display="block": no scroll bars appear which may explain that the formula looks "truncated". See the attached testcase comparing a simple formula in display and inline style.

Created attachment 285315 [details] Testcase A better test case using a horizontal gradient from red to green. You should be able to scroll to the green part but that does not seem possible in nightly.

Created attachment 285326 [details] Experimental Patch Some first thoughts: In general, because the preferred width of operators is overestimated (see https://bug-130326-attachments.webkit.org/attachment.cgi?id=283599). Hence all the MathML layoutBlock functions must set the correct logical width rather than relying on the preferred width. Then the RenderBox code use this logical width rather than filling the all available width. There is an exception for <math display="block">: this must be rendered as a formula centered in the available space. Hence RenderMathMLRow::layoutBlock does not set the its logicalWidth to the width of the math content so that the centering done is this function is correct (http://tests.mathml-association.org/mathml/relations/html5-tree/display-1.html). I guess something in RenderBox also make it also occupy the whole available width. But when the available width is less than the width of the math content, the <math> tag is too narrow. I'm attaching a hack that just injects the preferredLogicalWidth to force a minimal width but the ideal would be for RenderMathMLRow to expose the width of the math content and let RenderBox calculate the logical width by taking the maximum of the available width and of the width of the math content. Maybe rego or jfernandez have suggestions about how to do that.