This issue doesn't appear to be fixed in Mojarra as of a snapshot build on 2010-05-17. Our current thinking is that our best strategy to work around this in the short-term is to query any requests and check to see if the javax.faces.ViewState parameter is being included. If it isn't, add it in ourselves.

Just to clarify this a bit further, using the samples/test/nav case with stock JSF (ie no ICEfaces):

1) Load the page (h

2) In a JavaScript console, you can check that the number of ViewState nodes in the document matches the number of forms in the page:

document.getElementsByName('javax.faces.ViewState').length;
13

3) Click either of the buttons in the top table (this is a postback to the same page) that have f:ajax render='all'. Either button A2 or A5 will do.

4) In a JavaScript console, you can check that the number of ViewState nodes in the document is no longer correct:

document.getElementsByName('javax.faces.ViewState').length;
1

Introduce system event listener that inserts a component responsible to render javax.faces.ViewState field into the forms when old DOM is missing due to navigation.

This appears to fix the problem with both the nav test case and the Mojarra unit test that was failing. However, I am seeing some JavaScript errors in the WebKit browsers:

Safari: TypeError: Result of expression 'document.getElementById('vuoah0w5_icefaces_config')' [null] is not an object.

Chrome: Uncaught TypeError: Cannot read property 'parentNode' of null

Firefox: No error

I added a line of code as suggested by Ted that adds an id to the UIOutput to prevent the duplicate id problem when we were running the Mojarra unit tests. The JavaScript errors noted above are still there so re-opening for further investigation.

Enclosed script element with 'span' so that during a DOM update the script can lookup the enclosing element. The script elements are evaluated (not inserted in the document) by the JSF bridge.