math elements often don't know how high they are

REOPENED
Unassigned

Status

()

REOPENED
16 years ago
8 years ago

People

(Reporter: steve.swanson, Unassigned)

Tracking

Trunk
x86
Windows XP
Points:
---
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(6 attachments, 1 obsolete attachment)

(Reporter)

Description

16 years ago
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.
(Reporter)

Comment 1

16 years ago
Posted file testcase
(Reporter)

Comment 2

16 years ago
Posted image screenshot

Comment 3

16 years ago
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.
(Reporter)

Comment 4

15 years ago
See bug 236963 for a testcase where stretchy fences aren't stretching if 
they're directly nested in a math element.
QA Contact: ian → mathml
Following suggestion of comment 3 seems to fix the bug.
Assignee: rbs → fred.wang
Status: NEW → ASSIGNED
Attachment #424050 - Flags: review?(roc)
That patch could use a regression test, if possible...
Comment on attachment 424050 [details] [diff] [review]
Replace inline by inline-block

Yes, you should be able to write a reftest for this.
Attachment #424050 - Flags: review?(roc) → review+
Posted patch reftest (obsolete) — Splinter Review
Attachment #424210 - Flags: review?(roc)
Posted patch reftestSplinter Review
just fixing indentation...
Attachment #424210 - Attachment is obsolete: true
Attachment #424252 - Flags: review?(roc)
Attachment #424210 - Flags: review?(roc)
Comment on attachment 424252 [details] [diff] [review]
reftest

This fails before the patch, right?
Attachment #424252 - Flags: review?(roc) → review+
(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?
http://hg.mozilla.org/mozilla-central/rev/4dc8bdb7af6d
Status: ASSIGNED → RESOLVED
Last Resolved: 9 years ago
Flags: in-testsuite+
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.3a1
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
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Guessing this could be our imperfect width calculations leading to line-wrapping within inline-block elements.
(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.
Would it make sense to make <math/> nowrap?
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]).
> 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.
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...
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.
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.
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.
Assignee: fred.wang → nobody
Target Milestone: mozilla1.9.3a1 → ---
You need to log in before you can comment on or make changes to this bug.