400207 - incorrect widths make non-stretchy MathML frames invisible

Status: RESOLVED FIXED

(Core :: MathML, defect, P1)

Description

[Karl Tomlinson (:karlt)]

nsMathMLContainerFrame::Reflow(), nsMathMLTokenFrame::Reflow() and others use aReflowState.ComputedWidth() to set availSize.width for their children.
The computed width (for the non-block frame) is calculated from GetPrefWidth() (during shrink wrapping) which is not implemented specially for MathML frames so the default nsFrame method returns 0.

Using availableSize.availableWidth will probably work fine for non-block child frames, but block child frames will use all the available width, and so the available width for block child frames probably needs to be calculated from GetPrefWidth().  Implementing GetPrefWidth() for the MathML frames may be another way to solve the problem.

Comment 1

[Vlad Sukhoy]

Fixing this would be helpful for people who are working on symbolic font so that they can use the latest trunk..

Comment 2

[Karl Tomlinson (:karlt)]

Attachment: wip - implement nsMathMLContainerFrame::GetPrefWidth using nsContainerFrame::DoInlineIntrinsicWidth

This is just experimenting really, but it makes the frames visible even if their heights (or ascents) are not right.

Comment 3

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

So, based on discussions I had with rbs, I don't think MathML needs to implement the inline intrinsic width stuff since it never breaks -- I think it just needs GetPrefWidth and GetMinWidth (and they'll always return the same thing).

Comment 4

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

(Although maybe the breaking behavior at the edges of MathML is different from the breaking behavior of images, etc., in which case it would need to implement at least a simple AddInline*.)

Comment 5

[Karl Tomlinson (:karlt)]

Attachment: implement nsMathMLContainerFrame::GetPrefWidth using nsLayoutUtils::IntrinsicForContainer

This is a small start that makes a big difference, but there are still a few things to consider:

* Some derived classes may need their own GetIntrinsicWidth.
* Maybe GetPreferredStretchSize should be included here.
* Is the distance between frames zero?

Comment 6

[Karl Tomlinson (:karlt)]

Attachment: make -moz-mathml-anonymous-block "display: inline-block" [checked-in]

-moz-mathml-anonymous-block is used in two cases:
1) inside an mrow wrapping an mtable to make it behave like an inline-table.
   (We can probably get rid of this and use inline-tables now.)
2) inside mathml frames to wrap non-mathml content that may line-break.

In both cases the surrounding context is really inline rather than block (but
the parent frames don't know about line-breaking).
The "inline-block" value for the "display" style property of
-moz-mathml-anonymous-block therefore seems more appropriate than "block".

inline-block causes nsHTMLReflowState to shrink-wrap in frame->ComputeSize(),
which is what we want.

David, are there any problems with using "display: inline-block" instead of
"block"?  If so, I guess "width: -moz-fit-content" could be used instead?

(We should still implement GetPrefWidth/GetMinWidth so that the available width
for the child frames is reasonable instead of 0, and for tables.  But these
are going to be more complicated than indicated in comment 5.  Child text
frames happen to behave well with the inline-block change, even with 0 available width, because the text frames don't usually contain line break opportunities.)

Comment 7

[Boris Zbarsky [:bzbarsky]]

> 1) inside an mrow wrapping an mtable to make it behave like an inline-table.
>   (We can probably get rid of this and use inline-tables now.)

Yes, please!  We have bugs on that!

I agree that inline-block makes sense for this block.

Comment 8

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

Comment on attachment 290336 [details] [diff] [review]
make -moz-mathml-anonymous-block "display: inline-block" [checked-in]

This seems fine, so r=dbaron.  Although width:-moz-fit-content might make it clearer why it's being done.

Why is it not temporary anymore?

Comment 9

[Karl Tomlinson (:karlt)]

(In reply to comment #8)
> Although width:-moz-fit-content might make it clearer why it's being done.

inline-block seems the right thing anyway.  I'll add the following comment:  "This is used when wrapping non-MathML inline elements inside math."

> Why is it not temporary anymore?

Case 1 in comment 6 is temporary (bug 348577), but case 2 is still going to be necessary to wrap frames that require an nsLineLayout.

Comment 10

[Karl Tomlinson (:karlt)]

Comment on attachment 290336 [details] [diff] [review]
make -moz-mathml-anonymous-block "display: inline-block" [checked-in]

Checked in with comment.

Comment 11

[Karl Tomlinson (:karlt)]

That fixes this bug for everything except <mtable>, which is bug 363240.
GetPrefWidth/GetMinWidth can be done in that bug, which will make the available widths large enough.

(Ascents are still incorrect - bug 401178.
 Overflow rectangles are still not set correctly so some parts of glyphs
 disappear at various times - bug 161155 and bug 335405 I guess.)