207621 - Huh, event content left on the stack in pres shell dtor!: 'mCurrentEventContentStack.Count() == 0'

Status: NEW

(Core :: Layout, defect, P5)

Description

[timeless]

see also bug 94577

debug build, source tree from pre 1.4 freeze
###!!! ASSERTION: Huh, event content left on the stack in pres shell dtor!:
'mCurrentEventContentStack.Count() == 0', file
i:/build/mozilla/layout/html/base/src/nsPresShell.cpp, line 1613

nsDebug::Assertion(const char * 0x04431c44, const char * 0x04431c1c, const char
* 0x04431be4, int 1613) line 270 + 13 bytes
PresShell::~PresShell() line 1613 + 42 bytes
PresShell::`scalar deleting destructor'() + 15 bytes
PresShell::Release(PresShell * const 0x0b65b8f0) line 1560 + 186 bytes
nsCOMPtr<nsIPresShell>::assign_assuming_AddRef(nsIPresShell * 0x00000000) line 479
nsCOMPtr<nsIPresShell>::assign_with_AddRef(nsISupports * 0x00000000) line 981
nsCOMPtr<nsIPresShell>::operator=(nsIPresShell * 0x00000000) line 592
DocumentViewerImpl::Destroy(DocumentViewerImpl * const 0x0b657708) line 1136
DocumentViewerImpl::Show(DocumentViewerImpl * const 0x0b61af90) line 1368
PresShell::UnsuppressAndInvalidate() line 4946
PresShell::UnsuppressPainting(PresShell * const 0x0b617c78) line 4992
DocumentViewerImpl::LoadComplete(DocumentViewerImpl * const 0x0b61af90, unsigned
int 0) line 960
nsDocShell::EndPageLoad(nsIWebProgress * 0x0b608dc4, nsIChannel * 0x0b71ab20,
unsigned int 0) line 4373
nsWebShell::EndPageLoad(nsIWebProgress * 0x0b608dc4, nsIChannel * 0x0b71ab20,
unsigned int 0) line 879
nsDocShell::OnStateChange(nsDocShell * const 0x0b608bb4, nsIWebProgress *
0x0b608dc4, nsIRequest * 0x0b71ab20, unsigned int 131088, unsigned int 0) line 4305
nsDocLoaderImpl::FireOnStateChange(nsIWebProgress * 0x0b608dc4, nsIRequest *
0x0b71ab20, int 131088, unsigned int 0) line 1228

mCount is 1. steps were something like:
1. run mozilla
1' get profile manager
2. trigger manage profiles
3. trigger create profile
<fuzzy from here to assert>
4. possibly type/mouse/something before the create profile panel appeared?
(after running past the assertion i can confirm that the dialog had only started
to display when i triggered the assert)

What I found interesting is this caller fragment from DocumentViewerImpl::Show:
    // This little dance *may* only be to keep
    // PresShell::EndObservingDocument happy, but I'm not sure.
    nsCOMPtr<nsIContentViewer> prevViewer(mPreviousViewer);
    mPreviousViewer = nsnull;
    prevViewer->Destroy();

Comment 1

[timeless]

ok, the trick is to
4. both click the 'create profile' button and press <space> with it focussed at
about the same time (double click and double space to increase the chance of the
assert firing).

another assert can also result from doing this:
WARNING: NS_ENSURE_TRUE(window) failed, file
i:/build/mozilla/xpfe/appshell/src/nsContentTreeOwner.cpp, line 643
WARNING: NS_ENSURE_TRUE(docShellElement) failed, file
i:/build/mozilla/xpfe/appshell/src/nsXULWindow.cpp, line 1186
WARNING: NS_ENSURE_TRUE(windowElement) failed, file
i:/build/mozilla/xpfe/appshell/src/nsXULWindow.cpp, line 1240
###!!! ASSERTION: no xul:window: 'windowElement', file
i:/build/mozilla/xpfe/appshell/src/nsXULWindow.cpp, line 983
Break: at file i:/build/mozilla/xpfe/appshell/src/nsXULWindow.cpp, line 983
###!!! ASSERTION: no xul:window: 'windowElement', file
i:/build/mozilla/xpfe/appshell/src/nsXULWindow.cpp, line 917
Break: at file i:/build/mozilla/xpfe/appshell/src/nsXULWindow.cpp, line 917
###!!! ASSERTION: no xul:window: 'windowElement', file
i:/build/mozilla/xpfe/appshell/src/nsXULWindow.cpp, line 1055
Break: at file i:/build/mozilla/xpfe/appshell/src/nsXULWindow.cpp, line 1055
WARNING: NS_ENSURE_TRUE(windowElement) failed, file
i:/build/mozilla/xpfe/appshell/src/nsXULWindow.cpp, line 893

If that flavor happens then the create profile wizard will have the dimensions
of the screen and be shifted so part of it is offscreen a bit up and to the
left. I'll probably file a new bug for that version at some point.

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee didn't login in Bugzilla in the last 7 months, so the assignee is being reset.