Attach test case that shows this issue.

Steps:

• load welcomeICEfaces.jsf
• Click on the 'My Second Server Tab' tab.
• A confirmationDialog is shown, click Yes on the dialog. Tab two is now shown.
• In the second tab click the 'Go to the first tab' the first tab is now displayed (active).
• Click on the 'Execute @all' button. The confirmationDialog is now shown but it shouldn't be.

r45786: added utility function to clear the selected index state of ace:tabSet.

The only way to fix this is to add a utility function to manually clear the selected index state in the tabset whenever it's called. It's not possible to fix this in an automatic way, where the app developer wouldn't have to do anything, since the very features of the tabset that allow the component to change tabs in an alternative way, such as by using a confirmation dialog, are the same features that cause this issue. At first, I tried to fix this issue in the server side by forcing the renderer to only decode the request if the source was the tabset, but that didn't allow the confirmation dialog to be the one that actually changed the tab. I also tried to force the 'yti' field (which contains the selected index state) to be cleared after the request, but that cleared this field before the request from the confirmation dialog was made, and it wasn't possible to change tabs with the confirmation dialog. Therefore, the only way around this, is to have the app developer clear the selected index state after changing tabs in an alternative way, because the normal clean up procedure has been disrupted.

This utility function is ice.ace.tabset.clearSelectedIndexState(clientId) and takes the client ID of the tabset. In the test app, it's only necessary to add this attribute to the f:ajax tag of the 'Yes' and 'No' buttons in the confirmation dialog:

onevent="function(data) { if (data.status == 'success') ice.ace.tabset.clearSelectedIndexState('iceForm:serverTabSet'); }"

r45787: committed fix to the 3.3 EE maintenance branch as well.

I just tested the issue again, using the 4.0 trunk code and the 3.3 EE maintenance branch code, and this fix is working well for me every time. The problem was that the test page for 3.3 didn't have the onevent attributes that I mention above, so I just added them to the test page at revision 42646.

Verified ICEfaces EE-4.1.0, Tomcat 8, IE 11, FF 43, Chrome 50.