Details
-
Type:
Bug
-
Status: Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 3.2
-
Fix Version/s: 3.2
-
Component/s: ACE-Components, Sample Apps
-
Labels:None
-
Environment:Icefaces3/trunk revision# 31601 / 31613
Description
In showcase:
TabSet - Server Side: when coming first time to this page, the content of the tabSet is empty; must click on the first tab to enable its content (Firefox only).
This occurrs randomly, only when navigating first to the 'TabSet - Overview', and 'TabSet - Client side' pages and testing their functionality (screen shot attached).
Steps:
- load showcase in Firefox.
- navigate to 'TabSet - Overview', select one or two checkboxes, then select each of the tabs on this page.
- navigate to 'TabSet - Client Side' page, select each of the tabs.
- click on 'TabSet - Server Side'; page loads with none of the tabs selected, and no content displayed.
TabSet - Server Side: when coming first time to this page, the content of the tabSet is empty; must click on the first tab to enable its content (Firefox only).
This occurrs randomly, only when navigating first to the 'TabSet - Overview', and 'TabSet - Client side' pages and testing their functionality (screen shot attached).
Steps:
- load showcase in Firefox.
- navigate to 'TabSet - Overview', select one or two checkboxes, then select each of the tabs on this page.
- navigate to 'TabSet - Client Side' page, select each of the tabs.
- click on 'TabSet - Server Side'; page loads with none of the tabs selected, and no content displayed.
Activity
- All
- Comments
- History
- Activity
- Remote Attachments
- Subversion
To reproduce this issue is even easier, simply load the tabSet section in the showcase, then click to go to the Client example, and change the tab, and then click to go to the Server section. Essentially what's happening is that the two examples each have a tabSet component with the same clientId, which is causing them to share some state, when each expects a clean slate. It's not really clear to the system the difference between a postback that updates an existing component, versus a postback that uses dynamic ui:include to swap components that identify themselves identically. It should be an application best practice, and necessary practice, to give different ids to components that may take each other's place in a single postback.
To fix this specific issue I've changed the tabSet ids to be unique amongst the various tabSet examples. But likely it would be best for all of the form names in all of the examples to be unique.
icefaces3 trunk
Subversion 31622 [Committed with comment referring accidentally to ICE-8565]