Search Issue Tracker
Won't Fix
Votes
1
Found in [Package]
2.1.0-preview.1
Issue ID
1309684
Regression
No
Scene visibility toggles visible when entering Play Mode for TMP SubMeshUI that is in a Prefab and is invisible
How to reproduce:
1. Open the user's attached project("BugProject.zip")
2. Load "SampleScene"
3. Make sure "Canvas" is toggled invisible in the Hierarchy
4. Enter Play mode
5. Notice "TMP SubMeshUI" has been toggled visible again
Expected results: The TMP SubMeshUI stays invisible after entering Play Mode
Actual results: The TMP SubMeshUI becomes visible after entering Play Mode
Reproducible with: TMP 2.1.0-preview.1, 2.1.3 (2019.4.20f1), 3.0.0-preview.1, 3.0.3 (2020.2.3f1, 2021.1.0b5, 2021.2.0a4)
Not reproducible with: TMP 2.0.0 - 2.0.1 (2019.4.20f1)
Could not test with: TMP 1.5.3 (2018.4.32f1) (No scene visibility option yet)
Note: Scene visibility stays toggled visible again for the TMP SubMeshUI when exiting Play Mode
Add comment
All about bugs
View bugs we have successfully reproduced, and vote for the bugs you want to see fixed most urgently.
Latest issues
- [Android] Volume level of the same audio file is different on Samsung Galaxy Tab A8 between 2023.3.0b3 and 2023.3.0b4
- ‘Expected end of value’ warning occurs when a property declaration includes five or more variable references
- Tags window completely breaks and throws Exception errors when Adding a Tag to a GameObject
- Crash on BurstCompilerService::CompileAsync when entering Play mode in a specific scene
- InvalidOperationException when using Game Camera Preview in Scene window with a custom RenderGraph pass
Resolution Note:
This bug comes from the fact that temporary non-interact-able objects are both visible and select-able in the Hierarchy. When entering play mode, the temporary child objects are destroyed and recreated, losing any user-set values. This isn't specific to visibility flags. Static flags, tags, icons, etc will be lost as well. Adding special handling the scene visibility rendering code to handle this case isn't clear cut, as there are valid arguments that doing so would be a regression to expected behavior (eg, a user can select and modify this gameobject, therefore the systems should work as designed).
Given the low user pain and ambiguity of a "correct" fix, will resolve this as WontFix.