User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.3a1pre) Gecko/20090923 Minefield/3.7a1pre Build Identifier: Large operators with implicit/explicit displaystyle="true" must be displayed larger (see testcase). The screenshot shows the expected result on the left (Amaya) and the rendering in Gecko on the right. Reproducible: Always

Looks like displaystyle="true" is also being ignored re moveablelimits.

(In reply to comment #3) > Looks like displaystyle="true" is also being ignored re moveablelimits. You're right. I'm almost sure that previous versions of Gecko interpret moveablelimits correctly. When I set the macro NS_MATHML_IS_DISPLAYSTYLE to true, then the limits are placed correctly but the sigma symbol is still small.

The previous testcase was not valid, (displaystyle was used as an attribute of mrow). With this new version, the explicit displaystyle="true" is now taken into account.

OK, my testcase was not correct. So actually the rendering of movablelimits is good and the bug is really about the size of largeop.

According to chapter 3, section "The Top-Level math Element": "When display="block", displaystyle is initialized to "true", whereas when display="inline", displaystyle is initialized to "false"; [...] When this attribute is missing, a rendering agent is free to initialize as appropriate to the context." So it is not a bug if Mozilla does not set displaystyle="true" in the second testcase (no explicit display attribute on the <math/> element) but it could be a desired feature. Currently, Mozilla set displaystyle="false", except when the user specifies that it should be true. In my opinion, the behavior of Amaya is better: when the <math/> is alone in a block element, displaystyle="true" but when the <math/> is among other elements (for instance text) displaystyle="false".

I've just checked the source code of Amaya. Here is how the displaystyle of the <math/> element is set : If the <math/> element has a display attribute, use its value. Otherwise, if the <math/> element is the root of the document or a child of an svg element, set displaystyle to true. Otherwise, if the <math/> element is the child of an html element, look to the context. If it is a child of a <body/>, a <div/> then set displaystyle to true. If it is the only child of a <p/> (or an internal object "pseudo paragraph" that seems to be used for editing features, so it doesn't matter here) then set displaystyle to true. In all other cases, set displaystyle to false. I wonder whether just adding some contextual checking in nsMathMLFrame to set displaystyle to true would be OK: http://mxr.mozilla.org/mozilla-central/source/layout/mathml/nsMathMLFrame.cpp#229

If the display attribute of the math element didn't have the default "inline" specified, then perhaps the block/inline decision could have been made based on the context. But it would seem strange to me to have displaystyle initialized differently depending on whether display="inline" was explicitly specified or merely the default.

I still think a displaystyle="true" is only relevant when the <math/> element is surrounded by text inside the same paragraph. However, you're right that it's weird to have different behaviors for the implicit & explicit values (although the spec allows it), so let's not change it for the moment.

Karl, do you have a testcase for this bug?

(In reply to comment #12) > Karl, do you have a testcase for this bug? Sorry, I meant for bug 584332.

This bug should be fixed now we have a complete support for STIX fonts and implement the workaround of the scale-stretchy bug.