Yanick said the following on 9/4/2006 11:40 AM:
Randy :
How nice of you to always point out other person's errors. It really
makes me feel like I tried, doesn't it ? I shall say that you post is
no better since it doesn't give any further solution to the problem.
It doesn't give any further solution because the solution doesn't lie in
client side scripting. The problem isn't detecting onunload - that is
trivial as you know. The problem is detecting *why* it was triggered and
you simply can't detect that.
Events that can trigger onunload:
Closing the Browser.
Closing the Tab (Tabbed Browsers).
Clicking a Link.
Submitting a Form.
Clicking a Button on the page that navigates away.
Clicking a Favorites.
Typing in a new URL.
Clicking the Forward/Back button.
That is not a complete list but just a sample.
Of those, you can deal with the third, fourth and fifth reasonably in
the page with scripting. The others you simply can not detect other than
the fact that the page is being unloaded.
It is an often enough asked question that it is in the group FAQ
although the section title it is in isn't the easiest to search for.
<URL:
http://jibbering.com/faq/#FAQ4_29>
Which leads to this URL, which explains how to do it on the server:
<URL:
http://groups.google.com/group/comp.lang.javascript/msg/a0c582dc42c65fd2>
Maybe because some people insist on not giving them any examples with
clear solutions, but only conceptual suggestions... which, I may add,
are not always connected to the problem.
When you can't give a reliable solution then you there's not much point
in trying to come up with one. After you read questions like this a
kazillion times and explain it that many times you get jaded.
Like I said to you in an earlier post, I have no grief against you. I
believe that you are knowledgeable, and somewhat ressourceful. Though
everytime I read your posts, I can't help to feel that you're putting
down those you tried to help before you.
Maybe I need to change my demeanor and take a break from Usenet said:
As for the solution proposed, for the two reasons that you have
mentionned :
1) javascript issues
2) back button that'd fire the unload event
It is clear that the solution had issues. But I still stick to my
suggestion :
To (e-mail address removed) (the OP) :
This is a (tested) solution. It doesn't fix your back/foreward button
(you don't know if the 'X' or close button has been clicked, or if the
user simply press 'Back' or 'Foreward'), but it's a start (taken from
http://www.webreference.com/dhtml/diner/beforeunload/bunload4.html,
http://pro-thoughts.blogspot.com/2006/03/onbeforeunload-event.html) :
// take all anchors and disable the confirmation box
// in their onclick events
Sidenote: You may want to look into adding the same type of
onclick/onsubmit event handlers to forms and buttons:
<button onclick="document.location....">
<input type="submit">
Also, I have seen code that looks like this:
<span onclick=""> and <div onclick=""> and <li onclick=""> and it goes
on. Your code attempts to handle links but it can be made more
comprehensive but then it becomes overburdening to try to cover all the
possible ways to navigate away from the page.
The simplest solution to non A element onclicks is instead of setting
location properties, call a function that will cover the leaving of the
site.
Instead of this:
<button
onclick="document.location.href='
http://www.google.com'">Google</button>
The page author would have to write it as such:
<button onclick="navigateAway('
http://www.google.com')">Google</button>
And then have the navigateAway function set the unload flag.