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
- Crash on SortByExecutionOrder when interrupting the .androidpack import process
- ShaderGraph tab header changes the icon to the VFX Graph icon when ShaderGraph and VFX Graph with the same name are both opened
- The Build Profiles window has usability issues when the panel takes up less than 30% of the screen width
- Inconsistent ShaderGraph RGBA channels compared to the Inspector when "Alpha Is Transparency" is used
- Crash on "The GUID inside 'Assets/asset.png.meta' cannot be extracted by the YAML Parser." when opening the project
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.