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 on 1/2/2009 8:36 AM: 
> I'd like to propose an onNavigateToNewPage event for the window object.
> This would be distinguished from the onUnload event in that the event is
> only fired when the user navigates to a new page whereas onUnload is
> fired additionally for when the user closes the web page or browser.

I brought up a related idea on the WHATWG list where it would be possible to determine via onBeforeUnload if the user action is one where they're leaving the site versus one where they're remaining on the site:

 leaves site:
  closes browser
  closes tab
  closes window
  back/forward to different site
  GET/POST to another site
  navigates away using address bar

 returns to site:
  reloads page
  back/forward to same site
  GET/POST to same site


The thread is here if you're interested:

 http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-December/017766.html


That was to solve the issue of detecting when a user has left the site so as to log them out (since users typically are terrible at logging themselves out via a logout link).



> The advantages of this approach are:
> 
> 1)    The web page designer can detect when the browser back button is
> hit or when the user goes to a link that is not on the page and cancel
> this navigation.

FWIW, you can do this already to some extent.  This is what I do (using jQuery):


 <script language="JavaScript" type="text/javascript">
 jQuery(function(){
  var clicked = false;
  $(".nowarn").bind("click",function(e){clicked = true; return true;});
  window.onbeforeunload = function () { if(clicked == false){ 
   return 'You have not saved the report. Choose "Cancel" and click on "Save Report"'
  } };
 });
 </script>

Then my links look like:

 <a class="nowarn" href="somepage">Go here</a>


The user then only sees a warning if they click on a destructive link, reload the page, hit the back button, navigate to a new site, close the tab or close the browser.  Basically any action except the one(s) that properly save the data.



> 2)    This provides the web page designer the ability to warn the user
> that navigating away will cause any form information not yet posted back
> to the server to be lost and allow the user to cancel their request.
> This can be done without requiring a page refresh.

onBeforeUnload already allows this, correct?



> 3)    In some situations, the web page designer may wish to block
> navigation to any link but those specified on the page (for example, in
> order to recreate a desktop's modal dialog capability) and not show a
> confirm dialog.

This represents a fundamental shift in browser behavior (giving the server strong control over the browser, despite what the user wants to do).  An idea I've floated on a couple of other lists is one where the browser tab can be "pinned" to a single domain, and any action that would cause the URL to change to another domain (such as clicking an external link) would cause the browser to open it in another tab.  The only way to "navigate" away from the site that is pinned is to close the tab.



> Existing approaches such as onbeforeunload() have the following
> disadvantages:
> 
> 1)    They always show a confirm dialog (this sometimes is not
> desirable).

This is to give the user the option to override what the site wants.


> 2)    The text in the confirm dialog is not fully editable and may not
> be appropriate in some situations.

This is to prevent a malicious site from returning the message 'Click "Ok" to format your hard drive, click "Cancel" to abort.' -- thus forever scaring the novice user from leaving the site.  The pre-canned dialog text is localized, so it helps in situations where you don't speak the language and the browser is asking you to do something.



- Bil

Received on Monday, 5 January 2009 16:57:41 UTC