Bugzilla@Mozilla – Bug 468578
Crash [@ DeletingFrameSubtree] with -moz-column, pre-line, <legend>
Last modified: 2009-05-26 11:55:29 PDT
Summon comment box
Created attachment 352063 [details] 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).
> unexpected frame type It's a LegendFrame.
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.
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.
Created attachment 358686 [details] [review] patch
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.
http://hg.mozilla.org/mozilla-central/rev/c7858cf07599 I filed bug 476063 on constructing legends by display type.
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/5a3a905bf67f
Comment on attachment 358686 [details] [review] patch Approved for 1.9.0.7, a=dveditz for release-drivers.
Commited to CVS trunk (for 1.9.0.* releases), 2009-02-02 20:14 -0800.
This problem does not happen on the 1.8 branch
Tomcat, you have a debug build. Can you verify this fix for 1.9.0.7?
(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.
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
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
Added crashtest: http://hg.mozilla.org/mozilla-central/rev/63120a5301f2