Difference in onUnload when using link vs Back button

[MacTommy]

I am using an AJAX function that calls some PHP file when the user unloads a page.
This runs fine when the unload is fired because of a link being clicked on. However, if I hit backspace or the browser's back button the PHP appears not to be executed (even though the alert I set in Javascript just before the PHP is called by the AJAX function does pop-up).

What am I missing..?!?

 

[MacTommy]

And I am using the latest Firefox on Windows, by the way...

 

[Diancecht]

Maybe it's a matter of speed ...

Cheers,
Dian

 

[MacTommy]

What do you mean by that..?!?

What would be the difference in speed between clicking a link and the backspace..?!

 

[Diancecht]

The backspace should be faster than the link.

Cheers,
Dian

 

[MacTommy]

OK, but then what..?!?

I was assuming that when the PHP is called it would be executed no matter what, AJAX being asynchronous and all.
But maybe I am just wrong about that...

What then would be the best way to to an update query to a database on unloading a page (which is what I am trying to achieve).

I could do a sleep/wait of 0.1 second or something of course, but that is neither full-proof nor very elegant...

 

[Diancecht]

Actually, I don't think you can do that. All browsers use to have issues with that event when back or forward button is pressed.

Personally, I wouldn't like a page to do anything when I leave it.

Cheers,
Dian

 

[MacTommy]

Hmm, I didn't know that all browsers had issues with it.

And the reason I want to do this, just for the record, is because I am making an interface to a database. People should be able to edit records in it. However, if they are doing so, nobody else should be editing the same records at the same time, so I am 'locking' the records somehow. When a user exits the page the records should be unlocked again, so that's why I want to do a query on unloading...

 

[IPGuru]

Debugging tip
try moving your alert to after the ajax call & see what happens

 

[MacTommy]

Well, I am saying now:

alert("Getting: " + sFile);
xmlHttp.open("GET", sFile, true);
alert("Done with: " + sFile);

I get both of the alerts in all cases, but still the PHP is not carried out in the back button/backspace case.

I would say myself that this would actually seem to suggest that something else is the matter. But what..?!?

 

[Diancecht]

Javascript is supposed to be asynchronous, so the second alert just means the request has been tried to deliver, nothing else.

I know I should give a sollution, but I'm afraid I don't know it. Maybe you should rethink your design with some kind of timeout for the database lock. Waht would happen if the user closes the browser abruptly?

Cheers,
Dian

 

[MacTommy]

Yes, you are right of course. If the user closes the browser in some forceful kind of way or just pulls the plug or something the records would stay locked indefinitely.

Nonetheless I have become intrigued by the difference in behaviour when unloading pages in different ways...

 

[BillyRayPreachersSon]

We've built a fairly nice publishing system at work for around 20-30 editors who all sit on the same floor.

When one of them opens a record, it's locked against their ID. If another user opens a locked record, we put an overlay over the page so they cannot use anything on the page. We then put a box at the top of this overlay saying:

This record is locked by <name>. Override and unlock.

Because they know who has locked it, they can (shock!) actually go and speak to the other editor and ask if they've finished editing it. If they have, then all is good, and if they haven't then they can wait.

If the other editor isn't around, they can use the 'override and unlock' link and leave a post-it or whatever so the original editor knows what's going on.

Either way, the onus is on the second person to make sure it's OK for them to edit the record.

Dan


Coedit Limited - Delivering standards compliant, accessible web solutions

[tt]Dan's Page [blue]@[/blue] Code Couch

http://www.codecouch.com/dan/

[/tt]

 

[MacTommy]

Yes, I think I have to start thinking along the lines of what you describe. Sounds fair enough indeed.
Doesn't solve the mystery of the onUnload behaviour though, but well...
I read several things across the net about its behaviour being notoriously unreliable between browsers anyway.

Thanks for your time & ideas!

Cheers!!

 

[Kirsle]

I have some insight for this thread: when your page is gone from the browser's memory, so is the JavaScript code. Your ajax request might be fired just fine onUnload, but by the time the ajax returns a response, your original JS code is no longer there to handle it because the browser has loaded the new page.

With a hyperlink, the browser has to make some kind of HTTP request (even if it's just a HEAD request to see if the page has been modified or if the browser can use its cached copy of the new page, if it has one). This adds a tiny delay and gives your ajax request some time to finish and return and get picked up by the JavaScript. When you hit the back button though, most browsers will automatically go straight to cache and not make any HTTP request whatsoever (which is why it's nearly impossible to detect when a back button has been used, for example with an online RPG game). So the ajax request is sent but instantaneously the page is cleared from browser memory, and if the ajax request completes there's no handler for it.

Similarly, this instantaneous erasion of memory might actually cancel the ajax request, too, before the browser even opens a socket with the server to deliver the request. If your server isn't even being hit with the request at all, this is likely what's happening.

You might want to open your database page in a window that doesn't have navigation buttons.

-------------
Cuvou.com | My personal homepage

perl -e '$|=$i=1;print" oo\n<|>\n_|_";x:sleep$|;print"\b",$i++%2?"/":"_";goto x;'

 

[IPGuru]

shouldnt your code be

alert("Getting: " + sFile);
xmlHttp.open("GET", sFile, true);
 xlmHttp.send(null);
alert("Done with: " + sFile);

it may also be better to set the async flag to false (that will force things to wait untill the DB update has been completed)