The problem is not so much that the whole view gets reset when a component uses render="@all" in its ajax tag. What happens is that on an ajax render-all request, the whole view is getting dynamically updated. This means that the whole markup is being replaced in-place in the browser. This means that the HTML nodes that already had some input from the user get replaced by identical nodes but without that input that the user had entered. So, it looks like the whole view is reset. However, if these components had the default ajax tag or at least the ajax tag with execute="@this" render="@none", that value persisted when this issue occurred, because the value had already been saved when the user entered it.

The whole view is getting updated for an unknown reason. What we observed was that a couple of form elements that ICEfaces uses internally (single-submit and retrieve-update) are getting a new client ID at every ajax render-all request, and because these form elements are first-level children, this is triggering the whole view to be updated according to our DOMdiff rules. However, it seems to be a more general JSF issue, because we also tested with a pure, standard JSF test case, and we could see a similar behaviour. We didn't see these system form elements changing client IDs, because standard jSF doesn't use them, but we saw that the whole view was getting updated as well, at every ajax render-all request, and we also observed that all values in the view were reset, and no value could be saved, even for the very component that triggered that request.