Crash [@ nsMenuPopupFrame::RelayoutDirtyChild] when using display:-moz-popup

RESOLVED DUPLICATE of bug 271945

Status

()

Core
Layout
--
critical
RESOLVED DUPLICATE of bug 271945
13 years ago
6 years ago

People

(Reporter: Martijn Wargers (dead), Unassigned)

Tracking

({crash})

Trunk
x86
Windows 2000
crash
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(crash signature)

Attachments

(1 attachment)

(Reporter)

Description

13 years ago
See upcoming testcase.

Talkback data from one of the talkback ID's:
nsMenuPopupFrame::RelayoutDirtyChild 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Clobber/mozilla/layout/xul/base/src/nsMenuPopupFrame.cpp,
line 348]
nsIFrame::MarkDirtyChildren 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Clobber/mozilla/layout/xul/base/src/nsBox.cpp,
line 310]
nsFrameManager::RemoveFrame 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Clobber/mozilla/layout/base/nsFrameManager.cpp,
line 740]
nsCSSFrameConstructor::ContentRemoved 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Clobber/mozilla/layout/base/nsCSSFrameConstructor.cpp,
line 9933]
nsCSSFrameConstructor::RecreateFramesForContent 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Clobber/mozilla/layout/base/nsCSSFrameConstructor.cpp,
line 11814]
nsCSSFrameConstructor::RestyleElement 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Clobber/mozilla/layout/base/nsCSSFrameConstructor.cpp,
line 10402]
nsCSSFrameConstructor::ProcessPendingRestyles 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Clobber/mozilla/layout/base/nsCSSFrameConstructor.cpp,
line 13819]
nsCSSFrameConstructor::RestyleEvent::HandleEvent 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Clobber/mozilla/layout/base/nsCSSFrameConstructor.cpp,
line 13883]
SETUPAPI.DLL + 0x30c24 (0x778b0c24)
(Reporter)

Comment 1

13 years ago
Created attachment 172439 [details]
Testcase

Testcase crashes almost every time for me on hovering the text. If it doesn't
do it directly try a refresh and hover again.
Summary: Crash [@ nsMenuPopupFrame::RelayoutDirtyChild] when using display:-moz-popup → Crash [@
I swear I didn't touch the summary; restoring.  Sigh.
Summary: Crash [@ → Crash [@ nsMenuPopupFrame::RelayoutDirtyChild] when using display:-moz-popup
I get a nice slew of assertions here....  In particular:

###!!! ASSERTION: unexpected null pointer: 'rootBox', file
/home/bzbarsky/mozilla/xlib/mozilla/layout/base/nsCSSFrameConstructor.cpp, line 6169
###!!! ASSERTION: unknown out of flow frame type: 'NS_STYLE_FLOAT_NONE !=
disp->mFloats', file
/home/bzbarsky/mozilla/xlib/mozilla/layout/generic/nsHTMLReflowState.cpp, line 415
###!!! ASSERTION: This hack should not be needed now!!! See bug 126263.:
'Error', file
/home/bzbarsky/mozilla/xlib/mozilla/layout/generic/nsContainerFrame.cpp, line 454

These happen because:

1) display:-moz-popup assumes that the root frame for the presshell is a box.
   If it's not, it places the placeholder in the in-flow list and just drops the
   out-of-flow on the floor.
2) If the placeholder is in the in-flow kids of a block, it ends up in
   nsLineLayout::ReflowFrame, which ends up in
   nsLayoutUtils::GetFloatFromPlaceholder, which thinks all non-positioned
   out-of-flows are floats (popups are not!).  So we end up trying to
   nsHTMLReflowState the popup, and the reflow state makes the same basic
   assumption.
3) Not sure, but the view for the popup is pretty messed up to start with,
   so....

The actual crash is happening, according to gdb, because we call
CallQueryInterface on a null nsIBox, but it claims we do so from
nsMenuPopupFrame::RelayoutDirtyChild via NeedsRecalc, which seems unlikely...

So how do we deal with this?  I guess we can:

1)  Fix nsLayoutUtils to check for float before returning something it claims is
    a float.
2)  Fix -moz-popup construction to bail out completely if the root is not a box
    (not insert a placeholder).

Both would be needed to get anywhere here, I think....

Comment 4

13 years ago
My checkin for bug 271945 replaces the crash with yet another assertion...
(Reporter)

Comment 5

13 years ago
Ok, this doesn't crash anymore in a 20050203 trunk build, so this can be
resolved FIXED then or resolved DUPLICATE of bug 271945?

*** This bug has been marked as a duplicate of 271945 ***
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → DUPLICATE
(Assignee)

Updated

6 years ago
Crash Signature: [@ nsMenuPopupFrame::RelayoutDirtyChild]
You need to log in before you can comment on or make changes to this bug.