Stack Trace: XPCOM! 60a24584() --> invalid address accessed. RAPTORHTML! 604f6088() RAPTORHTML! 6049505d() RAPTORVIEW! 609e1d16() RAPTORVIEW! 609e1cdb() RAPTORVIEW! 609e6391() RAPTORVIEW! 609e23ec() RAPTORWIDGET! 60a05078() RAPTORWIDGET! 60a07702() RAPTORWIDGET! 60a07a04() RAPTORWIDGET! 60a0516e() USER32! 77e71250() umm...I take it that these DLL's aren't compiled with debugging information in the "Daily Builds" This was build 1999081108 BTW. Let me go get source code and try to get better debugging information.

Steve, don't we (or somebody else) already have a bug on this?

A more informative stack trace: nsMenuFrame::Execute() line 928 + 15 bytes nsMenuFrame::HandleEvent(nsMenuFrame * const 0x0a18f7a0, nsIPresContext & {...}, nsGUIEvent * 0x0012fba0, nsEventStatus & nsEventStatus_eConsumeDoDefault) line 247 PresShell::HandleEvent(PresShell * const 0x09dc0474, nsIView * 0x0ad37890, nsGUIEvent * 0x0012fba0, nsEventStatus & nsEventStatus_eConsumeDoDefault) line 1877 + 38 bytes nsView::HandleEvent(nsView * const 0x0ad37890, nsGUIEvent * 0x0012fba0, unsigned int 8, nsEventStatus & nsEventStatus_eConsumeDoDefault, int & 0) line 835 nsView::HandleEvent(nsView * const 0x09e3f3b0, nsGUIEvent * 0x0012fba0, unsigned int 28, nsEventStatus & nsEventStatus_eConsumeDoDefault, int & 0) line 820 nsViewManager::DispatchEvent(nsViewManager * const 0x09e3f5d0, nsGUIEvent * 0x0012fba0, nsEventStatus & nsEventStatus_eConsumeDoDefault) line 1611 HandleEvent(nsGUIEvent * 0x0012fba0) line 67 nsWindow::DispatchEvent(nsWindow * const 0x0ad37754, nsGUIEvent * 0x0012fba0, nsEventStatus & nsEventStatus_eIgnore) line 498 + 10 bytes nsWindow::DispatchWindowEvent(nsGUIEvent * 0x0012fba0) line 523 nsWindow::DispatchMouseEvent(unsigned int 301, nsPoint * 0x00000000) line 3268 + 21 bytes ChildWindow::DispatchMouseEvent(unsigned int 301, nsPoint * 0x00000000) line 3463 nsWindow::ProcessMessage(unsigned int 514, unsigned int 0, long 524326, long * 0x0012fdd4) line 2536 + 24 bytes nsWindow::WindowProc(HWND__ * 0x00030a1c, unsigned int 514, unsigned int 0, long 524326) line 571 + 27 bytes USER32! 77e71820()

The reason for the crash is that mcontent has value 0xdddddddd in the statement mContent->HandleDOMEvent(*mPresContext, &event, nsnull, NS_EVENT_FLAG_INIT, status);

David, has this been fixed?

Yes.

It worked for me too in my debug build today.

Updating QA Contact/Component

VERIFIED fixed with 2000011210 build on WinNT