336718 - [FIX]Crash [@ nsSubDocumentFrame::Reflow] with evil testcase, using ::before, ::after and display: table-row a lot

Status: VERIFIED FIXED

(Core :: Layout, defect, P2)

Description

[Martijn Wargers (dead)]

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?

Comment 1

[Martijn Wargers (dead)]

Attachment: testcase, crashes on load

Comment 2

[Martijn Wargers (dead)]

Attachment: 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

Comment 3

[Boris Zbarsky [:bzbarsky]]

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?

Comment 4

[Bernd]

sure we have, see the patch in bug 162063

Comment 5

[Boris Zbarsky [:bzbarsky]]

Attachment: 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).

Comment 6

[Olli Pettay [:smaug][[e-mail]]]

@ nsSubDocumentFrame::Reflow is nowadays a trunk topcrasher.

Comment 7

[Robert O'Callahan (:roc) (email my personal email if necessary)]

You may want to add a comment for posterity, noting that "overshooting" and reframing more than we need to is safe.

Comment 8

[Boris Zbarsky [:bzbarsky]]

Checked in, with a comment to that effect.

Comment 9

[Stephen Donner [:stephend] Not actively reading bugmail]

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.