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
- Symlinks are broken when a package which contains .xcframework + symlinks is added through Unity Package Manager.
- Crash on ApplyMaterialPass when opening a specific scene
- Memory leak when using Native Plugin in Windows IL2CPP Build
- [URP][Tutorial] Universal 3D Sample tutorial issues
- Gradle error: "...Unexpected error during link..." is thrown when building for Android and targeting API Level 34
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.