468578 - Crash [@ DeletingFrameSubtree] with -moz-column, pre-line, <legend>

Status: VERIFIED FIXED

(Core :: Layout, defect, P3)

Description

[Jesse Ruderman]

Attachment: testcase

###!!! ASSERTION: unexpected frame type: 'Not Reached', file layout/base/nsCSSFrameConstructor.cpp, line 10583

###!!! ASSERTION: reflow dirty lines failed: 'NS_SUCCEEDED(rv)', file layout/generic/nsBlockFrame.cpp, line 955

###!!! ASSERTION: out-of-flow on wrong child list: '!(childFrame->GetStateBits() & NS_FRAME_OUT_OF_FLOW)', file layout/base/nsCSSFrameConstructor.cpp, line 9221

Crash [@ DeletingFrameSubtree] (calling 0xdddddddd, or calling DoDeletingFrameSubtree, which then dereferences null).

Comment 1

[Mats Palmgren (inactive)]

> unexpected frame type

It's a LegendFrame.

Comment 2

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

Maybe what we should do here is only construct nsLegendFrames when the legend is in a fieldset, and otherwise just handle them by display type.  (Not sure how to deal with legends that aren't the first child, or multiple legends, though.)  We'd need to make sure legend is display:block in html.css in that case, though.

Comment 3

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

Then again, we should probably do that as a followup bug; nsLegendFrame is very similar to nsBlockFrame so we should just be able to add to CreateContinuingFrame.

Comment 4

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

Attachment: patch

Comment 5

[Boris Zbarsky [:bzbarsky]]

We could certainly construct legends by display if the parent content is not a fieldset, sure.  That would make a lot of sense to me.

Legends that are not a first child of the fieldset we currently treat as "the" legend, and need to for web compat, iirc.

Multiple legends is tough if we ever continue kids of fieldsets; for that we need this continuingframe change.

Comment 6

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

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

I filed bug 476063 on constructing legends by display type.

Comment 7

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

http://hg.mozilla.org/releases/mozilla-1.9.1/rev/5a3a905bf67f

Comment 8

[Daniel Veditz [:dveditz]]

Comment on attachment 358686 [details] [diff] [review]
patch

Approved for 1.9.0.7, a=dveditz for release-drivers.

Comment 9

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

Commited to CVS trunk (for 1.9.0.* releases), 2009-02-02 20:14 -0800.

Comment 10

[Daniel Veditz [:dveditz]]

This problem does not happen on the 1.8 branch

Comment 11

[Al Billings [:abillings - ex-MoCo]]

Tomcat, you have a debug build. Can you verify this fix for 1.9.0.7?

Comment 12

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

(In reply to comment #10)
> This problem does not happen on the 1.8 branch

That's probably just an artifact of the testcase; the problematic code is there:  nsLegendFrame::GetType is implemented and CreateContinuingFrame doesn't deal with it.

Comment 13

[Carsten Book [:Tomcat]]

verified fixed 1.9.07 using Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.7pre) Gecko/2009021407 Firefox/3.0.7pre and the testcase - no crash on testcase

Comment 14

[Aakash Desai [:aakashd]]

verified FIXED on builds: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090415 Minefield/3.6a1pre ID:20090415030845

and

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b4pre) Gecko/20090416 Shiretoko/3.5b4pre ID:20090416030924

Comment 15

[Jesse Ruderman]

Added crashtest:
http://hg.mozilla.org/mozilla-central/rev/63120a5301f2