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
- Mono Windows Builds don't produce full log callstacks when generating logs
- AssetBundles fail to load when running in Built Players for Mobile Devices
- UI elements with text gets bigger and grey when Player window is moved to another screen with different resolution
- System name accepts multiline text but crops it on confirmation, duplicates input, and shrinks the field when empty
- UI element scale and position are wrong in project build when DRS is changed with HDR and Software Dynamic Resolution enabled
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.