Step 1 done. No need to change JS (ours or Yahoo's) so far. Just changed renderer to add disabled style class to Tab (<li>) element when a tab is disabled. When creating from pre-rendered HTML, YUI uses style classes (among other things) as config. params. (We were already using the disabled style class, but only when the whole tabset was disabled.) See screenshot-1.

The default for active index and active tab is null. (See screenshot-2.) And YUI won't let you activate a disabled tab. (See sceenshot-3.) So in this case it doesn't matter what active index you are trying to set. It just has no effect.

Note that in the test case the tab contents flash first because clientSide="true".

Modified: C:\svn\ossrepo\icefaces-ee\patches\icefaces-ee-sf-10754\icefaces\ace\component\src\org\icefaces\component\tab\TabSetRenderer.java
Completed: At revision: 27359

After changing the backing bean to sync the selected index, the test app. works as expected when clientSide="false". When clientSide="true", the tabs are enabled and selected properly. However, the contents are not shown. Why?

There is actually a JS error thrown behind the scenes by YUI if an invalid active index is being set.

When the active index is valid but the tab pane is disabled, active index should take precedence and the tab pane re-enabled. (As specified in tabSet TLD doc for disabled attribute, "If true then all tabs except the active one will be disabled and can not be selected."

After these changes switching tabs and content display work OK if using the command buttons, but clicking the tabs still doesn't work, as if there were no click listeners anymore.

Modified: C:\svn\ossrepo\icefaces-ee\patches\icefaces-ee-sf-10754\icefaces\ace\component\resources\org.icefaces.component.tab\tabset.js
Modified: C:\svn\ossrepo\icefaces-ee\patches\icefaces-ee-sf-10754\icefaces\ace\component\src\org\icefaces\component\tab\TabSetRenderer.java
Completed: At revision: 27415

As per decision in meeting, reverted back to having disabled attribute override active index attribute.

Tested dynamically toggling tab pane disabled attribute from true => false => true. Tab change working initially, but no more tab change event after re-enabling a disabled tab pane. Could be bug in YUI, or could be our JS or DOM updates trample over the listener.

Modified: C:\svn\ossrepo\icefaces-ee\patches\icefaces-ee-sf-10754\icefaces\ace\component\resources\org.icefaces.component.tab\tabset.js
Modified: C:\svn\ossrepo\icefaces-ee\patches\icefaces-ee-sf-10754\icefaces\ace\component\src\org\icefaces\component\tab\TabSetRenderer.java
Completed: At revision: 27422

ICE-7627 was the original reported issue where it wasn't possible to dynamically change the disabled attribute of a tabPane. It took a browser refresh to show the tab as enabled and therefore selectable.

DOM update stomped over the tab node including its listener set up by YUI. No way YUI would know someone else is trashing its HTML behind its back. As I said many times before, this is a ubiquitous problem for nontrivial components and properties, whether using YUI or jQuery. updateProperties() can't possibly handle all property change scenarios, all interactions between properties (e.g. disabled and active index in this case), all subsequent layout, CSS and listener changes ...

Changed to re-initialize tab view when client side is true and when at least one of the tabs changes its disabled state. Working. See video at http://screencast.com/t/peiskaQYFs4.

Modified: C:\svn\ossrepo\icefaces-ee\patches\icefaces-ee-sf-10754\icefaces\ace\component\resources\org.icefaces.component.tab\tabset.js
Completed: At revision: 27436

Can't apply changes to icefaces-ee-2.0.0-dev branch. Versions in icefaces-ee-2.0.0-dev too different. Looks like some other JIRA changes haven't been applied there yet.

From Arran:

The latest issue they are having now is that when the client-side tab is changed and they try and make a tab change on the server side, the server-side action isn't displayed on the client side.

Try something like this:

function selectTabFromServer(clientId, index) {
var callback = function (tabset)

;
ice.component.tabset.getInstance(clientId, callback);
}

But there may be problems if client side obejcts and states (e.g. JSContext) are not kept in sync.

From Arran:

Perfect, that works much better, thanks. This looks to help the latest issue they have.

From Arran:

The customer has found an issue when they are disabling or enabling a tab and also trying to select it or another tab in the same call. When this occurs it throws a JavaScript error: "tabset is undefined". This seems to occur only when they are also toggling the disabled attribute. It doesn't seem to cause the component from working correctly after though, at least in my tests so far.