Closed Bug 468578 Opened 13 years ago Closed 13 years ago

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

Categories

(Core :: Layout, defect, P3)

defect

Tracking

()

VERIFIED FIXED
mozilla1.9.1b3

People

(Reporter: jruderman, Assigned: dbaron)

References

(Blocks 2 open bugs)

Details

(5 keywords, Whiteboard: [sg:critical?] post 1.8-branch)

Crash Data

Attachments

(2 files)

Attached file 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).
Flags: blocking1.9.1?
Whiteboard: [sg:critical?]
> unexpected frame type

It's a LegendFrame.
Assignee: nobody → mats.palmgren
OS: Mac OS X → All
Hardware: PC → All
Flags: blocking1.9.1? → blocking1.9.1+
Priority: -- → P3
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.
Attached patch patchSplinter Review
Assignee: mats.palmgren → dbaron
Status: NEW → ASSIGNED
Attachment #358686 - Flags: superreview?(roc)
Attachment #358686 - Flags: review?(roc)
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.
Attachment #358686 - Flags: superreview?(roc)
Attachment #358686 - Flags: superreview+
Attachment #358686 - Flags: review?(roc)
Attachment #358686 - Flags: review+
Flags: wanted1.9.1+
Flags: blocking1.9.1-
Flags: blocking1.9.1+
http://hg.mozilla.org/mozilla-central/rev/c7858cf07599

I filed bug 476063 on constructing legends by display type.
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Flags: in-testsuite?
Resolution: --- → FIXED
Whiteboard: [sg:critical?] → [sg:critical?][needs 1.9.1 landing][needs 1.9.0.* landing]
Target Milestone: --- → mozilla1.9.2a1
Attachment #358686 - Flags: approval1.9.1?
Attachment #358686 - Flags: approval1.9.1? → approval1.9.1+
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/5a3a905bf67f
Keywords: fixed1.9.1
Whiteboard: [sg:critical?][needs 1.9.1 landing][needs 1.9.0.* landing] → [sg:critical?][needs 1.9.0.* landing]
Target Milestone: mozilla1.9.2a1 → mozilla1.9.1b3
Attachment #358686 - Flags: approval1.9.0.7?
Flags: wanted1.9.0.x+
Comment on attachment 358686 [details] [diff] [review]
patch

Approved for 1.9.0.7, a=dveditz for release-drivers.
Attachment #358686 - Flags: approval1.9.0.7? → approval1.9.0.7+
Commited to CVS trunk (for 1.9.0.* releases), 2009-02-02 20:14 -0800.
Keywords: fixed1.9.0.7
Whiteboard: [sg:critical?][needs 1.9.0.* landing] → [sg:critical?]
This problem does not happen on the 1.8 branch
Flags: wanted1.8.1.x-
Whiteboard: [sg:critical?] → [sg:critical?] post 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.
Whiteboard: [sg:critical?] post 1.8-branch → [sg:critical?]
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
Whiteboard: [sg:critical?] → [sg:critical?] post 1.8-branch
Group: core-security
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
Status: RESOLVED → VERIFIED
Added crashtest:
http://hg.mozilla.org/mozilla-central/rev/63120a5301f2
Flags: in-testsuite? → in-testsuite+
Crash Signature: [@ DeletingFrameSubtree]
You need to log in before you can comment on or make changes to this bug.