Incorrect widths of math elements in Gecko

[fred-wang]

Follow-up of Peter's report on the dev list, there are issues with width of math elements in Gecko. MML.math has the following block:

if (nMML.widthBug && !mtable.nMMLforceWidth && mtable.nMMLlaMatch))) {
       //
       //  Convert size to ex's so that it scales properly if the print media
       //    has a different font size.
       //
      parent.style.width = (math.firstChild.scrollWidth/nMML.ex).toFixed(3) + "ex";
     }

As I read it, this will not be executed if there is not any mtable. I think we disabled the correction when we added the mlabeldtr workaround in 0891402#L5L621 (issue #356). The condition should probably be:

    nMML.widthBug && !(mtable.nMMLhasLabels && (mtable.nMMLforceWidth || !mtable.nMMLlaMatch))

But then this gives too large widths. It seems to be due to the conversion to ex which was introduced in debc240#L3L618 (issue #386)

[pkra]

Thanks, Fred!

[fred-wang]

Peter's original test case was test/sample-mml but it's somewhat difficult to reproduce. Here are some test cases related to this bug:

<p>Gecko's bug 415413 (for the Zoom we have a workaround):</p>
  <table>
    <tr>
      <td style="border: 1px solid black">
        <math><mi>f</mi><mi>f</mi><mi>f</mi><mi>f</mi><mi>f</mi><mi>f</mi><mi>f</mi><mi>f</mi><mi>f</mi><mi>f</mi></math>
      </td>
    </tr>
  </table>

<p>Gecko's bug 415413 with mlabeledtr</p>
<math>
  <mtable>
    <mlabeledtr>
      <mtd><mtext>LABEL</mtext></mtd>
      <mtd style="border: 1px solid black">
        <mi>f</mi><mi>f</mi><mi>f</mi><mi>f</mi><mi>f</mi><mi>f</mi><mi>f</mi><mi>f</mi><mi>f</mi><mi>f</mi>
      </mtd>
    </mlabeledtr>
  </mtable>
</math>

<p>Gecko's bug 415413 with mlabeledtr</p>
<math>
  <mtable side="left">
    <mlabeledtr>
      <mtd><mtext>LABEL</mtext></mtd>
      <mtd style="border: 1px solid black">
        <mi>f</mi><mi>f</mi><mi>f</mi><mi>f</mi><mi>f</mi><mi>f</mi><mi>f</mi><mi>f</mi><mi>f</mi><mi>f</mi>
      </mtd>
    </mlabeledtr>
  </mtable>
</math>

[fred-wang]

So here is how it looked like in v2.1:

The "ex" changes of issue386 made the widths too large:

The changes for the mlabedledtr workaround removed the width correction in general:

[fred-wang]

So I've committed a patch that restores the width correction of the math in Gecko's native MathML but removes the incorrect fix of issue #386 in that case (I guess the latter is less likely to happen than the former). However, the width may still be wrong for mtable cells so we definitely need to fix bug 415413 upstream.

I suspect that in general, each time we measure some width in native MathML (not only Gecko), this width is likely to change after Web fonts are loaded. So in particular we'd rather implement mlabeledtr upstream and remove the workaround introduced in #356 in the future (or we'll have to do ugly measure verifications on each math, which will be a performance loss for the native MathML). Having #301 to ensure correct stretching of operators is more important to me and anyway people will always be able to use Web fonts themselves.

[dpvc]

I am not able to reproduce the problem that you are seeing. With the v2.1, the v2.2, and the develop branches, I get correct results for your test file.

Your image looks like it is using the MathJax fonts, is that correct? Are they locally installed, or web-based?

[dpvc]

Sorry, I forgot to switch to MathML output (D'oh!)

[fred-wang]

They were local fonts. The result may well be system-dependent. For example I didn't see Peter's original bug without trying with a larger zoom. That may depend on default font preference of Firefox (font-family and font-size). Probably that worked on your system and so didn't see the issue when fixing the bug.

[fred-wang]

Sorry, I forgot to switch to MathML output (D'oh!)

OK :-)

[dpvc]

Here's what I've found out about the problem. It used to be that the <math> element itself had the wrong width, which is why we added the <mrow>, and that even with the <mrow> the math element didn't get the right width. The latter seems to have been fixed (at least with the test cases I've tried). So it seems that <math> now has the correct width. The problem, however, is that that width does not propagate up to the enclosing element properly (at least when that element is "shrink-wrap" element like a <td> or <mtd> or an element with display:inline-block).

The following code shows the issue:

<!DOCTYPE html>
<html>
<head>
<title>Firefox MathML size errors</title>
</head>
<body>

<p>
<span style="display:inline-block; border: 1px solid red">
  <math id="math1">
    <mrow style="border: 1px solid black">
      <mi>f</mi><mi>f</mi><mi>f</mi><mi>f</mi><mi>f</mi><mi>f</mi><mi>f</mi><mi>f</mi><mi>f</mi><mi>f</mi>
    </mrow>
  </math>
</span>
</p>

<script>
math = document.getElementById("math1");
span = math.parentNode;
mbb = math.getBoundingClientRect();
sbb = span.getBoundingClientRect();
document.write("math scrollWidth = "+math.scrollWidth+"<br>");
document.write("math clientWidth = "+math.clientWidth+" (wrong)<br>");
document.write("math bbox width = "+(mbb.right-mbb.left)+"<br>");
document.write("span scrollWidth = "+span.scrollWidth+"<br>");
document.write("span clientWidth = "+span.clientWidth+" (wrong)<br>");
document.write("span offsetWidth = "+span.offsetWidth+" (wrong)<br>");
document.write("span bbox width = "+(sbb.right-sbb.left)+" (wrong)<br>");
</script>

<p>
<math>
  <mtable>
    <mtr>
      <mtd style="border: 1px solid red">
        <mrow style="border: 1px solid black" id="math2">
          <mi>f</mi><mi>f</mi><mi>f</mi><mi>f</mi><mi>f</mi><mi>f</mi><mi>f</mi><mi>f</mi><mi>f</mi><mi>f</mi>
        </mrow>
      </mtd>
    </mtr>
  </mtable>
</math>
</p>

<script>
math = document.getElementById("math2");
mtd = math.parentNode;
mbb = math.getBoundingClientRect();
sbb = mtd.getBoundingClientRect();
document.write("math scrollWidth = "+math.scrollWidth+"<br>");
document.write("math clientWidth = "+math.clientWidth+" (wrong)<br>");
document.write("math bbox width = "+(mbb.right-mbb.left)+"<br>");
document.write("mtd scrollWidth = "+mtd.scrollWidth+"<br>");
document.write("mtd clientWidth = "+mtd.clientWidth+" (wrong)<br>");
document.write("mtd bbox width = "+(sbb.right-sbb.left)+" (wrong)<br>");
</script>

</body>
</html>

The output for me is the following:

Note that the true width of the math is 76 pixels, while the width of the containing element (<span> or <mtd>) is only 53. The container has a red border and the math has a black one. The second example shows that the same is true internally within the math, in this case the <mtd> also fails to get the width of its content correct.
This has nothing to do with MathJax, as this example doesn't load MathJax.

MathJax tries to compensate for the first error by transferring the scrollWidth of the top-level <mrow> to the <span> that contains it. MathJax doesn't currently try to adjust the width in the second case (the <mtd> one), though it does add an explicit <mrow> to overcome other problems. (Fred points this out above where he says the upstream bug needs to be fixed.)

Fred correctly points out that this correction was lost in the change for the <mlabeledtr> support. I suspect he is also right that the ex versus px change is probably the reason for the wrong amount of space being reserved for the expression. I want to look into this further, as it suggests that the determination of the ex value is wrong. This could also account for your seeing font sizes that are too big.

[dpvc]

I suspect that in general, each time we measure some width in native MathML (not only Gecko), this width is likely to change after Web fonts are loaded.

The only widths that are being measured (currently) is the size of the <mrow> inside the <math> element. And yes, you are right that if web fonts are used, that means the size could change after we have set it. That is one of my concerns about using web fonts for MathML. Since Gecko doesn't propagate the sizes of the math element properly, we have to correct the size of the container (since it is a span with display:inline-block, one of the cases that Gecko gets wrong), otherwise all the math will have the wrong amount of space, not just math that uses web fonts.

we'd rather implement mlabeledtr upstream and remove the workaround introduced in #356 in the future (or we'll have to do ugly measure verifications on each math, which will be a performance loss for the native MathML).

I'm not sure I understand the linkage between the <mlabeledtr> workaround and the measurements for the Gecko bug with wrong widths. There is no special measuring in the mlabeledtr code, so that patch is independent of setting the widths of the container spans, as far as I can tell. Yes, having <mlabeledtr> work in Gecko would be great, and I'm all for that, but I don't see how it affects the decision about setting the size of the <span> that contains the resulting <math> element. That has to be done in either case.

The only solution I can think if is the one I suggested in #301 and that you suggest above: looping through the math periodically to see if the width has changed and updating it. It is ugly, but it is not that inefficient (it is merely checking if the top-level <mrow>'s width is no longer the same size as the containing <span>'s width. Running through the math elements to check this should be reasonably fast, and if one does all the checking before making any changes, you should not get the multiple reflow problem in the situation where something has changed.

Certinaly fixing the measurement errors in Gecko is a better solution, but we have to work with the Firefox browser as it currently stands (and will still have to support some older versions even once it is fixed, at least for a while).

[fred-wang]

There are two distinct Gecko bugs here:

• clientWidth, clientHeight, offsetLeft & offsetTop values are incorrect. Boris Zbarsky says they are not supposed to be used on MathML see https://bugzilla.mozilla.org/show_bug.cgi?id=491668#c12.
• Intrinsic widths of some token elements are incorrectly computed (bug 415413). This affects the layout of elements like table cells.

[fred-wang]

since it is a span with display:inline-block, one of the cases that Gecko gets wrong),

Why do we have to put each math element in an inline-block span?

I'm not sure I understand the linkage between the workaround and the measurements for the Gecko bug with wrong widths. There is no special measuring in the mlabeledtr code, so that patch is independent of setting the widths of the container spans, as far as I can tell. Yes, having work in Gecko would be great, and I'm all for that, but I don't see how it affects the decision about setting the size of the that contains the resulting element.

I think I remember that in mlabeledtr we take the width of the parent table at some point but didn't check in details. Anyway, my point is that we should ideally not measure anything in the NativeMML code since that's a performance loss and interfere with the user's CSS. So things like #564 must be fixed now. Of course if there are bugs, we have no other choice than to workaround them and to temporarily measure sizes.

Another bug in Gecko affecting height:

• https://bugzilla.mozilla.org/show_bug.cgi?id=219873

[dpvc]

Note that we don't use any of clientWidth, clientHeight, offsetLeft, or offsetTop from MathML elements in MathJax. Never have.

I certainly don't know anything about how Gecko works internally, but it doesn't to me that this problem is about the widths of token elements. Those all seem to have the correct widths. Even the math element has the correct width. It is that that width doesn't seem to be recognize by the parent element. Unless what you are saying is that the parent element asks the math element for its width, and the math element asks the mrow, and the mrow asks the token elements, and they report something wrong, and the mrow adds up the wrong values and reports it back to the math element, and it reports back the wrong sum to the parent. In that case, I don't see how the scrollWidth and the bounding rect size can be right. But, as I said, I don't know anything about the internals of Gecko; it just seems weird.

[dpvc]

I think I remember that in mlabeledtr we take the width of the parent table at some point but didn't check in details.

There is a check to see if there is an explicit width that is a percentage, as the work around is different in that case, but no actual measuring of elements is performed.