Details
-
Type:
Bug
-
Status: Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 3.0
-
Fix Version/s: 3.0.1, EE-3.0.0.GA
-
Component/s: ACE-Components
-
Labels:None
-
Environment:Chrome, Firefox, IE, TomCat 7
Description
To reproduce:
1. Create a test case from attached source code.
2. Launch application and click on change tab command link
Notice:
- Server log will display messages:
Action Event begin
Old Index value: 0
New index value: 1
Action Event end
- Tab1 will switch to Tab2 in the browser and display its content
3. Click on change tab for the second time.
Notice:
- Server log will display messages:
Action Event begin
Old Index value: 1
New index value: 2
Action Event end
- The content of tab 2 will disappear and it will remain selected in the browser.
4. Hit refresh button in the browser
Notice:
- Tab 2 will switch to Tab3 in the browser and display its content.
5. Click on change tab link. Behavior of steps 2-4 will be repeated.
Other notes:
Tried sample code with different parameters of the cache attribute for tabs without any success.
No errors were present in the JavaScript console or server log during the test.
Activity
- All
- Comments
- History
- Activity
- Remote Attachments
- Subversion
Investigation of the code paths executed from all the relevant scenarios showed that some re-organisation was necessary to facilitate all of the proper tab activation and opacity code to run in every case.
SERVER-SIDE
Regular click tab
tabChange: ENTER
tabChange: EXIT end
doOnSuccess: ENTER
doOnSuccess: EXIT
==> WORKS
Click tab, listener switch to tertiary tab
tabChange: ENTER
tabChange: EXIT end
updateProperties: index mismatch BEFORE set activeIndex
tabChange: ENTER
tabChange: EXIT suppressTabChange
updateProperties: index mismatch AFTER set activeIndex
updateProperties: index mismatch BETWEEN set contentVisible/active AND opacity
==> WORKS
Click tab, listener revert tab
tabChange: ENTER
tabChange: EXIT end
updateProperties: index mismatch BEFORE set activeIndex
tabChange: ENTER
tabChange: EXIT suppressTabChange
updateProperties: index mismatch AFTER set activeIndex
updateProperties: index mismatch BETWEEN set contentVisible/active AND opacity
==> WORKS
Other comp other form
updateProperties: index mismatch BEFORE set activeIndex
tabChange: ENTER
tabChange: EXIT suppressTabChange
updateProperties: index mismatch AFTER set activeIndex
updateProperties: index mismatch BETWEEN set contentVisible/active AND opacity
==> WORKS
Other comp same form full submit
updateProperties: index mismatch BEFORE set activeIndex
tabChange: ENTER
tabChange: EXIT suppressTabChange
updateProperties: index mismatch AFTER set activeIndex
updateProperties: index mismatch BETWEEN set contentVisible/active AND opacity
==> WORKS
CLIENT-SIDE
Regular click tab
tabChange: ENTER
tabChange: EXIT end
==> WORKS
Other comp other form
updateProperties: index mismatch BEFORE selectTab
tabChange: ENTER
tabChange: EXIT suppressTabChange
updateProperties: index mismatch AFTER selectTab
==> WORKS
Other comp same form full submit
updateProperties: index mismatch BEFORE selectTab
tabChange: ENTER
tabChange: EXIT suppressTabChange
updateProperties: index mismatch AFTER selectTab
==> WORKS
icefaces-3.0.x-maintenance
Subversion 28366
trunk
Subversion 28388
The problem can be reproduced if instead of
<h:commandLink value="change tab" actionListener="#
<f:ajax execute="@this" render="@form"/>
</h:commandLink>
next are used:
1. <h:commandLink value="change tab" actionListener="#{sampleBean.changeTab}
" />
2. <ice:commandLink value="change tab" actionListener="#
3. <ice:commandLink value="change tab" actionListener="#{sampleBean.changeTab}
">
<f:ajax execute="@this" render="@form"/>
</ice:commandLink>
Just keep clicking on "change tab" link and clicking on tab itself and eventually you will end up with two selected tabs at the same time. You will also see that a content of the currently selected tab will disappear during this operation.
There are four main scenarios:
1. When the user clicks to change tabs, the form doesn't validate, and the tabSet is set to remain on the old tab
2. When the user clicks to change tabs, the application uses a tabChangeListener, and forces it to remain on the old tab
3. When the user clicks to change tabs, the application uses a tabChangeListener, and forces it to go to a tertiary tab
4. When the user clicks on some other component, the action[Listener] changes the tabSet's selectedIndex
Both the QA test app and the support case are scenario #4. Fixing that won't necessarily fix any of the other scenarios. Not that they've necessarily been tested nor shown to be broken.