2020658 - Operator not stretched with two nested mrow.

Status: NEW

(Core :: MathML, enhancement)

Description

[Frédéric Wang Nélar]

Attachment: stretching-embellished-mrow.html

See the attach test case.

1. The first line is <math><mo>(</mo><mspace style="background: lightblue" width="5px" height="200px" depth="100px"></mspace></math> ; it does not stretch because of bug 236963.

2. The second line is <math><mrow><mo>(</mo><mspace style="background: lightblue" width="5px" height="200px" depth="100px"></mspace></mrow></math>, nsMathMLContainerFrame::FinalizeReflow for the mrow will have parentWillFireStretch=false because its parent is a nsMathMLmathInlineFrame, which is not a nsIMathMLFrame: https://searchfox.org/firefox-main/rev/0894e095dfb46b6dac785365432791a54861fe09/layout/mathml/nsMathMLContainerFrame.cpp#490 ; so the function properly takes care of stretching the mo. This is a common work around bug 236963.

3. The third line has two nested mrow: <math><mrow><mrow><mo>(</mo><mspace style="background: lightblue" width="5px" height="200px" depth="100px"></mspace></mrow></mrow></math>. But the inner mrow is actually an embellished operator with baseFrame the <mo>, so the stretch is passed to that inner mrow:

https://searchfox.org/firefox-main/rev/0894e095dfb46b6dac785365432791a54861fe09/layout/mathml/nsMathMLContainerFrame.cpp#305
https://searchfox.org/firefox-main/rev/0894e095dfb46b6dac785365432791a54861fe09/layout/mathml/nsMathMLContainerFrame.cpp#340

To determine the metrics, we exclude embellishments, so the mspace height is not included in the size, only the one of the mo:
https://searchfox.org/firefox-main/rev/0894e095dfb46b6dac785365432791a54861fe09/layout/mathml/nsMathMLContainerFrame.cpp#233 ; so the mo does not stretch.

4. The fourth and fifth line use more nested levels of mrow and use the same logic. However, note that we use the base not the core mo (cf comment from Karl: XXXkt Does that mean the core descendent frame should be used instead of the base child?) so the base becomes the mrow and includes the height of the mo and of the mspace descendents, so the mo properly stretches.

While working on bug 2018403, I'm adding an anonymous mrow. This fixes bug 236963 and the "two nested mrow" bug shows up for one level now. In particular in https://searchfox.org/firefox-main/rev/0894e095dfb46b6dac785365432791a54861fe09/testing/web-platform/tests/mathml/presentation-markup/mrow/inferred-mrow-stretchy.html#49 (this could be worked around with an empty mn to make the mrow non-embellished).

Comment 1

[Frédéric Wang Nélar]

MathML Core's algorithm for operator stretching is a bit different to what we have, it's based on these:
https://w3c.github.io/mathml-core/#dfn-algorithm-for-stretching-operators-along-the-block-axis
https://w3c.github.io/mathml-core/#algorithm-for-stretching-operators-along-the-inline-axis

In both case, we layout all children without any stretch constraint or a zero one, in order to obtain their unstretched size. Then we layout the embellished op children with a stretch constraint based on the max unstretched sizes of children. So embellishments are always included. I think we could always use PreferredStretchSizeMode::Embellishments instead of PreferredStretchSizeMode::EmbellishmentsIfSameStretchDirection in order to get closer to MathML Core and fix this bug.

PreferredStretchSizeMode::Embellishments uses Place() which I believe does not fire stretching, although I suspect it can reuse the size of a previous stretch/layout, which is different to MathML Core doing the layout with an explicit stretch constraint.

Comment 2

[Frédéric Wang Nélar]

Thinking again, MathML Core actually says to include the size of the embellished operartors (with its embellishments) if L_NotToStretch is empty. In general they do not enter into the calculation of operator stretching.

Comment 3

[Frédéric Wang Nélar]

Attachment: WIP: Bug 2020658 - Add test for embellished operator stretching with various levels of nested mrows.