[whatwg] salvaging work while navigating away from a web app -- onunload="confirm('save before quitting?')

[Ojan Vafai]

On Fri, Dec 12, 2008 at 12:55 AM, Ian Hickson <ian at hixie.ch> wrote:

> On Sun, 16 Nov 2008, ddailey wrote:
> >
> > Here's the sitch: because of an extensive use of CTRL sequences in the
> > interface, the user will sometimes accidentally do something like CTRL R
> > (which the browser thinks is a refresh command). In a regular app, if
> > users stand in jeopardy of losing all their work, the app usually warns
> > them before quitting. The way I found to work around it (that used to
> > work) was to use onunload="confirm('save before quitting?'). Currently,
> > however, IE seems to have removed my ability to intervene before it
> > erases all work. onbeforeunload=function (){ fix(everything)} doesn't
> > seem to help either.
> >
> > So the question: how does HTML 5 currently address the issue and do
> > browsers actually implement something along this line these days?
>
> I just went ahead and specced out the 'onbeforeunload' feature that most
> browsers support today that handles this case.
>
> Basically you just need to do
>
>   onbeforeunload="if (dirty) return 'You have unsaved work. Are you sure
> you want to close this page?'"
>
> ...or some such.
>

If we're going for matching what browsers do, there's a number of cases
(different in each browser) where the confirm doesn't popup. In Chrome, for
example, if the beforeunload handler takes too long, we kill it and navigate
away. Similarly, in Firefox, if the beforeunload handler hits the limit for
script execution and the user stops the script, the beforeunload handler
never fires.

Not sure what the right language for that is. But developers try to do
things like using beforeunload/unload to release locks, make server
requests, etc. and it's just not a very reliable thing to do in any browser.
It's really just useful for the quick prompt for the user as to things like
unsaved changes.

Ojan

On Mon, 17 Nov 2008, Thomas Broyer wrote:
> >
> > I'm not sure you can automatically save but what you can do is cancel
> > the unload with a prompt.
> >
> > window.onbeforeunload = function() {
> >   return "Your unsaved changes will be lost. Are you sure you want to
> leave?";
> > };
> >
> > The browser will prompt the user with the returned string. Clicking "no"
> > or "cancel" (depends on the browser) will cancel the "unload". If you
> > don't want the prompt, just return "undefined" (beware, returning null
> > in IE6 is equivalent to returning the string "null").
> >
> > window.onbeforeunload = function() {
> >  if (unsavedChanges) {
> >    return "You have unsaved changes.";
> >  }
> >  // return nothing, i.e. return undefined
> > };
>
> Right.
>
>
> > HTML5 is almost silent about beforeunload and unload (and many other)
> > events re. their properties (cancelable in this case). unload is defined
> > in DOM3-Events (as non-cancelable) but AFAICT beforeunload is not spec'd
> > anywhere.
>
> Fixed.
>
>
> On Mon, 17 Nov 2008, Philipp Serafin wrote:
> >
> > What you can do for an "emergency save" is to fire a *synchronous* XHR
> during
> > the unload event. This will freeze the UI but since the user was about to
> > close the page anyway, this shouldn't matter much.
>
> The other alternative is to be always saving state on the server (or in
> a local database, cookie, or equivalent).
>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20081212/2201c078/attachment.htm>