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

RESOLVED FIXED

Status

()

--
critical
RESOLVED FIXED
14 years ago
13 years ago

People

(Reporter: michali.sarris, Assigned: jst)

Tracking

({crash})

Trunk
crash
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(crash signature, URL)

Attachments

(3 attachments, 1 obsolete attachment)

(Reporter)

Description

14 years ago
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.
(Reporter)

Comment 1

14 years ago
Created attachment 164268 [details]
The window that opens the dialog
(Reporter)

Comment 2

14 years ago
Created attachment 164269 [details]
The dialog that makes the XMLHttpRequest wich makes firefox crash
(Reporter)

Updated

14 years ago
Attachment #164269 - Attachment mime type: text/html → application/vnd.mozilla.xul+xml

Comment 3

14 years ago
Created attachment 164272 [details]
The window that opens the dialog - With url to Attachment #2 [details] [diff]
Attachment #164268 - Attachment is obsolete: true

Comment 4

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

Product -> Browser
Component: General → Browser-General
Product: Firefox → Browser
Version: unspecified → Trunk

Comment 5

14 years ago
>	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
Assignee: firefox → events
Component: Browser-General → Event Handling
QA Contact: firefox.general → ian
Summary: A window.close() statement in the XMLHttpRequest object onload event in a dialog window will make firefox crash → A window.close() statement in the XMLHttpRequest object onload event in a dialog window will make firefox crash [@ nsEventStateManager::PreHandleEvent]
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?
Oh, I'm confirming this.  It's pretty easy to reproduce and all that.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: crash

Comment 8

14 years ago
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)
*** Bug 286610 has been marked as a duplicate of this bug. ***
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

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

Updated

14 years ago
Assignee: events → jst
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.
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.)
OS: Windows XP → All
Hardware: PC → All
Created attachment 186710 [details]
Crash log.

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

Comment 15

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

Comment 16

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

Comment 17

13 years ago
*** Bug 295422 has been marked as a duplicate of this bug. ***
Yeah, almost certainly.
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Depends on: 281139
Resolution: --- → FIXED
*** Bug 337473 has been marked as a duplicate of this bug. ***
Crash Signature: [@ nsEventStateManager::PreHandleEvent]
You need to log in before you can comment on or make changes to this bug.