Details
-
Type:
Bug
-
Status: Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 3.1.0.BETA2
-
Fix Version/s: 3.2
-
Component/s: ACE-Components, Sample Apps
-
Labels:None
-
Environment:ACE
-
Affects:Sample App./Tutorial
Description
TabSet - Server Side - switching tabs doesn't load tab content for 2nd and third server tab; in order to load 2nd server tab, must go to 3rd server tab and go back to 2nd server tab; also, multiple tab selection occuring (see attached image)
TabSet - Proxy - switching tabs doesn't load tab content for 2nd and third server tab; in order to load 2nd server tab, must go to 3rd server tab and go back to 2nd server tab; also, multiple tab selection occuring (see attached image)
Activity
- All
- Comments
- History
- Activity
- Remote Attachments
- Subversion
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
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 markupMy 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.