window.close crashes browser when invoked from async xmlhttp callback

RESOLVED DUPLICATE of bug 267286

Status

()

--
critical
RESOLVED DUPLICATE of bug 267286
14 years ago
13 years ago

People

(Reporter: moz-bugzilla, Unassigned)

Tracking

({crash, testcase})

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

(Reporter)

Description

14 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4

this happens in 1.0.4 AND in deerpark reliably, every time.

when window.close is issued to close an opened window, inside the
onreadystatechange callack of on xmlhttp object, it crashes the browser.  i
believe the key ingredient of this is that the xmlhttp object itself, and thus
the lexical scope of the anonymous callback function, are created in the popup,
see the 'how to reproduce' for details. 

to use the 'to be attached' files, which reproduce every time, you MUST use a
web server to create latency on the async xmlhttp request or it won't crash. 
ie.e you cannot use file:// domain

Reproducible: Always

Steps to Reproduce:
1.main page opens popup

winref = window.open(...)

2.some event handler (e.g. onclick) in popup calls into opener.somefunc()
3.opener.somefunc() creates xmlhttp object to a remote page (must have some
latency to trigger) with async onreadystatechange handler of an anonymous function:

in somefunc():

xh.onreadystatechange = function() { var x = xh.responseText; completefunc(x); }

4. on async callback, close opened popup window

completefunc() {
 winref.close();
 winref = null;
}


Actual Results:  
the popup may or may not close immediately and crash.  if it does not crash
immediately, it will crash as soon as the mouse is clicked on/moved over the popup

Expected Results:  
not crashed.

let me know how to get the trace/module name info.
(Reporter)

Comment 1

14 years ago
Created attachment 185782 [details]
main page for reproducing crash. also need two more

this page must be saved with the other two attachements to a real-live
webserver with some latency to the client to work.  in the doxmlhttp() function
the url will then need to be edited to reflect the url of the saved target.
(Reporter)

Comment 2

14 years ago
Created attachment 185783 [details]
html for popup opened by main page

this page must be saved with the other two attachements to a real-live
webserver with some latency to the client to work.
(Reporter)

Comment 3

14 years ago
Created attachment 185784 [details]
target of the xmlhttp POST

this file is a JSP simply to create the latency necessary to reproduce this bug
for me on 'localhost' it can be reproduced in any environment where the actual
xmlhttp request takes a bit of time to complete.

Updated

14 years ago
Keywords: crash, testcase
I have confirmed this crash on FC3, using both Deer Park Alpha (CVS) and Firefox
1.0.4 (rpm).

For reference, I've installed the testcase here:
http://coop.deadsquid.com/test/crasher.html

My steps to reproduce were slightly different, but they will crash the browser
every time:
1. Open http://coop.deadsquid.com/test/crasher.html
2. Click the 'click me' link.
3. On the resulting popup, click the 'click me' link.
4. Switch focus from the popup to the main browser window.
5. Switch focus back to the popup -> CRASH

Build IDs:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b2) Gecko/20050622 Firefox/1.0+
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050513
Fedora/1.0.4-1.3.1 Firefox/1.0.4

Linux version:
2.6.11-1.27_FC3

rpm versions:
xorg-x11-6.8.2-1.FC3.13
gcc-3.4.3-22.fc3
gtk2-2.4.14-3.fc3

Comment 5

13 years ago
Have seen this problem on XP too. Does not occur with IE and Mozilla - only in 
Firefox.

Comment 6

13 years ago

*** This bug has been marked as a duplicate of 267286 ***
Status: UNCONFIRMED → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.