TabSheet behavior

This is question regarding the Vaadin TabSheet component. If you close a selected tab the first tab is selected. That’s fine if you don’t have many tabs. But if you do have many open tabs so that a scroller is shown in tab bar there is the case that the first tab is selected but the tab bar is not scrolled to show this tab:


http://img21.myimg.de/closeTabc5a15.png


http://img21.myimg.de/TabClosedfd925.png

In the worst case you have an empty tab bar:


http://img21.myimg.de/manyTabsClosed6cdb2.png

Is this the intended behavior of the TabSheet component?

The documentation describes this behavior:

“Removes a component and its corresponding tab. If the tab was selected, the first eligible (visible and enabled) remaining tab is selected.” - https://vaadin.com/api/com/vaadin/ui/TabSheet.html#removeComponent(com.vaadin.ui.Component)

I agree that it could be improved to scroll to the selected tab. Or, maybe, a neighbor tab could be selected after removing, instead the first.

Yes,
Ticket #6876
is about this.

If the neighbour left tab (to the being closed one) is to be selected, which seems to me to be the most intuitive behaviour, here is the code I use:

tabLayout = new TabSheet(); tabLayout.setCloseHandler(new TabSheet.CloseHandler() { @Override public void onTabClose(TabSheet tabsheet, Component tabContent) { int positionToBeSelected = 0; if (tabsheet.getSelectedTab().equals(tabContent)) { int position = tabsheet.getTabPosition(tabsheet.getTab(tabContent)); if (position > 1) { positionToBeSelected = position - 1; } } tabsheet.removeTab(tabsheet.getTab(tabContent)); if (positionToBeSelected > 0) tabsheet.setSelectedTab(positionToBeSelected); } }); Sure, we have two subsequent selections here, one made by private updateSelection() method within TabSheet and second by the custom code. If, however, nothing heavy is performed e.g. within selection listeners, one can’t notice the first selection at all.

What happens if you select the neighbor tab
before
removing the current tab? Wouldn’t that avoid the “two subsequent selections” you refer to since the tab being removed would no longer be the “selected” tab?

Whatever I do
before
removal will be null and void, as afterwards (on removal) the TabSheet class will trigger its hardcoded logic (select the very left tab, if exists and visible), which will override whatever earlier done.

So this part of the documentation is incorrect? "
If the tab was selected
, the first eligible (visible and enabled) remaining tab is selected." If so, then this is a bug, not just a request for enhancement or a different behavior.

Well, it depends on what they mean by
the first eligible (visible and enabled)
.
As I understand it,
first
means
first, counting from left
. If so, the TabSheet works as described in doc and there is no bug in this - by the way - annoying default, non-customizable behaviour.

I’m having trouble getting my point across but here goes again…

If you select the neighbor tab first and then proceed to remove the original tab, the tab you will be removing is no longer the selected tab. Thus, the part of the documentation after the “If the tab was selected,” should not be applicable because the tab being removed is not selected and “the first eligible (visible and enabled) remaining tab” should have no part in the removal.

Do you follow what I’m saying? If the documentation is correct then the converse should also be correct - removing a non-selected tab should not alter the current tab selection.

You are absolutely right. I must have had an intelectual depression.

tabLayout = new TabSheet();
tabLayout.setCloseHandler(new TabSheet.CloseHandler() {
    @Override
     public void onTabClose(TabSheet tabsheet, Component tabContent) {
         if (tabsheet.getSelectedTab().equals(tabContent)) {
             int position = tabsheet.getTabPosition(tabsheet.getTab(tabContent));
             if (position > 1) tabsheet.setSelectedTab(position - 1);               
         }
         tabsheet.removeComponent(tabContent);
     }
});

Nice refactor! Your code is definitely cleaner. You certainly came out of that intellectual depression. Perhaps you could add your workaround to
Ticket #6876
Johannes found for us above. New activity on the ticket may prompt someone at Vaadin to alter the lousy default behavior and close it out.

Sure, I’ll do.
Darrell, I’v forgotten to thank you for your friendly curiosity :slight_smile: