RE: Proposal: Detecting when the user leaves a page due to hitting the back button or typing in a URL or going to a favorite

>I can see providing information about whether the user is going to 
>another page in the same domain, and if so which one.  Is this a common

>use case for application developers?

Presently, in my multi page form, I intercept all links on the page that
go to other pages in the form.  The link goes to a javascript routine
which sets a global javascript variable (GLOBALDoUnsavedEditCheck) to
false and then submits the form back to the server with a hidden form
field containing the URL to go to.  The server saves the form
information and then redirects the browser to the URL hidden on the
form.  In the onbeforeunload handler, I do something like:

window.onbeforeunload = function()
{
  if (GLOBALDoUnsavedEditCheck)
  {
    var changes = getUnsavedEditString();

    if (changes != null)
    {
      return "Changes (" + changes + ") have not been saved.  If you
proceed, they will be lost."; // cancel unload.
    }
  }
}

This allows the app to skip over the confirm dialog since the user is
not losing any unsaved edits by leaving the page, just going to another
part of the form.


Rather than have a global javascript flag, this event handler could
check the destination URL against an array of form URLs...

There may be other use cases.


>Because onbeforeunload can fire multiple times (e.g. if the user
decides 
>not to leave), so any real cleanup the web app does needs to happen in 
>unload.

>Making unload fire multiple times is a bigger compat-breaking change 
>than changing beforeunload behavior slightly.

>In other words, it's easier to make beforeunload do what's needed while

>not breaking either existing pages in UAs implementing the new stuff
nor 
>new pages in old UAs than it is to do the same thing with unload.  At 
>least as far as I can tell.

Existing webapps either utilize the nonstandard onbeforeunload or they
don't.

For those that don't, making the unload event cancellable won't break
anything (it won't be fired multiple times because the first time it's
fired is the last for the page because it gets unloaded on the first
fire since these existing web apps don't know that it can be cancelled
and thus don't do it).

For those web apps that do use onbeforeunload, it will continue probably
to be supported by browsers that use it, and again, unload will only be
called once, when onbeforeunload allows it.

So allowing unload to be canceled within the unload event handler won't
break existing apps.

-----Original Message-----
From: Boris Zbarsky [mailto:bzbarsky@MIT.EDU] 
Sent: Tuesday, January 06, 2009 10:21 AM
To: Shropshire, Andrew A
Cc: Mike Wilson; public-webapps@w3.org
Subject: Re: Proposal: Detecting when the user leaves a page due to
hitting the back button or typing in a URL or going to a favorite

Shropshire, Andrew A wrote:
> It would appear that there are countless ways to crash the browser
> and/or lose navigation history

Depends on the browser.  If your browser allows web pages to do this, 
either complain to the vendor or vote with your feet and switch to a 
better browser.  ;)

> 2. Add a property/method to the event object that tells the developer
> whether the window is closing or whether user is navigating away.  Now
> it may be helpful to provide the destination URL if navigating away in
> the special case where the user is going to a URL in the same domain
(if
> going to another domain, then the new function (to be added),
> getDestinationURL() could return null for security reasons).  This
would
> provide an additional way to the developer to detect whether the user
is
> jumping to another page within the same web application.

I can see providing information about whether the user is going to 
another page in the same domain, and if so which one.  Is this a common 
use case for application developers?

> One could fix the onbeforeunload() to behave this way and make it
> standard, but I don't see why one would need an onunload() event.

Because onbeforeunload can fire multiple times (e.g. if the user decides

not to leave), so any real cleanup the web app does needs to happen in 
unload.

Making unload fire multiple times is a bigger compat-breaking change 
than changing beforeunload behavior slightly.

In other words, it's easier to make beforeunload do what's needed while 
not breaking either existing pages in UAs implementing the new stuff nor

new pages in old UAs than it is to do the same thing with unload.  At 
least as far as I can tell.

-Boris

Received on Tuesday, 6 January 2009 17:25:46 UTC