Closed Bug 34426 Opened 25 years ago Closed 25 years ago

crash when closing pop-up window

Categories

(Core :: XUL, defect, P3)

defect

Tracking

()

VERIFIED FIXED

People

(Reporter: the-enigman, Assigned: pavlov)

References

()

Details

(Keywords: crash, Whiteboard: [nsbeta2+])

Overview Description: Mozilla app will hang when you close the pop-up window at the given url. Steps to Reproduce: 1) load given url, wait for main page and pop-up window to load 2) close pop-up window using close box in title bar Actual Results: mozilla will hang, focus will not return to main window Expected Results: pop-up should close cleanly without affecting other mozilla windows Build Date & Platform Bug Found: Netscape Beta 1 Branch, 2000032718, Win98 Additional Builds and Platforms Tested On: Main Branch, 2000040308, Win98: same result Additional Information:
verified on linux 40409 also, perhaps travis's bug
Assignee: don → travis
Severity: normal → critical
OS: other → All
Hardware: PC → All
Summary: hang when closing pop-up window → crash when closing pop-up window
bug is still alive on PC/Linux with 2000-04-10-08
new and sluffing off to jrgm
Status: UNCONFIRMED → NEW
Ever confirmed: true
QA Contact: paulmac → jrgm
Adding crash keyword.
Keywords: crash
If the stack crawl (from a talkback incident on win95 2000042608 build) is to be believed then this dies trying to exit from an nsAutoMonitor. [This is easy to reproduce as described above, although note that you must delete the cookies from the site each time; otherwise the popup window will not launch]. Stack crawl from talkback incident (truncated for some reason): fill_n [prprf.c, line 217] cvt_l [prprf.c, line 267] _hashKeyCompare [d:\builds\seamonkey\mozilla\xpcom\ds\nsHashtable.cpp, line 38] PL_HashTableLookup [plhash.c, line 345] nsServiceManagerImpl::GetService [d:\builds\seamonkey\mozilla\xpcom\components\nsServiceManager.cpp, line 292] PR_snprintf [prprf.c, line 1164] RDFContainerUtilsImpl::IndexToOrdinalResource [d:\builds\seamonkey\mozilla\rdf\base\src\nsRDFContainerUtils.cpp, line 154]
still seeing in 60208 winME, crashed in APPSHELL.DLL. incident ID: TB11666562G
The problem seems to be that the js popup window is calling 'self.close()' in its unload handler. However, the object on the other end of that call is already gone by the time this call happens. (?) This exception is thrown at the time of the crash: JavaScript error: line 0: uncaught exception: [Exception... "Component does not have requested interface" code: "-2147467262" nsresult: "0x80004002 (NS_NOINTERFACE)" location: "<unknown>"] a simple testcase is posted at http://jrgm/bugs/34426/itlib.html where the source of these files is: ---itlib.html-------------------------------------------------- <html> <head><script language="JavaScript"> var page = "pup.html"; var windowprops = ""; function qWindow() { window.open(page, "", windowprops); } </script></head> <body onLoad="qWindow();"> <p>You're Doomed!!!</p> </body> </html> ---pup.html---------------------------------------------------- <html> <body onunload="self.close()"> <p>Doomed, I tell you ...</p> </body> </html> I get a stacktrace/console on linux of : Document http://jrgm/bugs/34426/itlib.html loaded successfully Document: Done (0.602 secs) *** check number of frames in content area Document http://jrgm/bugs/34426/pup.html loaded successfully JavaScript error: line 0: uncaught exception: [Exception... "Component does not have requested interface" code: "-2147467262" nsresult: "0x80004002 (NS_NOINTERFACE)" location: "<unknown>"] JavaScript error: line 0: uncaught exception: [Exception... "Component does not have requested interface" code: "-2147467262" nsresult: "0x80004002 (NS_NOINTERFACE)" location: "<unknown>"] WEBSHELL- = 6 ###!!! ASSERTION: You can't dereference a NULL nsCOMPtr with operator->().: 'mRawPtr != 0', file ../../dist/include/nsCOMPtr.h, line 623 ###!!! Break: at file ../../dist/include/nsCOMPtr.h, line 623 Program received signal SIGSEGV, Segmentation fault. 0x4070183f in nsXULWindow::Destroy (this=0x8681f80) at nsXULWindow.cpp:452 452 mWindow->SetClientData(0); // nsWebShellWindow hackery (gdb) bt #0 0x4070183f in nsXULWindow::Destroy (this=0x8681f80) at nsXULWindow.cpp:452 #1 0x4070d85e in nsWebShellWindow::Destroy (this=0x8681f80) at nsWebShellWindow.cpp:1735 #2 0x4070a4c7 in nsWebShellWindow::Close (this=0x8681f80) at nsWebShellWindow.cpp:362 #3 0x4070a7ae in nsWebShellWindow::HandleEvent (aEvent=0xbffff2c4) at nsWebShellWindow.cpp:441 #4 0x40a35858 in nsWidget::DispatchEvent (this=0x86e4a80, aEvent=0xbffff2c4, aStatus=@0xbffff2c0) at nsWidget.cpp:1418 #5 0x40a3e53b in handle_delete_event (w=0x86a63b0, e=0x82196b8, win=0x86e4a80) at nsWindow.cpp:1528 #6 0x40b12719 in gtk_marshal_BOOL__POINTER () from /usr/lib/libgtk-1.2.so.0 #7 0x40b3ffdd in gtk_handlers_run () from /usr/lib/libgtk-1.2.so.0 #8 0x40b3f422 in gtk_signal_real_emit () from /usr/lib/libgtk-1.2.so.0 #9 0x40b3d575 in gtk_signal_emit () from /usr/lib/libgtk-1.2.so.0 #10 0x40b7277c in gtk_widget_event () from /usr/lib/libgtk-1.2.so.0 #11 0x40b11700 in gtk_main_do_event () from /usr/lib/libgtk-1.2.so.0 #12 0x40a2c9ee in handle_gdk_event (event=0x82196b8, data=0x0) at nsGtkEventHandler.cpp:902 #13 0x40bbc00b in gdk_event_dispatch () from /usr/lib/libgdk-1.2.so.0 #14 0x40be9be6 in g_main_dispatch () from /usr/lib/libglib-1.2.so.0 #15 0x40bea1a1 in g_main_iterate () from /usr/lib/libglib-1.2.so.0 #16 0x40bea341 in g_main_run () from /usr/lib/libglib-1.2.so.0 #17 0x40b11209 in gtk_main () from /usr/lib/libgtk-1.2.so.0 #18 0x40a23338 in nsAppShell::Run (this=0x814e6c8) at nsAppShell.cpp:342 #19 0x40707954 in nsAppShellService::Run (this=0x8115490) at nsAppShellService.cpp:386 #20 0x8053489 in main1 (argc=1, argv=0xbffffa24, nativeApp=0x0) at nsAppRunner.cpp:906 #21 0x8053b6e in main (argc=1, argv=0xbffffa24) at nsAppRunner.cpp:1092 (gdb) passing on to danm -- the window man -- and cc: jst so he's aware of this DOM problem. Nominating nsbeta2 on the basis of the crash -- I don't think this is a common use case, but a crash is not good, and there is not much of a workaround for the user in this scenario.
Assignee: travis → danm
Component: XPApps → XP Toolkit/Widgets
Keywords: nsbeta2
Putting on [nsbeta2+] radar for beta2 fix.
Whiteboard: [nsbeta2+]
stealing bug from danm
Assignee: danm → pavlov
i stepped through the code and because of the self.close() we end up trying to close the window twice. this appears to be ok, we just need to check for null. i just checked in a fix
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
verified fixed win32/mac/linux 20000607nn M17 builds.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.