219873 - math elements often don't know how high they are

Status: REOPENED

(Core :: MathML, defect)

Description

[steve.swanson]

Using CSS, I gave a dotted border to the <math> elements in the testcase. The 
width seems to always be OK, but the height is often wrong.  Particularly bad 
are <mtable>s.

Comment 1

[steve.swanson]

Attachment: testcase

Comment 2

[steve.swanson]

Attachment: screenshot

Comment 3

[rbs]

The behavior comes from the fact that <math> is treated as an "inline CSS box",
i.e., its height is the height of the "font box" per CSS, which is rather
non-intuitive if your are not familiar with CSS. By treating it as an
inline-block (when this is supported in Gecko), its height will be what you expect.

Comment 4

[steve.swanson]

See bug 236963 for a testcase where stretchy fences aren't stretching if 
they're directly nested in a math element.

Comment 5

[Frédéric Wang (:fredw)]

Attachment: Replace inline by inline-block

Following suggestion of comment 3 seems to fix the bug.

Comment 6

[Boris Zbarsky [:bzbarsky]]

That patch could use a regression test, if possible...

Comment 7

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 424050 [details] [diff] [review]
Replace inline by inline-block

Yes, you should be able to write a reftest for this.

Comment 8

[Frédéric Wang (:fredw)]

Attachment: reftest

Comment 9

[Frédéric Wang (:fredw)]

Attachment: reftest

just fixing indentation...

Comment 10

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 424252 [details] [diff] [review]
reftest

This fails before the patch, right?

Comment 11

[Frédéric Wang (:fredw)]

(In reply to comment #10)
> (From update of attachment 424252 [details] [diff] [review])
> This fails before the patch, right?

Yes, and applying the patch allows to pass the test.

Does attachment 424050 [details] [diff] [review] needs a superreview?

Comment 12

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(In reply to comment #11)
> Does attachment 424050 [details] [diff] [review] needs a superreview?

No.

Comment 13

[Karl Tomlinson (:karlt)]

http://hg.mozilla.org/mozilla-central/rev/4dc8bdb7af6d

Comment 14

[Karl Tomlinson (:karlt)]

I had to back this out do to a reftest failures

REFTEST TEST-UNEXPECTED-FAIL | file:///builds/moz2_slave/mozilla-central-linux-debug-unittest-reftest/build/reftest/tests/layout/reftests/bugs/355548-2.xml
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1265091803.1265094429.16200.gz#err0

REFTEST TEST-UNEXPECTED-FAIL | file:///e:/builds/moz2_slave/mozilla-central-win32-debug-unittest-reftest/build/reftest/tests/layout/reftests/bugs/355548-3.xml
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1265093180.1265094865.20958.gz#err0

http://hg.mozilla.org/mozilla-central/rev/a8d05daa3192

Comment 15

[Karl Tomlinson (:karlt)]

Guessing this could be our imperfect width calculations leading to line-wrapping within inline-block elements.

Comment 16

[Frédéric Wang (:fredw)]

(In reply to comment #15)
> Guessing this could be our imperfect width calculations leading to
> line-wrapping within inline-block elements.

Yes, the reftests you mentions do not fail on my computer but I've been able to write a test where I can see a line-wrap. Also, in attachment 131840 [details], it seems that the bounding box of some <math/> elements is too wide / not wide enough.

Comment 17

[Boris Zbarsky [:bzbarsky]]

Would it make sense to make <math/> nowrap?

Comment 18

[Frédéric Wang (:fredw)]

Attachment: testcase width

Comment 19

[Frédéric Wang (:fredw)]

Attachment: reftests width

Comment 20

[Frédéric Wang (:fredw)]

The MathML spec allows linebreaking. But in Mozilla, it is currently only possible at the <math/> level, not deeper in the formula tree. Moreover, one can not force a newline, so I don't know whether people really use this feature.

Anyway, adding nowrap would not solve the problem of width computation. Attachment 424952 [details] [diff] adds two reftests for the math width, showing that the bug is already present and not fixed by the patch. However, setting math inline-block makes the bug a lot more visible (attachment 424951 [details]).

Comment 21

[Boris Zbarsky [:bzbarsky]]

> The MathML spec allows linebreaking. 

Er... in that case inline-block is the wrong thing to use, no?  If I have this markup:

  This is some equation: <math>x + 2 = 5</math>.

and it needs to line-break after the "2" due to lack of space, then the desired rendering is:

  This is some equation: x + 2
  = 5.

whereas with inline-block you would get:

                         x + 2
  This is some equation: = 5

or so, depending on the exact markup.  Or possibly you'd have a blank line after the "= 5" instead of text continuing after it.

Comment 22

[Frédéric Wang (:fredw)]

OK, so actually such kind of linebreaking is often used in inline math. But I've no idea about how to fix the bug with the height of <math/> element...

Comment 23

[Boris Zbarsky [:bzbarsky]]

You have to effectively create a new CSS box type for it.  CSS does not have a box type that behaves in the way that seems to be desired here.

Comment 24

[Robert O'Callahan (:roc) (email my personal email if necessary)]

We don't support line-breaking of MathML content currently. So I'd be happy to take the inline-block patch if it fixed the bug and didn't cause any regressions.

Comment 25

[Frédéric Wang (:fredw)]

Linebreaking occurs in Boris' example with

<math><mi>x</mi><mo>+</mo><mn>2</mn><mo>=</mo><mn>5</mn></math>

but not with

<math><mrow><mi>x</mi><mo>+</mo><mn>2</mn><mo>=</mo><mn>5</mn></mrow></math>.

In the former case, we currently have the first result of comment 21. If we apply the patch, then either we will have the second result of of comment 21, or - if we use "nowrap" - no linebreaking at all.

More annoying is Attachment 424951 [details]: it renders correctly without the patch, but we get an overlap and a gap if block-inline is used.

I don't think the patch should be taken.

Comment 26

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I stand corrected!