This investigation may require a few stages; one stage can be to have Mircea briefly document the current back button technique in ICEfaces 1.8.

Editing subject to include bookmarking as it related to back button behaviour.

Some interesting information regarding bookmarking in JSF 2.0. There are a few new features available to help with handling GET requests in general and bookmarking specifically. I found this blog to explain a few things more clearly than trying to wring them out of the spec and it also points to some other good resources:

http://andyschwartz.wordpress.com/2009/07/31/whats-new-in-jsf-2/

The short version is that there are a couple of new tags, h:button and h:link, that make it possible to directly or programmatically provide the result of navigating but have it calculated during the render phase. During rendering, the navigation system can calculate what the result of a navigation request will be and generate a URL with the necessary parameters. Since these are GET requests, they are also bookmarkable.

There are two different techniques used in ICEfaces for dealing with the back button. Each of these techniques is targeting one browser. Unfortunately we could not find a working solution for Safari.

The technique used for Firefox is quite simple since it relies only on the HTTP caching headers for forcing the browser to reload the page the back button navigated to. Firefox is the only browser that really discards the viewed page from its cache and fetches the page again as instructed by the cache headers.
Here are the sent headers:

Cache-Control = no-cache, no-store, must-revalidate – HTTP 1.1 instructions
Pragma = no-cache – HTTP 1.0 instruction
Expires = 0 – prevents proxy caching

As for IE the solution is a bit more complex because the browser doesn't re-fetch the page as it should.
In IE an iframe that is created by HTML markup (not created dynamically using Javascript) preserves the changes made to the fragment part of its location URL when the back button is used. This specific behavior is used to mark any page that was change by a DOM update. Once the back button is used the bridge (of the cached page) will check the iframe's fragment value, if its value is non-empty that means the page was modified by a DOM update. In order to bring browser's DOM in sync with the one on the server the bridge will fire an AJAX request to re-fetch the page and then apply a DOM update extracted from the page content.

I will try to describe what goes wrong when the back button is used in the context of an ICEfaces application. Let's assume we have an application that is made of 2 pages: A and B. We can have the following notation for the state of the DOM tree of page A: A(0) for the initial page load, A(1) after fist DOM update, A(2) after the second DOM update and so on.
Let's say the user will first navigate to page A. The browser will load the page, create the DOM in its initial state A(0), and cache this state for the URL corresponding to page A. Then the user interacts twice with the rendered page thus causing twice a change in the state of DOM tree: A(0) > A(1) > A(2) . When the user navigates to page B and then hit the back button the browser will look into the history and restore the page from the cache by using A(0) state that was saved when the page was first loaded. The intermediary states A(1) and A(2) are never saved. So even if page A had A(2) state before navigating to page B, A(0) is the state used to render the page when the back button is used.

I can see three types of solutions to fix the "back button" problem:

1) Force a URL change every time the state of the DOM is changed. This way the browser will cache/save the state every time the DOM is updated.

2) Detect the change in state after the the back button was used and re-synchronize the state by applying a page-wide update.

3) Force the browser to replace the state cached at page load time A(0) with the last state A(2) before the page is unloaded.

The first solution would be way too verbose because the navigation history would be polluted with so many similar URLs. The second solution is what we have today. The third solution is really the ideal solution for fixing the "back button" problem, the only problem is finding a implementation that works across all browsers.

Separated the aspects of this issue in two issues, one for back-button handling and the other for page bookmark-ability. See ICE-5007 and ICE-5008.