295422 - JavaScript: After using XMLHttpRequest window.close() won't work, but clicking that window then makes it disappear.

Status: RESOLVED WORKSFORME

(Core :: XML, defect)

Description

[Matthias Sommerfeld]

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.

Comment 1

[Matthias Sommerfeld]

Attachment: minmized JavaScript to help reproduce the problem

Comment 2

[Felipe]

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.

Comment 3

[Adam Guthrie]

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

Comment 4

[Matthias Sommerfeld]

(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.

Comment 5

[karl]

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.

Comment 6

[timeless]

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.

Comment 7

[Matthias Sommerfeld]

(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. 

Comment 8

[Thierry Pierron]

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 9

[Thierry Pierron]

Attachment: Entry point of crash test

Comment 10

[Thierry Pierron]

Attachment: XmlHttpRequest part

Comment 11

[Thierry Pierron]

Attachment: Dummy xml file for XmlHttpRequest

Comment 12

[Marius Strumyla]

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 13

[Marius Strumyla]

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>

Comment 14

[Marius Strumyla]

Attachment: XmlHttpRequest part

Comment 15

[Marius Strumyla]

Attachment: XmlHttpRequest part

Comment 16

[Marius Strumyla]

Attachment: Entry point of crash test

Comment 17

[Marius Strumyla]

(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

Comment 18

[Marius Strumyla]

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).

Comment 19

[Marius Strumyla]

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

Comment 20

[Nickolay_Ponomarev]

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

Comment 21

[Thomas Wisniewski]

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.