Closed
Bug 34426
Opened 25 years ago
Closed 25 years ago
crash when closing pop-up window
Categories
(Core :: XUL, defect, P3)
Core
XUL
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:
Comment 1•25 years ago
|
||
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
Comment 2•25 years ago
|
||
bug is still alive on PC/Linux with 2000-04-10-08
Comment 3•25 years ago
|
||
new and sluffing off to jrgm
Status: UNCONFIRMED → NEW
Ever confirmed: true
QA Contact: paulmac → jrgm
Comment 5•25 years ago
|
||
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]
Comment 6•25 years ago
|
||
still seeing in 60208 winME, crashed in APPSHELL.DLL. incident ID: TB11666562G
Comment 7•25 years ago
|
||
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 | ||
Comment 10•25 years ago
|
||
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
Comment 11•25 years ago
|
||
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.
Description
•