Closed Bug 34426 Opened 24 years ago Closed 24 years ago

crash when closing pop-up window

Categories

(Core :: XUL, defect, P3)

Product:
Core
Component:
XUL
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: the-enigman, Assigned: pavlov)

References

(
URL
)

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: 24 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.