304369 - Reflow assertions when viewing e-mail messages

Status: NEW

(Core :: Layout, defect)

Description

[Scott MacGregor]

I've been seeing this in my debug build for at least 3 or 4 days now. Whenever I
read an e-mail message, I get multiple assertions in nsBlockFrame::Reflow:

  // Now reflow...
  rv = ReflowDirtyLines(state, PR_TRUE);
  NS_ASSERTION(NS_SUCCEEDED(rv), "reflow dirty lines failed");

nsDebug::Assertion(const char * 0x021760e0, const char * 0x021760cc, const char
* 0x02176090, int 877) line 109
nsBlockFrame::Reflow(nsBlockFrame * const 0x06235bd4, nsPresContext *
0x061cff80, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...},
unsigned int & 0) line 877 + 38 bytes
nsBlockReflowContext::ReflowBlock(const nsRect & {...}, int 1,
nsCollapsingMargin & {...}, int 0, int 1, nsMargin & {...}, nsHTMLReflowState &
{...}, unsigned int & 0) line 605 + 42 bytes
nsBlockFrame::ReflowBlockFrame(nsBlockReflowState & {...}, nsLineList_iterator
{...}, int * 0x0012cf48) line 3410 + 66 bytes
nsBlockFrame::ReflowLine(nsBlockReflowState & {...}, nsLineList_iterator {...},
int * 0x0012cf48, int 1) line 2571 + 27 bytes
nsBlockFrame::ReflowDirtyLines(nsBlockReflowState & {...}, int 1) line 2239 + 31
bytes
nsBlockFrame::Reflow(nsBlockFrame * const 0x06235a5c, nsPresContext *
0x061cff80, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...},
unsigned int & 0) line 876 + 17 bytes
nsContainerFrame::ReflowChild(nsIFrame * 0x06235a5c, nsPresContext * 0x061cff80,
nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, int 0, int 0,
unsigned int 0, unsigned int & 0) line 899 + 31 bytes
CanvasFrame::Reflow(CanvasFrame * const 0x06210640, nsPresContext * 0x061cff80,
nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, unsigned int & 0)
line 522
nsContainerFrame::ReflowChild(nsIFrame * 0x06210640, nsPresContext * 0x061cff80,
nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, int 0, int 0,
unsigned int 3, unsigned int & 0) line 899 + 31 bytes
nsHTMLScrollFrame::ReflowScrolledFrame(const ScrollReflowState & {...}, int 0,
nsHTMLReflowMetrics * 0x0012d7ec, int 0) line 508 + 54 bytes
nsHTMLScrollFrame::ReflowContents(ScrollReflowState * 0x0012d95c, const
nsHTMLReflowMetrics & {...}) line 595 + 25 bytes
nsHTMLScrollFrame::Reflow(nsHTMLScrollFrame * const 0x06210784, nsPresContext *
0x061cff80, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...},
unsigned int & 0) line 753 + 16 bytes
nsContainerFrame::ReflowChild(nsIFrame * 0x06210784, nsPresContext * 0x061cff80,
nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, int 0, int 0,
unsigned int 0, unsigned int & 0) line 899 + 31 bytes
ViewportFrame::Reflow(ViewportFrame * const 0x062105b0, nsPresContext *
0x061cff80, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...},
unsigned int & 0) line 239 + 43 bytes
PresShell::ResizeReflow(PresShell * const 0x0299dad8, int 13920, int 3360) line 3014
PresShell::ResizeReflow(PresShell * const 0x0299db4c, nsIView * 0x061e2298, int
13920, int 3360) line 6471
nsViewManager::DoSetWindowDimensions(int 13920, int 3360) line 420
nsViewManager::SetWindowDimensions(nsViewManager * const 0x061e21e0, int 13920,
int 3360) line 695
nsViewManager::DispatchEvent(nsViewManager * const 0x061e21e0, nsGUIEvent *
0x0012dfe4, nsEventStatus * 0x0012df38) line 1954
HandleEvent(nsGUIEvent * 0x0012dfe4) line 174

Comment 1

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

This is bad, and generally means some descendant's reflow method return a
failure nsresult, which we propagate.  Reflow methods should really only do that
in exceptional situations (e.g., out of memory).

Comment 2

[Scott MacGregor]

If you need an example that will generate this reflow assertion, just read any
old bugzilla e-mail in Thunderbird or the suite. They all generate the
assertions for me.

Comment 3

[Boris Zbarsky [:bzbarsky]]

So I only see this when switching folders in mailnews.  When this happens, we
bail out of reflowing a textframe because the current document of its mContent
is null.  The stack that gets us into reflow is:

#22 0xb6474aec in PresShell::ResizeReflow (this=0x8944470, aView=0x8b87c58, 
    aWidth=11382, aHeight=5012) at ../../../mozilla/layout/base/nsPresShell.cpp:6322
#23 0xb68932ad in nsViewManager::DoSetWindowDimensions (this=0x8ac2438,
aWidth=11382, 
    aHeight=5012) at ../../../mozilla/view/src/nsViewManager.h:418
#24 0xb68884f6 in nsViewManager::SetWindowDimensions (this=0x8ac2438, aWidth=11382, 
    aHeight=5012) at ../../../mozilla/view/src/nsViewManager.cpp:694
#25 0xb688bd02 in nsViewManager::DispatchEvent (this=0x8ac2438, aEvent=0xbfffd990, 
    aStatus=0xbfffd880) at ../../../mozilla/view/src/nsViewManager.cpp:1952
#26 0xb688154c in HandleEvent (aEvent=0xbfffd990)
    at ../../../mozilla/view/src/nsView.cpp:171
#27 0xb5e1f987 in nsWidget::DispatchEvent (this=0x86ec110, aEvent=0xbfffd990, 
    aStatus=@0xbfffd940) at ../../../../mozilla/widget/src/gtk/nsWidget.cpp:1558
#28 0xb5e1f5d1 in nsWidget::DispatchWindowEvent (this=0x86ec110, event=0xbfffd990)
    at ../../../../mozilla/widget/src/gtk/nsWidget.cpp:1447
#29 0xb5e1dbb3 in nsWidget::OnResize (this=0x86ec110, event=0xbfffd990)
    at ../../../../mozilla/widget/src/gtk/nsWidget.cpp:675

with the resize coming from nsSubDocumentFrame::Reflow in the parent document,
which calls nsDocShell::SetPositionAndSize.  At the point when we hit
ResizeReflow in the presshell, we have:

(gdb) p mDocument->GetRootContent()->GetCurrentDoc()
$15 = (class nsIDocument *) 0x0
(gdb) p ((class nsHTMLDocument*)mDocument)->mScriptGlobalObject
$18 = {mRawPtr = 0x0}

So it looks like the document there is already dead, but we haven't torn down
the presshell for some reason...

Comment 4

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Would fixing PresShell::IsVisible to reflect what fastback does fix this?

Comment 5

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Also, when this is fixed, the change in the balsa/Firefox tree should probably
be uncommented.  (This assertion is commented out so I could make assertions
fatal on that tinderbox.)

Comment 6

[Boris Zbarsky [:bzbarsky]]

(In reply to comment #4)
> Would fixing PresShell::IsVisible to reflect what fastback does fix this?

Maybe... Worth trying, at least.