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.
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.