Modified one remaining instance in our bridge were the javax.faces.ViewState input element was looked up by name instead of using the utility function lookupViewStateElement(). The function was introduced when we discovered that IE9 fails to look up the elements by complex names (such when the name contains dots).

Even if we fixed the source of the problem in our bridge the issue is not completely fixed. We need to prepare a patch for Mojarra, patch that will modify the lookup by name used in Mojarra's bridge with a function that will iterate over the form elements to find the input element that holds the view state key.

We already provided a similar patch for Myfaces.

Attached patch for Mojarra built off revision #10252 (trunk at 2012-07-09 20:39:26 +0300).

The full fix needs changes to both ICEfaces JavaScript in icefaces.jar and jsf.js in javax.faces.jar. Mircea can provide an ICEfaces patch (for support to apply to their branch) as well as a patched javax.faces.jar, but we need to know which version of mojarra to patch.

Please provide information on which version of mojarra is required.

Created Mojarra bug: http://java.net/jira/browse/JAVASERVERFACES-2482 .

I tested this using IE 9 and using the Developer console to switch the browser modes (IE 9, 8, 7) as well as the the document modes (standards, quirks). I could only reproduce the problem in the test case when the document mode was set to "Quirks". Then I would see that additional ViewState parameters were being included in the form submission.

To confirm, I used the debugger to show that the following line in jsf.js doUpdate():

var field = stateForm.elements["javax.faces.ViewState"];

is returning the field as "undefined" when running IE in Quirks mode. Not really sure why this is. Looking at the form, it appears the element array is there. And checking for the existence of other form elements using the exact same syntax works. For example:

var buttonOne = stateForm.elements["button1"];

returns the appropriate input element. So it must not like something about "javax.faces.ViewState". As Mircea noted, perhaps the dots where throwing it off but I tried a stand-alone script that simply iterated through a form and it was able to find the hidden input text name "javax.faces.ViewState" so there must be more variables involved.

In any event, when it can't find a ViewState it goes ahead and appends a new one - which is why we see the multiple ViewStates being accumulating with each submission. The patch avoids this by checking to see if the ViewState is found and, if not, before adding a new one, tries an alternate approach of iterating through and comparing the each form.element.name with the incoming ViewState value.

Created new issue http://java.net/jira/browse/JAVASERVERFACES-2500 that will hopefully be targeted to Mojarra 2.1.11.