168454 - Crash on opening link in new window - Trunk M120A [@ nsEventStateManager::PreHandleEvent]

Status: VERIFIED FIXED

(Core :: DOM: UI Events & Focus Handling, defect)

Description

[Markus Hübner]

Just right click on "freunde + partner" and select "Open Link in new Window" --
> crashing.

using trunk build 2002091208 on win-xp pro.

Comment 1

[Christian :Biesinger (don't email me, ping me on IRC)]

fixing url field

Comment 2

[Matthias Versen [:Matti]]

nsEventStateManager::PreHandleEvent(nsEventStateManager * const 0x042bd640,
nsIPresContext * 0x058dcb60, nsEvent * 0x0012f264, nsIFrame * 0x059d3920,
nsEventStatus * 0x0012f09c, nsIView * 0x05912758) line 747 + 53 bytes
PresShell::HandleEventInternal(nsEvent * 0x0012f264, nsIView * 0x05912758,
unsigned int 1, nsEventStatus * 0x0012f09c) line 6149 + 43 bytes
PresShell::HandleEvent(PresShell * const 0x0582c6bc, nsIView * 0x05912758,
nsGUIEvent * 0x0012f264, nsEventStatus * 0x0012f09c, int 1, int & 1) line 6078 +
25 bytes
nsViewManager::HandleEvent(nsView * 0x05912758, nsGUIEvent * 0x0012f264, int 0)
line 2046
nsView::HandleEvent(nsViewManager * 0x059df760, nsGUIEvent * 0x0012f264, int 0)
line 301
nsViewManager::DispatchEvent(nsViewManager * const 0x059df760, nsGUIEvent *
0x0012f264, nsEventStatus * 0x0012f1d4) line 1897 + 23 bytes
HandleEvent(nsGUIEvent * 0x0012f264) line 83
nsWindow::DispatchEvent(nsWindow * const 0x0591536c, nsGUIEvent * 0x0012f264,
nsEventStatus & nsEventStatus_eIgnore) line 1038 + 10 bytes
nsWindow::DispatchWindowEvent(nsGUIEvent * 0x0012f264) line 1059
nsWindow::DispatchFocus(unsigned int 108, int 1) line 5325 + 15 bytes
nsWindow::ProcessMessage(unsigned int 8, unsigned int 5243368, long 0, long *
0x0012f670) line 4030 + 23 bytes
nsWindow::WindowProc(HWND__ * 0x000701fa, unsigned int 8, unsigned int 5243368,
long 0) line 1307 + 27 bytes
USER32! 77e01d0a()
USER32! 77e02bcc()
USER32! 77e02b84()
NTDLL! 778a02ff()
USER32! 77e0287f()
USER32! 77e01d0a()
USER32! 77e03d4b()
USER32! 77e0734d()
nsWindow::WindowProc(HWND__ * 0x005001e8, unsigned int 6, unsigned int 1, long
721548) line 1318 + 31 bytes
USER32! 77e01d0a()
USER32! 77e02bcc()
USER32! 77e02b84()
NTDLL! 778a02ff()
nsXULWindow::SetVisibility(nsXULWindow * const 0x05923a68, int 1) line 640
nsXULWindow::OnChromeLoaded() line 837
nsWebShellWindow::OnStateChange(nsWebShellWindow * const 0x05923ac8,
nsIWebProgress * 0x0591b66c, nsIRequest * 0x0590bc98, unsigned int 786448,
unsigned int 0) line 1305
nsDocLoaderImpl::FireOnStateChange(nsIWebProgress * 0x0591b66c, nsIRequest *
0x0590bc98, int 786448, unsigned int 0) line 1235
nsDocLoaderImpl::doStopDocumentLoad(nsIRequest * 0x0590bc98, unsigned int 0)
line 871
nsDocLoaderImpl::DocLoaderIsEmpty() line 768
nsDocLoaderImpl::DocLoaderIsEmpty() line 771
nsDocLoaderImpl::OnStopRequest(nsDocLoaderImpl * const 0x05b79574, nsIRequest *
0x05b79df8, nsISupports * 0x00000000, unsigned int 0) line 699
nsLoadGroup::RemoveRequest(nsLoadGroup * const 0x05b797b8, nsIRequest *
0x05b79df8, nsISupports * 0x00000000, unsigned int 0) line 694 + 35 bytes
nsStreamIOChannel::OnStopRequest(nsStreamIOChannel * const 0x05b79dfc,
nsIRequest * 0x05b79eec, nsISupports * 0x00000000, unsigned int 0) line 486
nsOnStopRequestEvent::HandleEvent() line 213
nsARequestObserverEvent::HandlePLEvent(PLEvent * 0x05b7b18c) line 116
PL_HandleEvent(PLEvent * 0x05b7b18c) line 643 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x00ff7b30) line 573 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x0004011c, unsigned int 49415, unsigned int 0,
long 16743216) line 1308 + 9 bytes
USER32! 77e01d0a()
USER32! 77e01bc8()
USER32! 77e072b4()
nsAppShellService::Run(nsAppShellService * const 0x010c9b28) line 472
main1(int 2, char * * 0x00283160, nsISupports * 0x00000000) line 1508 + 32 bytes
main(int 2, char * * 0x00283160) line 1868 + 37 bytes
mainCRTStartup() line 338 + 17 bytes
KERNEL32! 77e8ca90()

Comment 3

[Christian :Biesinger (don't email me, ping me on IRC)]

I can reproduce this (win98, 2002091110). talkback ID = 10856227K

Comment 4

[Markus Hübner]

TB ID on win-xp pro = TB10855931G

Comment 5

[Matthias Versen [:Matti]]

i get an assertion :
###!!! ASSERTION: You can't dereference a NULL nsCOMPtr with operator->().: 'mRa
wPtr != 0', file ../../../dist/include/xpcom\nsCOMPtr.h, line 650


and focusController is zero = crash

-> Events

Comment 6

[Christian :Biesinger (don't email me, ping me on IRC)]

cc'ing some people who did some checkins to this file, maybe they're interested
in fixing this :)

Comment 7

[David Tenser [:djst]]

WinXP Pro. TB10858001E
Adding self to cc.

Comment 8

[Boris Zbarsky [:bzbarsky]]

This is the crash that I was seeing over in bug 167228, as it happens...  See
bug 167228 comment 5 and forward.

(gdb) frame 0
#0  0x40bfdc57 in nsEventStateManager::PreHandleEvent (this=0x86a6650, 
    aPresContext=0x871b530, aEvent=0xbfffe800, aTargetFrame=0x87c3dbc, 
    aStatus=0xbfffe608, aView=0x8681318) at nsEventStateManager.cpp:747
747              
focusController->GetFocusedElement(getter_AddRefs(focusedElement));
(gdb) p focusController
$1 = {mRawPtr = 0x0}
(gdb) p gLastFocusedDocument
$2 = (class nsIDocument *) 0x874b830
(gdb) p mDocument
$3 = (nsIDocument *) 0x874b830
(gdb) p gLastFocusedContent
$4 = (class nsIContent *) 0x87b1228

#0  0x40bfdc57 in nsEventStateManager::PreHandleEvent (this=0x86a6650, 
    aPresContext=0x871b530, aEvent=0xbfffe800, aTargetFrame=0x87c3dbc, 
    aStatus=0xbfffe608, aView=0x8681318) at nsEventStateManager.cpp:747
#1  0x42512efa in PresShell::HandleEventInternal (this=0x877b240,
aEvent=0xbfffe800, 
    aView=0x8681318, aFlags=1, aStatus=0xbfffe608) at nsPresShell.cpp:6190
#2  0x42512b24 in PresShell::HandleEvent (this=0x877b240, aView=0x8681318, 
    aEvent=0xbfffe800, aEventStatus=0xbfffe608, aForceHandle=1,
aHandled=@0xbfffe604)
    at nsPresShell.cpp:6119
#3  0x41f08322 in nsViewManager::HandleEvent (this=0x866da30, aView=0x8681318, 
    aEvent=0xbfffe800, aCaptured=0) at nsViewManager.cpp:2050
#4  0x41ef9505 in nsView::HandleEvent (this=0x8681318, aVM=0x866da30,
aEvent=0xbfffe800, 
    aCaptured=0) at nsView.cpp:300
#5  0x41f07d73 in nsViewManager::DispatchEvent (this=0x866da30, aEvent=0xbfffe800, 
    aStatus=0xbfffe700) at nsViewManager.cpp:1903
#6  0x41ef8d92 in HandleEvent (aEvent=0xbfffe800) at nsView.cpp:80
#7  0x41257cc6 in nsWidget::DispatchEvent (this=0x8657bd8, aEvent=0xbfffe800, 
    aStatus=@0xbfffe7bc) at nsWidget.cpp:1476
#8  0x412578de in nsWidget::DispatchWindowEvent (this=0x8657bd8, event=0xbfffe800)
    at nsWidget.cpp:1364
#9  0x41257986 in nsWidget::DispatchFocus (this=0x8657bd8, aEvent=@0xbfffe800)
    at nsWidget.cpp:1386
#10 0x4125f31e in nsWindow::DispatchDeactivateEvent (this=0x8657bd8) at
nsWindow.cpp:1486
#11 0x4125f4fd in nsWindow::HandleMozAreaFocusOut (this=0x8169708) at
nsWindow.cpp:1565
#12 0x412634f7 in handle_mozarea_focus_out (aWidget=0x817e3d0, 
    aGdkFocusEvent=0xbfffec80, aData=0x8169708) at nsWindow.cpp:2890

Comment 9

[Olivier Cahagne]

fwiw, I don't crash using build 20020901 (trunk debug build on Linux).

Comment 10

[Brian Ryner (not reading)]

The root of the problem here seems to be that mDocument's container is null.

jst, any idea what would cause that?  This is during processing of NS_DEACTIVATE
on the original page, not the newly opened window.

Comment 11

[Johnny Stenback (:jst)]

The document only holds a weak reference to its container (if it even has one),
if the document outlives its container then the container will be null. Code
should not rely on there always being a container in a document since there are
cases where there isn't one.

Comment 12

[Brian Ryner (not reading)]

per conversation with jst, I think it's fine to just null-check this and not
fire the blur if we don't get a container for the document.  This means that the
docshell has gone away, and hence the document is no longer visible.

Comment 13

[Brian Ryner (not reading)]

Attachment: null-check the focus controller

Comment 14

[Johnny Stenback (:jst)]

Comment on attachment 99771 [details] [diff] [review]
null-check the focus controller

sr=jst

Comment 15

[Markus Hübner]

*** Bug 170156 has been marked as a duplicate of this bug. ***

Comment 16

[Joe Hewitt (gone)]

Comment on attachment 99771 [details] [diff] [review]
null-check the focus controller

r=hewitt

Comment 17

[Brian Ryner (not reading)]

checked in.

Comment 18

[Jay Patel [:jay]]

Adding topcrash keyword and Trunk M120A to summary for future reference.  This
was a topcrasher on the MozillaTrunk and with Mozilla 1.2 Alpha.  

I don't see any recent crashes on the MozillaTrunk, so also verifying fixed.