Hi,

I'd like to use onbeforeunload to submit a form before leaving a page.
This works in Firefox and IE. Safari, however, blithely ignores this.

Does anyone know of a workaround for Safari? Or another way to do the
same thing in Safari? (that is, intercept a request to leave the page).
I tried Safari 2.02 on Tiger.

Thanks!

Jen

> I'd like to use onbeforeunload to submit a form before leaving a page.
> This works in Firefox and IE. Safari, however, blithely ignores this.
>
> Does anyone know of a workaround for Safari? Or another way to do the
> same thing in Safari? (that is, intercept a request to leave the page).
> I tried Safari 2.02 on Tiger.

Any reason why window.onunload won't work? Maybe use both, and have
onbeforeunload set a flag that onunload checks for to work around
things like the Google toolbar that disable onunload.

On 11/11/2005 01:43, jennyw wrote:

> I'd like to use onbeforeunload to submit a form before leaving a page.

Why? If the user is leaving, it should be considered too late to do 
anything.

> This works in Firefox and IE. Safari, however, blithely ignores this.

Why shouldn't it? The beforeunload event is a Microsoft invention, so no 
vendor is under any obligation to implement it. Even Opera doesn't, and 
it probably implements more of Microsoft's proprietary features than any 
other browser.

[snip]

Mike

-- 
Michael Winter
Prefix subject with [News] before replying by e-mail.

> I'd like to use onbeforeunload to submit a form before leaving a page.
> This works in Firefox and IE. Safari, however, blithely ignores this.
> Does anyone know of a workaround for Safari? Or another way to do the
> same thing in Safari? (that is, intercept a request to leave the page).
> I tried Safari 2.02 on Tiger.

<onbeforeunload> event handler is implemented only by browsers which
have "current page's state snapshot" mechanics.

What <onbeforeunload> is for:
1) to take the current page's state snapshot including each form
elements state/value and save in the data store on the client side: so
next time user comes on this page she will get it in the exactly same
state as she left it.

2) That's it!


What <onbeforeunload> is *NOT" for:
1) to nag users with idiotic questions:
- Are you sure you want to quit?
- Are you really really sure you want to leave now?
- Maybe you will stay here a bit more?
 etc.

2) to sent/receive last minute data from server. Like:
- Sure I'll let you to leave... Just hold on for a couple of minutes
(hours) before I finish data exchange...
 :-)

Safari and Konqueror are not such browsers, so they don't have
<onbeforeunload>. They are (as a greate amount of other wannabes)
rather featureless HTML/XML renderers. The only reason they are *so
far* taken into any account is that they are coming pre-installed with
Mac OS X and KDE for Linux respectively. So they are parasiting on some
users' mental inertion: it was here from the beginning, so I'll keep
using it. This tactic helped a lot to Internet Explorer to win the war,
but besides that it was at least a really powerful browser. I'm not
sure what their hope is on the long run.

VK wrote:

> What <onbeforeunload> is for:
> 1) to take the current page's state snapshot including each form
> elements state/value and save in the data store on the client side: so
> next time user comes on this page she will get it in the exactly same
> state as she left it.
> 
> 2) That's it!

Err, no. onbeforeunload has one intended purpose which is to warn the user 
that they are navigating away from the page and give the user the option to 
decide whether or not they want to continue. That is the sole reason for 
its existence.

> 
> 
> What <onbeforeunload> is *NOT" for:
> 1) to nag users with idiotic questions:
> - Are you sure you want to quit?
> - Are you really really sure you want to leave now?
> - Maybe you will stay here a bit more?
>  etc.
> 
The question may be idiotic if asked in the wrong situation, but the 
ability to ask such questions is an important part of making a useable web 
application, and onbeforeunload is the only way to do it reliably.

> 2) to sent/receive last minute data from server. Like:
> - Sure I'll let you to leave... Just hold on for a couple of minutes
> (hours) before I finish data exchange...
> :-)

You are correct on that point.

Duncan Booth wrote:
> Err, no. onbeforeunload has one intended purpose which is to warn the user
> that they are navigating away from the page and give the user the option to
> decide whether or not they want to continue. That is the sole reason for
> its existence.
> >
> The question may be idiotic if asked in the wrong situation, but the
> ability to ask such questions is an important part of making a useable web
> application, and onbeforeunload is the only way to do it reliably.

If user wants to leave the site it means she *wants* to leave the site.
If she wants to go to the previous page it means that she *wants" to go
to the previous page. These are very basics of usability and proper
programming.
We may presume an unattended form submission or a link click on the
page - but this is easy to fix by standard event handlers on the page
itself. If someone used browser interface: toolbar button or menu
command or shortcut key - then there is no space for any guess or
presumption. User indeed wants what she asked for. Save the page state
using <onbeforeunload> and let her go.

But if you really cannot let someone out without one more final "Hell
f*** yes, I do!" confirmation, then... you're the king anyway, I guess.

VK wrote:

> Duncan Booth wrote:
>> Err, no. onbeforeunload has one intended purpose which is to warn the
>> user that they are navigating away from the page and give the user
>> the option to decide whether or not they want to continue. That is
>> the sole reason for its existence.
>> >
>> The question may be idiotic if asked in the wrong situation, but the
>> ability to ask such questions is an important part of making a
>> useable web application, and onbeforeunload is the only way to do it
>> reliably. 
> 
> If user wants to leave the site it means she *wants* to leave the
> site. If she wants to go to the previous page it means that she
> *wants" to go to the previous page. These are very basics of usability
> and proper programming.
> We may presume an unattended form submission or a link click on the
> page - but this is easy to fix by standard event handlers on the page
> itself. If someone used browser interface: toolbar button or menu
> command or shortcut key - then there is no space for any guess or
> presumption. User indeed wants what she asked for. Save the page state
> using <onbeforeunload> and let her go.

You and your users may be perfect, unfortunately my users aren't and they 
make mistakes and sometimes click on links which result in navigating away 
from a page without having saved their work. If a page contains a complex 
form, and the user has entered some data but then attempts to navigate away 
without saving, a simple yes/no request for confirmation is appropriate.

> 
> But if you really cannot let someone out without one more final "Hell
> f*** yes, I do!" confirmation, then... you're the king anyway, I
> guess. 

Sorry, but my business is providing the users what they want, and since the 
users ask for such confirmation, that is what they get.

Anyway, you are missing the point: onbeforeunload exists solely for the 
purpose of generating a confirmation dialog before navigating away. That is 
why Microsoft invented the event, and using it is so important in some 
situations that the Mozilla team realised they had to adopt the same event 
(albeit with a slightly incompatible interface). To say the event is not 
intended for generating a warning dialog is simply wrong. Yes, it can also 
be used in inappropriate situations to annoy users, but that does not 
impact on its correct use.