W3C home > Mailing lists > Public > public-webapi@w3.org > January 2006

Re: Ajax Back/Forward History problem saving document state by document.save()

From: Vladimir Kelman <vlad@vkelman.com>
Date: Sat, 07 Jan 2006 20:41:06 -0500
Message-ID: <43C06DB2.8010406@vkelman.com>
To: public-webapi@w3.org

Karl Pongratz wrote:
> I also want to note that I wanted to propose something simple that 
> solves the emerging Ajax web application web browser history problem,
>  something that is strongly tight to the xmlhttp request object and
> would be easy to implement by user agent vendors.

Karl, I strongly believe that modifying browser's engines to save 
*state* in addition to URL just cannot be simple enough. I highly doubt 
it would be implemented any soon.

As <isolani/> says here 
http://www.isolani.co.uk/blog/javascript/FixingTheBackButtonThatAjaxBroke, 
  "Part of the AJAX problem is understanding whether an AJAX enhanced 
page is actually a web application, or is it still just a web document?"

I believe that an AJAX enhanced page should be considered a web 
application by itself. I also believe, that the best and really easy 
solution would be to conditionally disable "Back" and "Forward" buttons 
on an AJAX page. When I said "conditionally" I meant that in case a user 
clicks one of these buttons a browser should display a confirmation 
window asking if user really wants to *leave application*.

Yes, it would break a "pure HTML ideology", but this ideology applies to 
   web pages, not to web applications.

AJAX web pages aren't first pages which would benefit from conditionally 
disabling "Back" and "Forward" buttons. The same issue arises for any 
web pages with dynamically modified content: for pages with frames, for 
pages with Java applets or ActiveX controls.

Even plain HTML pages generated by server-side (PHP, ASP, etc.) script 
often experience troubles with "Back" and "Forward" buttons. Consider a 
standard situation when a page uses HTML form to POST to itself, or when 
server-side script uses SESSIONS to save data on a server side. It 
immediately breaks a normal behavior of "Back" and "Forward" buttons, 
because document's *state* is not exclusively determined by a URL, it 
may depend on a session variable or even data, retrieved from a database.

So, again, such pages are web applications by themselves - something 
similar to a graphical Windows desktop application, and they should be 
able to restrict "Back" and "Forward" buttons' behavior.

Internet Explorer does provide a way to do it with onbeforeunload Event 
http://msdn.microsoft.com/workshop/author/dhtml/reference/events/onbeforeunload.asp.
Unfortunately, other browser's vendors consider themselves more "purist" 
and do not provide such ability. If you try to Google like 
http://www.google.com/search?hl=en&lr=&rls=GGGL%2CGGGL%3A2005-09%2CGGGL%3Aen&q=disable+back+button&btnG=Search 
you'll get a long list of messages from people struggling to disable 
those buttons... I understand that controlling "Back" and "Forward" 
buttons' behavior from a loaded HTML document may introduce some 
security risks, but I think that it well worth to implement as standard 
behavior - advantages are immense.

-- 
Vladimir Kelman
http://www.vkelman.com
Vlad@vkelman.com
Received on Sunday, 8 January 2006 05:10:04 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:18:53 GMT