What we'd like next here is an analysis and/or suggestions on some possible ways we might handle use of the back and forward buttons. One suggestion would be for ICEfaces to provide a client-side API that hooks into the back/forward actions that would allow application developers to determine what happens. We could also provide a reasonable default implementation that uses the API to handle a standard use case.

The solution chosen was to rewrite the entire DOM of the browser just before the page is unloaded. This way the browser is forced to keep around the state of the page the way it is right before navigation occurs, and not the way ti was when first loaded. This fix should cover more than 50% of cases.

Created issue ICE-5685 that should be fixing the other 50% of cases, if needed.

As for IE, I think there's a fairly significant problem.

It seems that whenever a partial update is applied to the page, any
attempt to reload/refresh after that results in JavaScript errors (ice
undefined, window.ice undefined). I see this in the scopes case by

• going to any test
• reload the page (should work multiple times)
• change a counter value
• try and reload the page again (mine fails here)

In addition, once it fails, I frequently can't get anything to load in
that tab again. I've been able to reproduce the same behaviour in the
nav example by doing pretty much the same thing:

• going to the first page
• reload the page (should work multiple times)
• click the A3 button
• try and reload the page again (mine fails here)

This doesn't sound good. I'll have a look. We might need to remove the
code that rewrites the markup if it has this kind of "side effects".

Taking out the fix for this issue solves the problem we're seeing in Firefox ad IE6. Since the fix wasn't a complete solution for back button handling and it introduces unwanted side-effects this issue will not be fixed. Hopefully the solution for ICE-5685 will solve the back button handling problem.