See testcase, which crashes Firefox on reload. This is with the Windows Media Player 10 installed. The binding attached to the embed, is just an empty binding. This regressed between 2008-03-13 and 2008-03-14, so I think a regression from bug 416953.

http://crash-stats.mozilla.com/report/index/526c858c-f42f-11dc-9237-001a4bd46e84 0 npdsplay.dll@0x29519 1 npdsplay.dll@0x2972e 2 InternalCallWinProc 3 UserCallWinProcCheckWow 4 DispatchClientMessage 5 __fnDWORD 6 KiUserCallbackDispatcher 7 npdsplay.dll@0x29703 8 wmp.dll@0xf3744 9 wmp.dll@0x155e0e 10 npdsplay.dll@0x17b03 11 npdsplay.dll@0xcea7 12 npdsplay.dll@0x1090c 13 ns4xPluginInstance::Stop() mozilla/modules/plugin/base/src/ns4xPluginInstance.cpp:955 14 DoStopPlugin mozilla/layout/generic/nsObjectFrame.cpp:1730 15 nsStopPluginRunnable::Run() mozilla/layout/generic/nsObjectFrame.cpp:1766 16 nsThread::ProcessNextEvent(int, int*) mozilla/xpcom/threads/nsThread.cpp:510 17 PR_GetEnv

This is with Flash version 9,0,115,0 installed. To reproduce the crash, load testcase2, go back and then forward. http://crash-stats.mozilla.com/report/index/bf37f685-f431-11dc-b4b0-001a4bd43e5c 0 @0x300bf8c3 1 UserCallWinProcCheckWow 2 DispatchClientMessage 3 __fnDWORD 4 KiUserCallbackDispatcher 5 TestWindowProcess 6 nsPresContext::EnsureVisible(int) mozilla/layout/base/nsPresContext.cpp:1460 7 PresShell::UnsuppressAndInvalidate() mozilla/layout/base/nsPresShell.cpp:4326 8 PresShell::UnsuppressPainting() mozilla/layout/base/nsPresShell.cpp:4386 9 DocumentViewerImpl::LoadComplete(unsigned int) mozilla/layout/base/nsDocumentViewer.cpp:1013 10 nsDocShell::EndPageLoad(nsIWebProgress*, nsIChannel*, unsigned int) mozilla/docshell/base/nsDocShell.cpp:5025 11 nsWebShell::EndPageLoad(nsIWebProgress*, nsIChannel*, unsigned int) mozilla/docshell/base/nsWebShell.cpp:1013 12 nsCOMPtr_base::assign_from_qi(nsQueryInterface, nsID const&) nsCOMPtr.cpp:96 13 nsDocShell::OnStateChange(nsIWebProgress*, nsIRequest*, unsigned int, unsigned int) mozilla/docshell/base/nsDocShell.cpp:4930

This bug has accounted for about 20% of our crashes in the past few days of Windows nightlies, starting in 20080314.

(In reply to comment #4) > *** Bug 423494 has been marked as a duplicate of this bug. *** > I recognize the similarities between the two bugs (same signature, etc.), but the frame stack from comments 1 and 2 doesn't match very well with the report that I posted in bug 423494. Moreover, I wasn't doing anything with a plugin when the crash happened. See below: 0 @0x300a3de3 1 UserCallWinProcCheckWow 2 DispatchClientMessage 3 __fnDWORD 4 ntdll.dll@0x60e6d 5 nsView::~nsView() mozilla/view/src/nsView.cpp:272 6 nsView::`scalar deleting destructor'(unsigned int) 7 nsIView::Destroy() mozilla/view/src/nsView.cpp:314 8 nsView::~nsView() mozilla/view/src/nsView.cpp:224 9 nsView::`scalar deleting destructor'(unsigned int) 10 nsFrame::Destroy() mozilla/layout/generic/nsFrame.cpp:505 11 nsSubDocumentFrame::Destroy() mozilla/layout/generic/nsFrameFrame.cpp:784 12 nsFrameList::DestroyFrames() mozilla/layout/generic/nsFrameList.cpp:67 13 nsContainerFrame::Destroy() mozilla/layout/generic/nsContainerFrame.cpp:257 14 nsFrameList::DestroyFrames() mozilla/layout/generic/nsFrameList.cpp:67 15 nsContainerFrame::Destroy() mozilla/layout/generic/nsContainerFrame.cpp:257 16 nsBoxFrame::RemoveFrame(nsIAtom*, nsIFrame*) mozilla/layout/xul/base/src/nsBoxFrame.cpp:1024 17 nsCSSFrameConstructor::ContentRemoved(nsIContent*, nsIContent*, int, int*) mozilla/layout/base/nsCSSFrameConstructor.cpp:9648 18 PresShell::ContentRemoved(nsIDocument*, nsIContent*, nsIContent*, int) mozilla/layout/base/nsPresShell.cpp:4787 19 nsNodeUtils::ContentRemoved(nsINode*, nsIContent*, int) mozilla/content/base/src/nsNodeUtils.cpp:167 20 nsGenericElement::doRemoveChildAt(unsigned int, int, nsIContent*, nsIContent*, nsIDocument*, nsAttrAndChildArray&) mozilla/content/base/src/nsGenericElement.cpp:2850 21 nsXULElement::RemoveChildAt(unsigned int, int) mozilla/content/xul/content/src/nsXULElement.cpp:980 22 nsXULElement::IndexOf(nsINode*) mozilla/content/xul/content/src/nsXULElement.cpp:906 23 nsXULElement::RemoveChild(nsIDOMNode*, nsIDOMNode**) mozilla/content/xul/content/src/nsXULElement.h:610 24 NS_InvokeByIndex_P mozilla/xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp:101 25 xptiInterfaceEntry::GetMethodInfo(unsigned short, nsXPTMethodInfo const**) mozilla/xpcom/reflect/xptinfo/src/xptiInterfaceInfo.cpp:317

Not to confuse or derail things in this bug, but a random sampling of crashes from here: http://crash-stats.mozilla.com/report/list?range_unit=weeks&version=Firefox%3A3.0b5pre&range_value=2&signature=%400x300bf8c3 reveals that a large proportion of the crashes with signature 0x300bf8c3 have a frame stack similar to that of comment 5 and not to comment 1 or comment 2. I'd posit that the large proportion of 0x300bf8c3 crashes are related to bug 423494.

we should try and get this fixed for before releasing beta 5. looks like it will likely be the top crash by wide margin (4x?) over the number #2 crasher if we don't....

Fixed by the fix for bug 422926.

verified fixed using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008041217 Minefield/3.0pre ID:2008041217 and the testcases from this bug. No crash on testcases --> Verified fixed