267286 - A window.close() statement in the XMLHttpRequest object onload event in a dialog window will make firefox crash [@ nsEventStateManager::PreHandleEvent]

Status: RESOLVED FIXED

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

Description

[Michali Sarris]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20041101 Firefox/1.0RC2
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20041101 Firefox/1.0RC2

I'm building a XUL based application and im having some troubles.

I'm trying to do a POST HTTP request with the XMLHttpRequest object wich is
working fine. I'm am doing this from an openend dialog window opened with the
window.open method en the modal=yes property. I want to close the dialog after
the request has been completed.

I want to do this by assigning a function to the onload event of the
XMLHttpRequest object, wich is called when the request has been completed (Just
what i want). In this function i reload a iframe in the opener window and i make
a self.close() method call so the window closes (so i hoped).

But this does not happen. The request will be made and the iframe will be
reloaded in the opener iframe, but the dialog window does not close. It wil do
nothing until (i tried to reproduce this and i succeeded in the following way) i
focus on the opener window and after that focus on the opened window. The opened
window wont close then, instead FireFox just crashes, each time again.

If i remove the self.close() statement, firefox will not crash, if i put it back
it will crash again. So i'm sure it has to do with the close statement from the
onload event.

I just updated to the newest Aviary Branch (FireFox 1.0 RC2 20041101) but the
bug is still here (as i suspected, because i dont think a lot of people are
trying to do what i am doing). 

see this topic for more info: 

http://forums.mozillazine.org/viewtopic.php?t=154102

Reproducible: Always
Steps to Reproduce:
1. Open the dialog window.
2. Make the XMLHttpRequest in the dialog, so window.close() in the onload event
will be called.
3. Focus on the opener window without closing the dialog window.
4. Focus back on the dialog window and firefox will crash.

Actual Results:  
Firefox crashes. I see the send bug report dialogs etc.

Expected Results:  
The dialog should have closed and firefox shouldn't crash.

Comment 1

[Michali Sarris]

Attachment: The window that opens the dialog

Comment 2

[Michali Sarris]

Attachment: The dialog that makes the XMLHttpRequest wich makes firefox crash

Comment 3

[Gary van der Merwe]

Attachment: The window that opens the dialog - With url to Attachment #2

Comment 4

[Gary van der Merwe]

This also happens in 
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a5) Gecko/20041027

Product -> Browser

Comment 5

[timeless]

>	gklayout.dll!nsEventStateManager::PreHandleEvent(nsPresContext * 
aPresContext=0x0396bd24, nsEvent * aEvent=0x03d37f4c, nsIFrame * 
aTargetFrame=0x03e729c8, nsEventStatus * aStatus=0x03d92f38, nsIView * 
aView=0x03521768)  Line 802 + 0x3	C++
 	gklayout.dll!PresShell::HandleEventInternal(nsEvent * 
aEvent=0x0012f0ac, nsIView * aView=0x03521768, unsigned int aFlags=0x00000001, 
nsEventStatus * aStatus=0x0012efa8)  Line 5956	C++
 	gklayout.dll!PresShell::HandleEvent(nsIView * aView=0x03521768, 
nsGUIEvent * aEvent=0x0012f0ac, nsEventStatus * aEventStatus=0x0012efa8, int 
aForceHandle=0x00000001, int & aHandled=0x01d307f0)  Line 5814 + 0x11	C++
 	gklayout.dll!nsViewManager::HandleEvent(nsView * aView=0x00000000, 
nsGUIEvent * aEvent=0x03521768, int aCaptured=0x03d79330)  Line 2285	C++
 	gklayout.dll!nsViewManager::DispatchEvent(nsGUIEvent * 
aEvent=0x3d888889, nsEventStatus * aStatus=0x0012f004)  Line 2059 + 0x14
	C++
 	gklayout.dll!HandleEvent(nsGUIEvent * aEvent=0x0012f0ac)  Line 166
	C++
 	gkwidget.dll!nsWindow::DispatchEvent(nsGUIEvent * event=0x0012f0ac, 
nsEventStatus & aStatus=nsEventStatus_eIgnore)  Line 1074 + 0x3	C++
 	gkwidget.dll!nsWindow::DispatchWindowEvent(nsGUIEvent * 
event=0x00000000)  Line 1095	C++
 	gkwidget.dll!nsWindow::DispatchFocus(unsigned int 
aEventType=0x0000006b, int isMozWindowTakingFocus=0x00000001)  Line 5524 + 0xe
	C++
 	gkwidget.dll!nsWindow::ProcessMessage(unsigned int msg=0x00000007, 
unsigned int wParam=0x00042dbc, long lParam=0x00000000, long * 
aRetValue=0x0012f3b4)  Line 4206	C++
 	gkwidget.dll!nsWindow::WindowProc(HWND__ * hWnd=0x00032dd6, unsigned 
int msg=0x00000007, unsigned int wParam=0x00042dbc, long lParam=0x03c6619c)  
Line 1355 + 0x10	C++
 	user32.dll!77d43a50() 	
 	user32.dll!77d43b1f() 	
 	user32.dll!PostMessageA()  + 0xad	
 	user32.dll!PostMessageA()  + 0xdd	
 	ntdll.dll!RtlDestroyHeap()  + 0xd	
 	gklayout.dll!GlobalWindowImpl::Focus()  Line 2471 + 0x10	C++
 	appshell.dll!nsWebShellWindow::HandleEvent(nsGUIEvent * 
aEvent=0x03d37f4c)  Line 609	C++
 	gkwidget.dll!nsWindow::DispatchEvent(nsGUIEvent * event=0x0012f624, 
nsEventStatus & aStatus=nsEventStatus_eIgnore)  Line 1074 + 0x3	C++
 	gkwidget.dll!nsWindow::DispatchWindowEvent(nsGUIEvent * 
event=0x00000000)  Line 1095	C++
 	gkwidget.dll!nsWindow::DispatchFocus(unsigned int 
aEventType=0x00000069, int isMozWindowTakingFocus=0x00000001)  Line 5524 + 0xe
	C++
 	gkwidget.dll!nsWindow::ProcessMessage(unsigned int msg=0x00000007, 
unsigned int wParam=0x00022dd8, long lParam=0x00000000, long * 
aRetValue=0x0012f92c)  Line 4195 + 0xa	C++
 	gkwidget.dll!nsWindow::WindowProc(HWND__ * hWnd=0x00042dbc, unsigned 
int msg=0x00000007, unsigned int wParam=0x00022dd8, long lParam=0x03df4804)  
Line 1355 + 0x10	C++
 	user32.dll!77d43a50() 	
 	user32.dll!77d43b1f() 	
 	user32.dll!PostMessageA()  + 0xad	
 	user32.dll!PostMessageA()  + 0xdd	
 	ntdll.dll!RtlDestroyHeap()  + 0xd	
 	user32.dll!DefWindowProcW()  + 0xa0	
 	gkwidget.dll!nsWindow::DefaultWindowProc(HWND__ * hWnd=0x00042dbc, 
unsigned int msg=0x00000006, unsigned int wParam=0x00000002, long 
lParam=0x000a2c78)  Line 1381	C++
 	user32.dll!77d43a50() 	
 	user32.dll!77d43b1f() 	
 	user32.dll!IsWindowVisible()  + 0x80	
 	user32.dll!CallWindowProcW()  + 0x19	
 	gkwidget.dll!nsWindow::WindowProc(HWND__ * hWnd=0x00042dbc, unsigned 
int msg=0x00000006, unsigned int wParam=0x00000002, long lParam=0x03df4804)  
Line 1362 + 0x15	C++
 	user32.dll!77d43a50() 	
 	user32.dll!77d43b1f() 	
 	user32.dll!PostMessageA()  + 0xad	
 	user32.dll!PostMessageA()  + 0xdd	
 	ntdll.dll!RtlDestroyHeap()  + 0xd	
 	user32.dll!PeekMessageW()  + 0xe3	
 	gkwidget.dll!nsAppShell::Run()  Line 128 + 0x2a	C++
 	appshell.dll!nsAppShellService::Run()  Line 484	C++
 	mozilla.exe!main1(int argc=0x00000000, char * * argv=0x03521768, 
nsISupports * nativeApp=0x03d79330)  Line 1336	C++
 	mozilla.exe!main(int argc=0x00000001, char * * argv=0x003f7b88)  Line 
1827 + 0x16	C++
 	mozilla.exe!mainCRTStartup()  Line 400 + 0x11	C
 	kernel32.dll!TermsrvAppInstallMode()  + 0x269	

            shell->FrameSelection()->SetMouseDownState(PR_FALSE);

shell = 0xdddddddd

oddly context seems ok

Comment 6

[Boris Zbarsky [:bzbarsky]]

It seems as if the self.close() doesn't take effect until the window regains
focus, for some reason... Then we close the window, destroy the presshell, then
try to access it, and crash.

jst, danm, any idea how this could happen?

Comment 7

[Boris Zbarsky [:bzbarsky]]

Oh, I'm confirming this.  It's pretty easy to reproduce and all that.

Comment 8

[Menno Smits]

I can confirm with:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041111 Firefox/1.0

(as ships with updated FC3)

Comment 9

[:Gavin Sharp [email: [e-mail]]]

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

Comment 10

[SK Matic]

i, too, am developing a web app that uses the same scripting and have had
firefox crashing on me...

confirmed on:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050223
Firefox/1.0.1

Comment 11

[Evan]

I just ran into this bug, and worked around it by calling setTimeout("[window
reference].close(), 100) in the XMLHTTPConnection thread.

Comment 12

[Peter Flynn (Oracle)]

I've seen other manifestations of this bug in code I work on. (Note that it
occurs in unprivileged script as well). Sometimes the window closes without a
crash, but not until the user moves the mouse (in this situation, the window has
focus the whole time). And sometimes the crash occurs.

Comment 13

[Wevah (Nate Weaver)]

I'm getting an almost identical stack trace when I crash from this bug and when
I crash from clicking "Stop Stream" on Last.fm's player page
(http://www.last.fm/player/index.php). The player has a window.close() that's
triggered from an XMLHTTPRequests onreadystatechange handler. (The only
difference in the traces is that the one from Last.fm's line #0 isn't zeroed out.)

Comment 14

[Wevah (Nate Weaver)]

Attachment: Crash log.

Crash log from the Last.fm crash (only difference is line 0).

Comment 15

[Adam Guthrie]

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

Comment 16

[Adam Guthrie]

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

Comment 17

[Marius Strumyla]

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

Comment 18

[Marius Strumyla]

This looks to have been fixed on a trunk. 2006-01-25-06-trunk build crashes while 2006-01-26-09-trunk build does not.

Possible suspect: bug 281139
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2006-01-25+06%3A00%3A00&maxdate=2006-01-26+10%3A00%3A00&cvsroot=%2Fcvsroot

Comment 19

[Marius Strumyla]

I tested the builds from http://archive.mozilla.org/pub/firefox/nightly/

Comment 20

[Boris Zbarsky [:bzbarsky]]

Yeah, almost certainly.

Comment 21

[Daniel Veditz [:dveditz]]

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