Closed Bug 305855 Opened 19 years ago Closed 3 years ago

XMLHttpRequest not working after window.close() of spawned window

Categories

(Core :: DOM: Core & HTML, defect)

x86
Windows 2000
defect
Not set
normal

Tracking

()

RESOLVED INCOMPLETE

People

(Reporter: felipe, Assigned: jst)

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6

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.

Reproducible: Always




related to bug 295422
Incidentally, this does work in IE, but it fails in Opera with the same behavior
as in Moz. I don't have a Safari box handy to be able to test there.
I met the same problem with a popup window. I could workaround the problem by
calling xmlhttp.abort() right after the request result and before the
self.close() in the popup window eg:

In the main window:
"""
function do_request(url) {
          xmlhttp.open('GET', url, false);
          xmlhttp.send(null);
          var result_html = xmlhttp.responseText;
          xmlhttp.abort()
          // do stuff with result
}
"""

In the popup window:
"""
function do_remote_update(params) {
   var url
   // build url with params
   opener.do_request(url)
   self.close()
}

Hope this helps.
Haven't tested this with opera yet.
Assignee: nobody → general
Component: General → JavaScript Engine
Product: Firefox → Core
QA Contact: general → general
Version: unspecified → Trunk
Not a JS eng bug.
Component: JavaScript Engine → DOM: Core
Assignee: general → general
QA Contact: general → ian
Confirming.

Gabriel, please don't move random bugs that have nothing to do with the
JavaScript Engine into that component.

/be
Status: UNCONFIRMED → NEW
Ever confirmed: true
Might be a problem for AJAX apps.

/be
Flags: blocking1.8b5?
Assignee: general → jst
Flags: blocking1.8b5? → blocking1.8b5+
Johnny, can you take a look at this and help us decide if we can get something
in for 1.5?
This seems like it might be related (or even the same as!) bug 307777.
Johnny, have you had a chance to look into this? Seems like this could break a
lot of people. Time is getting very short for 1.5b2.
requires large changes to the ownership model so it's too late for 1.8
Flags: blocking1.8b5+ → blocking1.8b5-
Component: DOM: Core → DOM: Core & HTML
QA Contact: ian → general
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.