views:

529

answers:

2

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

+1  A: 

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.

Nick Craver
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.
maxdj
@maxdj - 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.
Nick Craver
+1  A: 
T.J. Crowder
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).
Nick Craver
@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. :-)
T.J. Crowder
@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.
Nick Craver
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.
maxdj
@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! :-)
T.J. Crowder
@maxdj - Why not disable that link until the ajax request comes back?
Nick Craver
@Nick: He can do that for links in his page, but the user's bookmarks, or back button, or...
T.J. Crowder
@T.J. I agree, but such is the stateless nature of the web, for better or worse.
Nick Craver