675552 - "ASSERTION: unexpected block frame" with MathML, text-overflow

Status: NEW

(Core :: Layout: Text and Fonts, defect)

Description

[Jesse Ruderman]

Attachment: testcase

###!!! ASSERTION: unexpected block frame: '!nsLayoutUtils::GetAsBlock(aFrame) || !aFrame->GetStyleDisplay()->IsBlockOutside()', file layout/generic/TextOverflow.cpp

Comment 1

[Mats Palmgren (inactive)]

There's a couple of assertions leading up to that:

###!!! ASSERTION: How'd we get a floated inline frame? The frame ctor should've dealt with this.: 'aReflowState.mStyleDisplay->mFloats == NS_STYLE_FLOAT_NONE', file layout/generic/nsLineLayout.cpp, line 1092
###!!! ASSERTION: How'd we get a floated inline frame? The frame ctor should've dealt with this.: 'isText || reflowStateHolder.ref().mStyleDisplay->mFloats == NS_STYLE_FLOAT_NONE', file layout/generic/nsLineLayout.cpp, line 1019

Comment 2

[Mats Palmgren (inactive)]

Attachment: Testcase #2

<math><div/></math> triggers just the "unexpected block frame" assertion and not the float related ones in comment 1.

Comment 3

[Boris Zbarsky [:bzbarsky]]

The float assertions there are bogus when MathML is involved, as things stand....

Comment 4

[Mats Palmgren (inactive)]

Attachment: Frame tree for Testcase #2

Hmm, this frame tree looks weird to me, why does the line have "state=inline"
and why is there no -moz-mathml-anonymous-block frame?

Comment 5

[Mats Palmgren (inactive)]

Attachment: Testcase #3

Comment 6

[Mats Palmgren (inactive)]

Attachment: Frame tree for Testcase #3

Comment 7

[Mats Palmgren (inactive)]

Attachment: fix

Is the attached frame trees what we want them to be?
If so, then we need to ignore block child frames.

Comment 8

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

The inline math frames containing blocks look wrong to me. Why aren't they being converted to anonymous blocks?

Comment 9

[Mats Palmgren (inactive)]

Because 'wrapFrame' is false for the block, so it's added as is to 'newItems':
http://mxr.mozilla.org/mozilla-central/source/layout/base/nsCSSFrameConstructor.cpp#3779

Comment 10

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

Yeah, but it seems to me that it would make more sense for inline <math> elements to participate in IB-splitting like other inline elements do.

Comment 11

[Boris Zbarsky [:bzbarsky]]

We could try to do that; would the math frame be able to deal?

Comment 12

[Ryan VanderMeulen [:RyanVM]]

Testcases #1 & #2 still assert on trunk. Testcase #3 no longer does (at least on linux64).

Comment 13

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee is inactive on Bugzilla, so the assignee is being reset.