See upcoming testcase, which crashes current trunk Mozilla builds. (unfortunately, not too minimised) Doesn't crash in 2006-04-10 build, crashes in 2006-04-11 build: http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2006-04-10+11&maxdate=2006-04-11+07&cvsroot=%2Fcvsroot The only thing that could have caused this, seems to me bug 332927. Talkback ID: TB18324960W nsSubDocumentFrame::Reflow nsLineLayout::ReflowFrame Maybe this gets 'automatically' fixed by the reflow branch?
Created attachment 220906 [details] Backtrace from debug build Prior to the crash, I get this assertion (stack included): ###!!! ASSERTION: DeletingFrameSubtree on a special frame. Prepare to crash.: ' !IsFrameSpecial(aFrame)', file c:/mozilla/mozilla/layout/base/nsCSSFrameConstruc tor.cpp, line 9845 And then the crash: #0 0x059f0c6e in nsIView::GetViewManager() const (this=0x0) at ../../../../dist/include/view/nsIView.h:144 #1 0x0536331f in nsSubDocumentFrame::Reflow(nsPresContext*, nsHTMLReflowMetrics &, nsHTMLReflowState const&, unsigned&) (this=0x101aceb0, aPresContext=0x1013b308, aDesiredSize=@0x22c1f8, aReflowState=@0x22c248, aStatus=@0x22c3c0) at c:/mozilla/mozilla/layout/generic/nsFrameFrame.cpp:392 #2 0x05395653 in nsLineLayout::ReflowFrame(nsIFrame*, unsigned&, nsHTMLReflowMe trics*, int&) (this=0x22c4a8, aFrame=0x101aceb0, aReflowStatus=@0x22c3c0, aMetrics=0x0, aPushedFrame=@0x22c3bc) at c:/mozilla/mozilla/layout/generic/nsLineLayout.cpp:996
So the problem is that in nsCSSFrameConstructor::WipeContainingBlock we end up finding the block inside the pseudo table-cell. We want to keep going up through the table pseudos until we find an honest block. Possibly just fixing this loop condition: while (IsFrameSpecial(aContainingBlock)) aContainingBlock = aContainingBlock->GetParent(); would work. Bernd, do we have a way to detect table pseudo-frames?
sure we have, see the patch in bug 162063
Created attachment 220946 [details] [diff] [review] Proposed patch OK, I think the right thing to do here is to walk out of all pseudos, not just table pseudos. Safer that way, esp. if we ever start supporting things like positioned anonymous content (which could then be block-level even if the parent is inline).
OS: Windows XP → All
Priority: -- → P2
Hardware: PC → All
Summary: Crash with evil testcase, using ::before, ::after and display: table-row a lot → [FIX]Crash with evil testcase, using ::before, ::after and display: table-row a lot
Target Milestone: --- → mozilla1.9alpha
Summary: [FIX]Crash with evil testcase, using ::before, ::after and display: table-row a lot → [FIX]Crash [@ nsSubDocumentFrame::Reflow] with evil testcase, using ::before, ::after and display: table-row a lot
@ nsSubDocumentFrame::Reflow is nowadays a trunk topcrasher.
You may want to add a comment for posterity, noting that "overshooting" and reframing more than we need to is safe.
Checked in, with a comment to that effect.
Status: ASSIGNED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED
Verified FIXED using 2006-11-13-09 of SeaMonkey trunk under Windows XP on the testcase: https://bugzilla.mozilla.org/attachment.cgi?id=220905. No crash.
Status: RESOLVED → VERIFIED
Crash Signature: [@ nsSubDocumentFrame::Reflow]
You need to log in before you can comment on or make changes to this bug.