Attached source code and built war file to reproduce issue.

Steps to reproduce:

• Load app, at the top of the page there are four commandButtons, each one will activate its respective tab.
• The tabSet is loaded as all disabled by default.
• Click on the "Activate Tab One" button and the "Activate Tab Two" button.
• Tab One and Tab Two are now shown as being selectable, but their content is not shown.
• Try and select either one of these tabs, nothing happens.
• Refresh the browser, the tabs content is now shown and they can be selected.

Bugs about dynamic properties are generally caused by the change of property not causing a sufficient Dom update. Here, it's likely that the tapPane renders some disabled style, but that the tabSet's JavaScript still needs to execute to make the relevant JavaScript objects know it's disabled. Forcing the JavaScript to update, given some property change that's not rendered in the script tag is generally accomplished by adding the property to the hash field.

I attempted again, and had greater success but my results appears to indicate that we need to send disabled property per-tab rather than as a hash.

After adding:
if (oldJSFProps && oldJSFProps['hashCode'] != jsfProps['hashCode']) {
var tabs = context.getComponent().get('tabs');
for (var i = 0; i < tabs.length; i++)

}

to ice.ace.tabset.updateProperties, I discovered that while the attached updateProperties script is run for every tabset render, it is run before the update is applied to the DOM. This means that though we are trying to inspect which tab has been disabled/enabled, and carry over the change into JS, the JS is running before the change to the style class, and that style class change is the one indication on the DOM of which TabPane is responsible for the hash code change. Without sending per-tab information, or running some sort of event following the DOM update, I'm not sure how this will be possible.

Problem now lies with the DOMEventHandler for the tabset. It's eating the events for the newly enabled tabs.

DOMEventHandler required that the DOM element causing the event was the child of one of the tabs elements that was initialized with tabset. The tab has been updated since the initialization due to the disabled style class changing on the server, so the DOMEventHandler didn't find a parent tab and ate the event.

When setAttributeConfig('disabled',

, true) was used to configure the tab JS object with the updated element, the DOMEventHandler passed the events on to the tab correctly, however it now appears the tab DOM element hasn't been configured with all the YUI Tab JS synthetic events. YUI sure doesn't make anything easy.

Not sure how to rebind these events to the new DOM element so, to avoid the problem above entirely, I'm attempting to modify the way in which tabs are disabled to avoid the DOM update, and let the tabset JS solely handle tab disabling.

I'd attempted to remove the tabs following the DOM update and adding the new DOM element as a 'new' tab at the old index, however the out-of-sync Tab object cannot be removed from the tabset either, due to an error related to the tabset attempting to remove the absent DOM element from its subtree.

I've made some success with the last technique I mention above.

The tabset diffs the updated set of disabled indexes with old one (if one exists) and uses JS to disable the individual tabs.

This solution unfortunately allows the selectedIndex to be loaded at the tabset construction, even though it may be disabled. This may be able to be corrected.

There may also be styling difference between this client-managed approach and the previous server-managed disabled styling.

The styling issues I mention above aren't of concern. The fixed version looks fine.

However the on-construction selection of the selectedIndex that occurs before our JS can apply the disabled property, will be very problematic. I don't see how this could be avoided without large modifications to the YUI code, or fixing the larger issue using yet some other technique.

The issue is we want to initialize the tabs with the disabled style class so the YUI construction won't do an initial selection. However later when we remove that disabled style class and enable the tab, we don't want an update (that kills our events), or that update has to somehow play nice with YUI, and rebind the new DOM element.

ICE-7627 - Partial fix for dynamic tabpane disabled issues. Using JS-managed state as DOM update ruined the existing Tab object, and I could not find a way to rebind the Tab object to the new DOM element; and removing the now DOM-less Tab from the TabView caused an error, so a newly created Tab object could not be added in its place. This change to JS initialized state however has introduced another problematic behaviour, that the selectedIndex is always loaded at tabset creation even though it is disabled by further constructor calls shortly after. Either the disabling will need to occur at Tab creation, during TabSet creation, or eventually the old technique will need to be used, and must elegantly update or replace the existing Tab object, rather than breaking it.

Reassigning to Mark for eventual revision to fix selectedIndex initialization.

More extensive YUI knowledge will be required to gracefully update/replace the Tab object that has been destroyed by the DOM update, or modify the TabView construction so that my technique of JS disabled initialization occurs soon enough to prevent the invalid initial selection.

Added custom styling and backported change to 2.X EE maintenance.

Fixed again in this other branch.

Revision #27275
ICE-7627 - Backporting tabset dynamic disabled attribute fix.