Closed Opened 14 years ago Closed 10 years ago

<mspace>/<mpadded> within <mtable> tags of MathML code is not rendered correctly

x86
All
Not set
normal

RESOLVED FIXED
mozilla20

Attachments

(5 files, 2 obsolete files)

 1.53 KB, application/xml Details 3.10 KB, image/png Details 253 bytes, text/xml Details 915 bytes, text/html Details 13.84 KB, patch Details | Diff | Splinter Review
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.0.3) Gecko/2008092417 Firefox/3.0.3
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.0.3) Gecko/2008092417 Firefox/3.0.3

<mtable> elements containing tags like <mspace width="0.5em" /> result in truncated tables. Bug was observed on Linux and WinXP computers with STIXfonts installed.

The attachments give an example. The first attachment contains the xhtml code while the second one shows a screenshot of the rendered equation.

Reproducible: Always

Steps to Reproduce:
Open the attached xhtml-file with Firefox.
Actual Results:
Bracket closes too far on the left.

Expected Results:
Bracket should be further on the right side.
Component: General → MathML
Product: Firefox → Core
QA Contact: general → mathml
Version: unspecified → 1.9.0 Branch
Attached file testcase
I can confirm his case. I reduced it as much as I could.

I think this is technically a regression because it rendered correctly in Firefox 2.0.0.16 (it would complain about lack of fonts though) but it seems to have been rewritten since Firefox 3.

Rules for variables inside parenthesis seemed to be added in between these trunks.

testcase broken:
2008-02-26-04-trunk

testcase gives same results as Firefox 3.0.3 & latest trunk (10-10-2008)
2008-02-27-04-trunk
Oh and I tested it on windows xp sp3

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.3) Gecko/2008092417 Firefox/3.0.3
Status: UNCONFIRMED → NEW
Ever confirmed: true
Version: 1.9.0 Branch → Trunk
I tried to check bonsai and this is what I found.

I think it points to this bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=363240

This bug is very similar to the following:
https://bugzilla.mozilla.org/show_bug.cgi?id=428906
There seems to be a general problem with bounding box size of MathMl expressions. mspace causes bounding box to be too small. mfenced causes bounding box to be too large. See the example on http://www.algebrakit.nl/ff.xhtml
Davide Cervone is trying to add a workaround in MathJax for the <mlabeledtr> bug in Gecko (and other rendering engines). He hit the present bug for <mpadded> and <mspace>.

If equations are labeled via <mlabeledtr>, then many formulas can be put in tables. In particular the use of <mspace>'s is common and things like

$$\f(n) = f(n-1) + f(n-2) \quad \text{for } n>2$$

would make the formula width badly computed and it will overlap with the label.
Summary: <mspace> within <mtable> tags of MathML code is not rendered correctly → <mspace>/<mpadded> within <mtable> tags of MathML code is not rendered correctly
Attached file another testcase
@Karl: do you know what's happening here? I think the issue is a bit different than for the width of token elements (bug 415413). Perhaps we could map mspace@width to style on the content/ side? Can using the flexbox model help (that's what Webkit folks do)?
Mapping mspace@width to style seems to fix the two testcases.
(In reply to Frédéric Wang (:fredw) from comment #10)
> @Karl: do you know what's happening here?

I'm guessing this is related to nsMathMLmspaceFrame implementing Reflow, but not Place and so nsMathMLContainerFrame's intrinsic width calculations are not taking into account the mspace element.

> I think the issue is a bit
> different than for the width of token elements (bug 415413).

Yes.

> Perhaps we could map mspace@width to style on the content/ side?

The may be the right thing to do anyway, but an AttributeChanged method may also be handling that.

> Can using the flexbox model help (that's what Webkit folks do)?

I'm not familiar with flexbox or how it is used in Webkit's MathML.
(In reply to Karl Tomlinson (:karlt) from comment #12)
> > Perhaps we could map mspace@width to style on the content/ side?
>
> The may be the right thing to do anyway, but an AttributeChanged method may
> also be handling that.

That would be better if we can fix that on the layout/ side. The fix won't work for mpadded.

> I'm guessing this is related to nsMathMLmspaceFrame implementing Reflow, but
> not Place and so nsMathMLContainerFrame's intrinsic width calculations are
> not taking into account the mspace element.
>

That's what I was just reading. However, mpadded implements Place and the bug also happens if you replace <mspace width="1em"> by <mpadded width="1em">. The only difference I see is that mpadded place its children first.

I'll try to do more testing when I have time.
Attached patch Patch V1 (obsolete) — Splinter Review
OK, the Place function of mpadded was not calling ProcessAttribute. I've implemented MeasureForWidth for mpadded and mspace and that seems to fix the testcases. Some reftest failures happened after this change, but that was due to errors in the test pages.
Assignee: nobody → fred.wang
Attachment #686060 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #686280 - Flags: review?(karlt)
Attachment #686280 - Flags: review?(karlt) → review+
Attached patch Patch V2Splinter Review
Updated patch. Just replacing

NS_IMETHODIMP

by

/* virtual */ nsresult

to prevent compilation errors on Windows.

https://tbpl.mozilla.org/?tree=Try&rev=075fc28d83f4
https://tbpl.mozilla.org/?tree=Try&rev=4904985e03b9
Attachment #686280 - Attachment is obsolete: true
Keywords: checkin-needed
https://hg.mozilla.org/integration/mozilla-inbound/rev/bb5f246f127f
Flags: in-testsuite+
Keywords: checkin-needed
https://hg.mozilla.org/mozilla-central/rev/bb5f246f127f
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla20
You need to log in before you can comment on or make changes to this bug.