Greg's findings:
"Looking at the application mentioned in the post ( A snappy client side ICEfaces compatible calendar from Rob Mayhew) I see what is happening.

The application does navigation from the main page to the calendar page without using redirection. This means that the URL in the title bar always remains:
http://localhost:8080/jspx&rvn=1

even though we have navigated. Hitting F5 in a purely JSF application causes the browser to submit the last post aubmitted and this causes re-navigation to the same page as before the reload, otherwise, it would wind up reloading the first page as well. The browser in an ICEfaces application doesn't do this, but merely issues a reload command which causes us to depend on the view preservation behaviour. I guess this gets into the unwanted re-posting of credit card details if one reloads the page in a JSF app from the order page.

It's an interesting observation that the execution in JSF is considered to be a postback."

This bug is a duplicate of bug http://jira.icefaces.org/browse/ICE-3632

Reuse FacesContext on reload to preserve the ViewRoot in case forward navigation rules were executed.

Reuse FacesContext on reload except in a Seam environment.

Yes, it can be backported but I have to pull in a few other changes.

Backport fixes from trunk together with the still standing fixes for ICE-3590.

Regression testing shows this is still not working for the case where just-ice.jar is configured on Tomcat 5 (instead of icefaces.jar).

Comment from Mircea:

I don't think this test was ever written to run with just-ice.jar and JSF1.1. h:commandLink uses a Javacript function that
h:form is responsible to render. So, as a consequence h:commandLink (in JSF1.1) doesn't work with ice:form ... it throws a Javascript error and the browser fails to submit the form. In JSF 1.2 this dependency h:commandLink->h:form does not exist anymore, that's why the test works fine in Tomcat6.0.