User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.7.8) Gecko/20050511 Firefox/1.0.4 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.7.8) Gecko/20050511 Firefox/1.0.4 Doing XMLTHttpRequests in a popped up window prevents the final window.close() from actually working. Instead the window stays on screen. When clicking in that window, it suddenly disappears. The JS console does not output anything. To verify that problem, other places of the application using similar behaviour (doing something via XMLHttp, closing the respective window afterwards) were checked, leading to the same problem. Reproducible: Always Actual Results: In my application a window is popped up to fetch mails regularly. It uses XMLHttpRequest to communicate with the backend, which responds with JSON. After doing its job and properly reacting on the backends repsonse, a window.close() is called, but does not work. Expected Results: Expected behaviour: On reaching the "window.close();" command, the window should close itself.

I think I have a related problem. I have a secure app that uses client cookies for session management. What I'd like to happen, if the user is idle for long enough that the session expires, is: 1) A message pops up in the document with a link that says "Click here to relogin." 2) Upon clicking, the link spawns a new window (thus getting around popup blockers), and the user logs in again. 3) Once the login is confirmed, the login window calls a "tryAgain" function in the main app window, then does "window.close()". 4) "tryAgain" then, able to grab the function and arguments of the last-attempted action, "tries again". 5) With the shiny new login cookie, all is well. .....which is what's happening, except for #5. It appears that XMLHttpRequest is simply lying to me when it says it's sent the request for more data; responseText gives me nothing, and when I set up the server-side data-spitting script to "mark" each access, there's nothing that indicates that the "try again" actually reaches my data-spitter script. Now, I *can* do a user-initiated "try again", by just clicking on the button that performs the appropriate action, but of course that's what I want to avoid.

Could you please provide an HTML testcase that shows the problem? Also, if it's crashing this is probably bug 267286.

(In reply to comment #3) > Could you please provide an HTML testcase that shows the problem? Also, if it's > crashing this is probably bug 267286. Yes, you are right. The description of 267286 matches my bug report - unfortunately 267286 didn't show up on my search for already posted bugs. I will try to build a test case for you to reproduce, for the time being consider my report as a clone of the above bug report.

I have exactly the same problem in Firefox 1.5rc3 (WindowsXP). window.close() does not work inside a function which is executed via a xmlhttp response. The window remains open, clicking on the window closes the window. Firefox doesn't crash.

that's not exactly the same problem. reporter: you owe this bug a testcase. if i run across it again next month and you haven't provided one, i'll kill this bug. it's misfiled and has no useful information.

(In reply to comment #6) > that's not exactly the same problem. reporter: you owe this bug a testcase. if > i run across it again next month and you haven't provided one, i'll kill this > bug. Why so rude? That bug report was unnoticed for nearly half a year. Unfortunately my worload is pretty high, so I did not manage to put the files together immediately. A testcase can be found here: http://testifyer.de/xmlhttpdemo.html If you wish, I can also upload these as attachments to this bug. > it's misfiled and has no useful information. What do you mean by misfiled? This was my first bug report, if I did something wron, please let me know.

Got also the same bug in Firefox 1.5.0.2 and mozilla 1.7.12 on Win2000. Actually, the browser seems to have completly crashed. I included 3 test files, that must be put in the same folder. Then open the file "open.html" in Firefox, click on "Open Window", then click on "Close window" : the window should be still here, though the crash is pending if you play a bit with the windows. It seems like some datastructure has been freed, while the window remains opened. Basically, open.html opens a window to bypass Firefox security on "window.close()" (which seems allowed only on window opened using javascript). This will open the file test.html, which will do a dummy XmlHttpRequest on the file "test.xml", when clicking on the button. Then in the callback onreadystatechange, we immediatly close the window as soon as the status is 200 (ok). Nothing happens though, but if you activate the initial window, and then reactivate the test.html window, the browser completly crash. Quick workaround : replace the line "window.close()" by "window.setInterval('window.close()', 500)"

Comment on attachment 220023 [details] Entry point of crash test ><HTML><HEAD><TITLE>Crash test</TITLE></HEAD><BODY> ><INPUT type="button" onclick="window.open('https://bugzilla.mozilla.org/attachment.cgi?id=220024')" value="Open window"/> ></BODY></HTML>

Comment on attachment 220024 [details] XmlHttpRequest part <HTML><HEAD><TITLE>Crash test</TITLE> <SCRIPT type="text/javascript"> var req = null; function submit_request() { req = new XMLHttpRequest(); req.onreadystatechange = close_window; req.open("GET", "https://bugzilla.mozilla.org/attachment.cgi?id=220025", true); req.send(null); } function close_window() { if (req.readyState == 4) { window.close(); } } </SCRIPT></HEAD><BODY> <INPUT type="button" onclick="submit_request()" value="Close window"/> </BODY></HTML>

(In reply to comment #8) > ... if you activate the initial window, and then > reactivate the test.html window, the browser completly crash. Confirmed with ff 1.5.0.2 on win2k 1) Open the testcase "Entry point of crash test", 2) Click "Open Window" 3) Click "Close Window" 4) Activate the window with "Open Window" button 5) Activate the window with "Close Window" button and click anywhere in the document I get a crash: TB18049648G

I think it is a dupe of bug 267286. I get the identical crash stacks when running this testcase and testcase from bug 267286. ps. The crash does not appear with a trunk build 20060420 (after changing the default option to open links in new windows instead of new tabs).

*** This bug has been marked as a duplicate of 267286 ***

If this bug ever got fixed, it regressed at a later point. I think bug 372964 will fix it though.

I cannot reproduce this with the given STR on modern Firefox on Windows 10, and the XHR code has changed a great deal in the 11 years since this bug was last discussed, so I'm closing this as WORKSFORME.