Resolving as fixed. Code was checked in to make MyFaces behave much the same as it does with Mojarra when using compat components. Our custom FormRenderer sticks in a placeholder and then the DOMResponseWriter replaces the placeholder at the appropriate time while removing the actual node from the DOM (to avoid unnecessary DOM diff related updates).

While trying to correct the ViewState issue in compat forms on the client-side does provide some success, I don't think it's a good long term solution. Some information to illustrate the point:

Mojarra and MyFaces handle state saving in different ways. Mojarra has a mechanism for installing a ViewState marker and then replacing that during the initial page render so that the state is actually only saved at the end of the lifecycle. State saving is done for each getViewState() call. This "mark and replace" approach is different than MyFaces which doesn't use a marker.

In ICEfaces, there are currently 2 types of Form renderers, standard h:form (handled by the JSF implementation, either Mojarra or MyFaces) and ice:form (which is handled by our own custom renderer). We have special Mojarra processing in this custom renderer so that the ViewState is included. We need to also ensure that the ViewState is also included when running with MyFaces.

Full page renders in Mojarra (which includes the ViewState) are different than partial page updates (which do not include the ViewState). ICEfaces DOM processing relies on certain behaviour here where the ViewState is written during the full page write but afterward removed from the DOM so that it is not there during a DOM diff. Without this logic, updates would always be full form updates. Again, something we need to cater to with MyFaces as well.

Also to consider are the number of forms per view and the number of views per page (e.g. portlets). The use cases are a combination of these two variables:

single view, single form
This is probably the most typical use case of a normal web app.

single view, multiple forms
This is also a fairly common use case.

multiple views, single form
While multiple views is a typical portlet scenario, I wouldn't expect only one portlet on the page to have a single form. There would likely be one or more forms per view.

multiple views, multiple forms
This is the typical portlet use case.

Without some fairly complex tracking, it would be more difficult to handle the portlet use cases on the client side. Instead, since each view should know it's own state, handling the ViewState processing on the server-side makes more sense.

Linking to the parent JIRA for overall MyFaces 2 compatibility

Both of the component issues are related to the strategy and timing of state saving in MyFaces.

With Mojarra, a marker/placeholder is used and state saving is not done until getViewState() is actually called. In Mojarra, this is done when the response is being written and the marker is being replaced.

With MyFaces, a marker is not used and getViewState() is called during the normal render process to inject the ViewState into the page. However, state saving is also done at this time but only once (as an optimization). Because of this, elements on the page that have not finished setting various state related values will not have those values saved and restored properly. For example, note the order of events as they are logged when the progress bar is updating:

OutputProgress.saveState: null
OutputProgressModel.setPercentComplete: 50
OutputProgress.restoreState: null
OutputProgressModel.getPercentComplete: 0
OutputProgressRenderer.setPercentage: 0

The issue is similar for the Chart component as the actual Chart resource is not state saved and is therefore not available to be restored when the user clicks on the image map.