Last Comment Bug 468578 - Crash [@ DeletingFrameSubtree] with -moz-column, pre-line, <legend>
: Crash [@ DeletingFrameSubtree] with -moz-column, pre-line, <legend>
Status: VERIFIED FIXED
: [sg:critical?] post 1.8-branch
: assertion, crash, testcase, verified1.9.0.7, verified1.9.1
Product: Core
Classification: Components
Component: Layout
: Trunk
: All All
: P3 critical (vote)
: mozilla1.9.1b3
Assigned To: David Baron [:dbaron]
: layout
:
:
: 306663 306939
  Show dependency treegraph
 
Reported: 2008-12-08 23:35 PST by Jesse Ruderman
Modified: 2009-05-26 11:55 PDT (History)
11 users (show)
roc: blocking1.9.1-
roc: wanted1.9.1+
dveditz: wanted1.9.0.x+
dveditz: wanted1.8.1.x-
jruderman: in‑testsuite+
See Also:
Crash Signature:
[@ DeletingFrameSubtree]


Attachments
testcase (539 bytes, application/xhtml+xml)
2008-12-08 23:35 PST, Jesse Ruderman
no flags Details
patch (974 bytes, patch)
2009-01-24 23:43 PST, David Baron [:dbaron]
roc: review+
roc: superreview+
roc: approval1.9.1+
dveditz: approval1.9.0.7+
Details | Diff | Splinter Review

Summon comment box

Description Jesse Ruderman 2008-12-08 23:35:49 PST
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).
Comment 1 Mats Palmgren [:mats] 2008-12-09 00:03:08 PST
> unexpected frame type

It's a LegendFrame.
Comment 2 David Baron [:dbaron] 2009-01-24 23:37:44 PST
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] 2009-01-24 23:38:27 PST
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] 2009-01-24 23:43:44 PST
Created attachment 358686 [details] [review]
patch
Comment 5 Boris Zbarsky (:bz) 2009-01-25 12:48:00 PST
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] 2009-01-29 15:52:48 PST
http://hg.mozilla.org/mozilla-central/rev/c7858cf07599

I filed bug 476063 on constructing legends by display type.
Comment 7 David Baron [:dbaron] 2009-01-31 12:59:22 PST
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/5a3a905bf67f
Comment 8 Daniel Veditz 2009-02-02 14:54:34 PST
Comment on attachment 358686 [details] [review]
patch

Approved for 1.9.0.7, a=dveditz for release-drivers.
Comment 9 David Baron [:dbaron] 2009-02-02 20:20:05 PST
Commited to CVS trunk (for 1.9.0.* releases), 2009-02-02 20:14 -0800.
Comment 10 Daniel Veditz 2009-02-12 11:52:22 PST
This problem does not happen on the 1.8 branch
Comment 11 Al Billings [:abillings] 2009-02-12 16:56:42 PST
Tomcat, you have a debug build. Can you verify this fix for 1.9.0.7?
Comment 12 David Baron [:dbaron] 2009-02-12 17:02:28 PST
(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] 2009-02-14 09:02:28 PST
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] 2009-04-16 10:50:14 PDT
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 2009-05-26 11:55:29 PDT
Added crashtest:
http://hg.mozilla.org/mozilla-central/rev/63120a5301f2

Note You need to log in before you can comment on or make changes to this bug.