TabContainer resets visibility to first tab in editor

[chucklepie]

Godot version

3.3 stable

System information

linux mint

Issue description

You're working on a single tab and need to switch to another scene or code. When you go back, whatever tab(s) you had selected is/are removed and the first one is selected.

This is really very annoying and forces you to constantly update visibility in the editor or temporarily move your tab (if you are editing just one) to the very top.

btw, It wouldn't be 'as bad' if you could drag items down (but still a pain) but Godot stops you from moving items to the bottom of the list because when at the bottom it eithier changes level to one before or one after, it will not let you move a sibling to be the last one.

Steps to reproduce

1. create a tab container with multiple tabs
2. select one tab
3. change to another open scene then go back

Minimal reproduction project

game.zip

[YuriSizov]

Can you demonstrate what you do with a video? Those steps are not enough to reproduce the issue. Changes to the visibility and selection in the scene dock are preserved when you switch between the scenes.

[chucklepie]

Sure. I didn't because I presumed it was simple and in case it was already a case. Give me a few minutes.

[chucklepie]

@pycbouh
In the video, TabDemo is selected and visible, switch scene, switch back and it's now at the first. I repeat with multiple and the same happens.

bug-tabcontainer2.mp4

[timothyqiu]

The supposed way of switching tabs is changing the Current Tab property of TabContainer I think.

The editor is trying to re-sync the scene with Current Tab.

[Calinou]

btw, It wouldn't be 'as bad' if you could drag items down (but still a pain) but Godot stops you from moving items to the bottom of the list because when at the bottom it eithier changes level to one before or one after, it will not let you move a sibling to be the last one.

You can select a node and use Ctrl + Up/Ctrl + Down to move it in the Scene tree dock. Using the keyboard is more precise than using drag-and-drop for this kind of stuff.

[timothyqiu]

btw, It wouldn't be 'as bad' if you could drag items down (but still a pain) but Godot stops you from moving items to the bottom of the list because when at the bottom it eithier changes level to one before or one after, it will not let you move a sibling to be the last one.

You can make the node last child by dropping it on the parent node. This bothered me for a long time too :)

[chucklepie]

So is this a bug, I'm not sure by the comments, seems like it to me?

btw, sorry for the extra addition, Sometimes sneaking in a question here is the best way to get answers as the UI is sometimes complex to use. In other IDEs when you drag you can move your move your mouse left/right at the relevant points and it indents the control for you. Would be nice.

[YuriSizov]

In the video, TabDemo is selected and visible, switch scene, switch back and it's now at the first. I repeat with multiple and the same happens.

Do you have a tool script that interacts with the tabs, per chance? Can you reproduce this behavior with a simple scene you create from scratch? Also, can you try 3.3.2? I tried to do the same things and it didn't change the visibility or selection no matter what.

[YuriSizov]

The supposed way of switching tabs is changing the Current Tab property of TabContainer I think.

The editor is trying to re-sync the scene with Current Tab.

I wanted to point it out too, but this is not about the tab you see when you run the scene, it's about the editor visibility state. Which for whatever reason gets reset for chucklepie when they switch the scenes, which shouldn't happen.

[timothyqiu]

@pycbouh In a MarginContainer, you can still adjust the margin / size / anchors of child controls in the editor, but these properties will reset when they switch scenes. I think it's the same here for a TabContainer, this container manages visibility instead of margin.

[YuriSizov]

@timothyqiu Except... 🙃

2021-07-27_16-16-55.mp4

[timothyqiu]

@pycbouh I could easily reproduce the issue until I followed your steps in the video, and now I can never reproduce it again 😂

... and I have no idea why :(

[chucklepie]

@pycbouh , @timothyqiu , and anyone else...
game.zip

Find attached solution with no code and as simple as it gets. If it doesn't do it for you, then I guess there's a Linux Mint Mate bug ;-)

1. Open up the tscn file
2. Make 'tabconfig' visible and 'tabachievement' not visible, no need to save, but it doesn't matter either way
3. Click on '+' to create a new scene, no need to save anything either
4. go back to the scene and it has reverted.

You can swap 2 and 3 if you want, it doesn't matter, it's simply the act of switching scenes.

[VincentSinel]

Hi, This problem still in place with Godot 4.1.1 version. I'm on Windows 10 and the same can be see with standard and mono version of godot.

TabsRefreshed.mp4

[kitbdev]

In Godot v4.2.beta2
For me it doesn't happen when switching scenes, but this happens in other places.
It also happens with both TabBar and TabContainer.

• Running the scene has the current tab set to 0.
• Setting current_tab then saving, closing, and reopening the scene has it set back to 0.
• Instantiating a scene with a TabBar or a TabContainer into another scene, it also shows as 0. Setting 'editable children' on shows that the current_tab is set to 0.

[kitbdev]

Checking the .tscn file, current_tab is not being saved at all.

[node name="TabContainer a2" type="TabContainer" parent="."]
layout_mode = 0
offset_left = 421.0
offset_top = 348.0
offset_right = 776.0
offset_bottom = 583.0
clip_tabs = false
drag_to_rearrange_enabled = true
tabs_rearrange_group = 1

[AThousandShips]

It is indeed an editor only property, not stored

[kitbdev]

Do we know why?
Checking the commits for current_tab's PROPERTY_USAGE_EDITOR, it seems it dates back all the way to the first commit 10 years ago.
There isn't a reason it should be editor only, right?

[AThousandShips]

I don't think it is desired to set which is the selected tab in that way, why should it be stored otherwise? No other thing like that is stored, like which item is selected in a list

[kitbdev]

For TabContainer, current_tab is more like changing its state entirely than a transient selection. It's more like an OptionButton's selection than an ItemList's selection. In ItemList, the selection can't even be set in the editor.

Otherwise if you want a TabContainer to start off a different tab than the first, it needs a script to set it.

Also, I tested removing the editor only flag and it causes index out of range errors because it needs the tabs to be added first. I think this is more likely the reason it was editor only. Maybe this could be fixed in TabBar by loading it last, but not for TabContainer since it needs children first. We would have to allow current_tab to be out of range or something. So I'm not sure how to change it.

However, if it is desired to act this way, the docs on current_tab should be updated to prevent misunderstandings.
And it means the original issue about switching scenes is caused by the scene reloading when it doesn't need to.

[KoBeWi]

The problem with resetting current tab is that the tab container changes visibility of its children. If you save scene with tab > 0, a different control from the first one will be visible. This means that when you reopen the scene and save, it will cause scene changes without any user action.

However not saving the current tab is convenient, because you can freely edit content of any tab. If the current tab is saved, you need to remember to reset it or do it using script (which causes double tab switch).

It's easier to store tab index than to fix the problem with incorrect visible control. Even if the current behavior is convenient, it's unexpected and has a bug.