Ideally, the new tab contents would come in from the server, and then any animation from one to the other would run, or no animation, and no resiing down to an empty size would happen.

When using caching, and revisiting a cached previously visited tab, the tabs are all in the dom, so there shouldn't be flickering. That could be tested to see if it makes the flickering go away. Just as a data point.

I had hoped that ICE-6728 would resolve this, but most likely the change from YUI3 loader to YUI2 static loading was sufficient to change the dynamic of what's going on, that new investigation will be necessary. I'd still see if this is an issue of sequencing of operations.

Using the poc we can see that there is no flicker, even though there is in the showcase. This is because the caching property solves the problem. This indicates that the problem is in how we transition from tab to tab, with the latency of the ajax request to get the new tab content coming in the middle of the transition. If we re-sequence things to first get the new contents, then change to them and then remove the old contents, that might be best.

From the YUI tabview javascript, there's a hook called beforeChange that might be usable for pre-loading the new tab content in the browser. Or we might simply avoid the dom difference removing the old content, and have that done in javascript, after the transition.

I think we need to use some client-side JS sleight of hand to ensure the tab pane size doesn't change between removing old pane and loading new one.

r26771 - Fixed with refactoring to content transitions. Added opacity effect to contents left in tab while waiting for request to finish and complete transition.