Closed
Bug 267286
Opened 20 years ago
Closed 18 years ago
A window.close() statement in the XMLHttpRequest object onload event in a dialog window will make firefox crash [@ nsEventStateManager::PreHandleEvent]
Categories
(Core :: DOM: UI Events & Focus Handling, defect)
Core
DOM: UI Events & Focus Handling
Tracking
()
RESOLVED
FIXED
People
(Reporter: michali.sarris, Assigned: jst)
References
()
Details
(Keywords: crash)
Crash Data
Attachments
(3 files, 1 obsolete file)
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•20 years ago
|
||
Reporter | ||
Comment 2•20 years ago
|
||
Reporter | ||
Updated•20 years ago
|
Attachment #164269 -
Attachment mime type: text/html → application/vnd.mozilla.xul+xml
Comment 3•20 years ago
|
||
Attachment #164268 -
Attachment is obsolete: true
Comment 4•20 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
> 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]
Comment 6•20 years ago
|
||
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•20 years ago
|
||
Oh, I'm confirming this. It's pretty easy to reproduce and all that.
Comment 8•19 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)
Comment 9•19 years ago
|
||
*** Bug 286610 has been marked as a duplicate of this bug. ***
Comment 10•19 years ago
|
||
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•19 years ago
|
||
I just ran into this bug, and worked around it by calling setTimeout("[window reference].close(), 100) in the XMLHTTPConnection thread.
Comment 12•19 years ago
|
||
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•19 years ago
|
||
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
Comment 14•19 years ago
|
||
Crash log from the Last.fm crash (only difference is line 0).
Comment 15•19 years ago
|
||
*** Bug 311788 has been marked as a duplicate of this bug. ***
Comment 16•19 years ago
|
||
*** Bug 297203 has been marked as a duplicate of this bug. ***
Comment 17•18 years ago
|
||
*** Bug 295422 has been marked as a duplicate of this bug. ***
Comment 18•18 years ago
|
||
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•18 years ago
|
||
I tested the builds from http://archive.mozilla.org/pub/firefox/nightly/
Comment 20•18 years ago
|
||
Yeah, almost certainly.
Comment 21•18 years ago
|
||
*** Bug 337473 has been marked as a duplicate of this bug. ***
Updated•13 years ago
|
Crash Signature: [@ nsEventStateManager::PreHandleEvent]
Updated•5 years ago
|
Component: Event Handling → User events and focus handling
You need to log in
before you can comment on or make changes to this bug.
Description
•