Verified that this issue occurs only when running with MyFaces and not Mojarra. It appears that the component is not being state saved/restored, and so is losing some state that it needs when changing tabs.

The Field in question that's coming back null each lifecycle is in TabSetMeta:
@Field(javadoc="Maintains the record of which tabs have been visited")
private List visitedTabClientIds;

Here is the dom update comes to the browser, when the user clicks to go to the second tab:

<update id="form:tabSet_safe_0"><![CDATA[<div id="form:tabSet_safe_0"><div class="ui-tabs-panel ui-widget-content ui-corner-bottom" id="form:pane2" role="tabpanel" tabindex="0"><span id="form:pane2Body">Second Body</span></div></div>]]></update>

One would expect a closing of tabSet_safe_0, and the new tab content to be in tabSet_safe_1, but since visitedTabClientIds is null, it loses the history of having used tabSet_safe_0, and so tries to recycle it, which the javascript doesn't handle.

Audited the subversion commits to the ACE generator, but nothing in it has changed in that area. Seems to indicate we may have made core changes that might affect state saving. It wouldn't seem likely, but just for completeness, tested with rolling back the recent change to tabset.js, but that had no effect.

Ran the tabset regression suite, with MyFaces, and found that it does work, so this is specific to the showcase application.

Identified key commits to MyFaces jars, core changes, and showcase application, and worked back through them to see when this problem started. It's revision 29753, which is for:
ICE-7283 : Showcase templates should not have ids on non-component markup

My current theory is that now that the div(s) are h:panelGroup(s), the id is the component id, and maybe now we have duplicate ids. Although there should be existing functionality to report that if it's the case.

Tried changing the ids to for sure be unique, and also tried to remove the ids. Neither fixed the problem, and both broke the styling of the app, since the styling highly depends on ids and less on class names than one would hope, especially in this css file:

icefaces3/samples/showcase/showcase/src/main/webapp/resources/css/demo_template.css

We need to essentially revert ICE-7283, and then remove the ids from all the divs, and then updating the css to not select based on those ids but instead style classes which would be added to the divs.

Okay, please implement using h:panelGroups (without IDs specified), and changing the CSS to use classes instead of IDs. Then we'll retest to see if MyFaces like it that way or not.

r29905 - Changed all the panelGroup IDs to be styleClass instead and modified to the CSS to match. I kept the IDs in there though in case some backend code or components rely on them (for example for a find component lookup) since that seemed like the least destructive approach.

Re-assigning to Ken to delegate for re-testing.

Changing all h:panelGroup components, which had ids, to div tags without ids, worked. Merely removing the ids from the h:panelGroup(s) did not work.

icefaces 3 trunk
Subversion 30015

r30023 - Slight change to div/panelGroup. main-template.xhtml was using panelGroups without layout="block" (so a div wasn't rendered out) but that was changed to a plain div, which may have been causing the IE9 style issue.

r30027 - Reverted r30015 at Ken's request, so we are back to all h:panelGroups with no divs. It will cause problems with the MyFaces tabs but is a better practice for users looking at the code.

When we next look into this, see if it's still happening, and check if the view state key is being submitted. That shouldn't be a problem due to the fixviewstate javascript. This behaviour is eerily similar to a maintenance branch tabSetProxy issue that was due to the view state key not being submitted, which was fixed by backporting the fixviewstate javascript.

There's no difference between what is being submitted for MyFaces and Mojarra.
The difference between Mojarra and MyFaces is that with MyFaces, TabSet.clearInitialState() is getting called on every postback in the middle of rendering by saveState which is called from context.getApplication().getStateManager().getViewState(context) which is called from org.icefaces.impl.event.FixViewState.ScriptWriter.encode. State saving is supposed to happen after rendering, not in the middle of it. If I disable this FixViewState rendering code, then the problem goes away.
With Mojarra the clearInitialState() method is not called at all in the postbacks. Possibly getViewState may not trigger state saving.
It should be noted, that if I click on the TabSet and get the Overview, that is a GET request. Changing the tabs there works. Clicking on Server tabs and then back again will lead to tab changes not working in this Overview. So it's not that any one example is broken, it's that when the TabSet is created from a GET it will work, and when it is created on a POSTback it does not work. Clicking between TabSet examples results in a dynamic ui:include that creates a new h:form and new ace:tabSet on the POSTback. The FixViewState code won't call getViewState on a GET, just on a POSTback.

Confirmed that issue has been resolved within showcase w/myfaces and ace:tabSet with myfaces regressions re-run (Also confirmed to pass manually).

Must have lost the commit comment.

Added hack to work-around the state saving issue. Probably wouldn't work with serialised/compressed/client-side state saving.

icefaces3 trunk
Subversion 31475