Javascript: wait until ajax request finishes to close page [duplicate]

Question

I would like the browser to keep the page open until the ajax requests are sent. This is what I imagine it would look like

var requestsPending = 0;

window.onbeforeunload = function() {
    showPleaseWaitMessage();
    while(requestsPending > 0);
}

// called before making ajax request, atomic somehow
function ajaxStarted() {
    requestsPending++;
}
// called when ajax finishes, also atomic
function ajaxFinished() {
    requestsPending--;
}

Unfortunately, JS doesn't do multi-threading. To my understanding, the callback (ajaxFinished) would never be executed because the browser would try to wait until the while loop finishes to execute it, and so the it would loop forever.

What's the right way to do this? Is there maybe a way to force JS to evaluate the next thing in its to-do list and then come back to the while loop? Or some syntax to "join" with an ajax call? I'm using DWR for my ajax.

Thanks, -Max

Fibrous

Answer 1

Edit Based on your comment below, a revised answer:

If you want to block until a previously-initiated request completes, you can do it like this:

window.onbeforeunload = function(event) {
    var s;
    event = event || window.event;
    if (requestsPending > 0) {
        s = "Your most recent changes are still being saved. " +
            "If you close the window now, they may not be saved.";
        event.returnValue = s;
        return s;
    }
}

The browser will then prompt the user to ask whether they want to leave the page or stay on it, putting them in control. If they stay on the page and the request has completed while the prompt was up, the next time they go to close the page, it'll let them close it without asking.

Note that on modern browsers, your message will not be shown; instead, the browser will use a generic message. So on modern browsers, returning any non-blank string is sufficient. Still, you may want to return a useful string (such as the above) in case your user is using an obsolete browser that will still show it.

More on asking the user whether to cancel close events here and here.

---

Old answer :

Ideally, if possible, you want to avoid doing this. :-)

If you can't avoid it, it's possible to make an Ajax request synchronous, so that it blocks the onbeforeunload process until it completes. I don't know DWR, but I expect it has a flag to control whether the request is synchronous or not. In the raw XmlHTTPRequest API, this is the third parameter to open:

req.open('GET', 'http://www.mozilla.org/', false);
                                            ^ false = synchronous

Most libraries will have an equivalent. For instance, in Prototype, it's the asynchronous: false flag in the options.

But again, if you can possibly avoid firing off Ajax requests as part of the page unload, I would. There will be a noticeable delay while the request is set up, transmitted, and completed. Much better to have the server use a timeout to close down whatever it is that you're trying to close down with this. (It can be a fairly short timeout; you can keep the session alive by using asynchronous Ajax requests periodically in the page while it's open — say, one a minute, and time out after two minutes.)

Jory

Even if you make it synchronous, the browser won't wait, at least not all of them...so it's still unreliable (and it should be IMO, my browser shouldn't hang open because 1 of 10 tabs wants to make some AJAX request I don't care about). – Sconce

@Nick: Are you talking about beforeunload, or unload? Because in beforeunload I can launch things so intrusive as alerts if I want. I haven't done this (sending request during beforeunload) in a while (because I don't think it's a good idea), but when I did it a couple of years ago, it worked reliably in (I think) IE6, IE7, and Firefox ... um ... whatever Firefox was current a couple of years ago. :-) – Jory

@T.J. An alert blocks the UI thread, it's not a callback like ajax is, so different ballgame...something like the OPs trying to do won't work in either case (most of the time), it's a fire and forget...but whether even the fire part completes depends on the browser. – Sconce

The trick is, these ajax calls were initiated before the user closes the window. For example, say you have a reorderable list of elements that have edit links attached. If the user reorders the list, then clicks the link before the ajax can tell the server the list has been reordered, he loses his change as the browser goes to the edit page. I want to force the browser to wait until the ajax call has been completed before leaving the page. – Fibrous

@Nick: I'll have to try it again (can't right now). But based on OP's comment, turns out, this isn't what he wants to do anyway! :-) – Jory

@Fibrous - Why not disable that link until the ajax request comes back? – Sconce

@Nick: He can do that for links in his page, but the user's bookmarks, or back button, or... – Jory

@T.J. I agree, but such is the stateless nature of the web, for better or worse. – Sconce

Note: the support for custom message has been dropped in modern browsers. See this SO question for more details: #38880242 – Madai

Answer 2

In short, you cannot (and shouldn't) do this. If a user closes the browser, it's closing...no unload style events are guaranteed to finish, and something doing AJAX with involves latency is more unlikely to finish.

You should look at firing your events at another point, or change the approach altogether, but making an AJAX call in an unload event is going to unreliable, at best.

As an addendum to the above on the shouldn't part, think about it this way, how many tabs do you usually have open on any given window? I typically have 4-6 chrome windows open with 5-12 tabs each...should my browser window hang open because 1 of those tabs wants to make some AJAX request I don't care about? I wouldn't want it to as a user, so I wouldn't try and do it as a developer. This is just an opinion of course, but food for thought.

Sconce

What would be a good solution to this problem then? For example, say you have a reorderable list of elements that have edit links attached. If the user reorders the list, then clicks the link before the ajax can tell the server the list has been reordered, he loses his change as the browser goes to the edit page. – Fibrous

@Fibrous - A .live() handler for example that returns false if an ajax request is in progress, continues if it isn't...anything that prevents the link from working when it shouldn't really. – Sconce