Search Issue Tracker
Won't Fix
Won't Fix in 2023.3.X
Votes
0
Found in
2022.2.15f1
2023.1.0b12
2023.2.0a9
2023.3.0a3
Issue ID
UUM-33143
Regression
No
The expansion behavior is not the same as in CSS when used with VisualElements
How to reproduce:
1. Open the attached project "UIToolkit Styles Bugs.zip"
2. Open Assets/Expansion.uxml
3. Select "#expand-to-child-size" in the UI Builder Hierarchy
Expected results: VisualElement's size is the same as its child
Actual results: VisualElement's size is not the same as its child
Reproducible with: 2020.3.47f1, 2021.3.23f1, 2022.2.15f1, 2023.1.0b12, 2023.2.0a9
Reproducible on: Windows 10
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
- Out-of-bounds memory access with multiple CanvasRenderers under a Canvas when using Mesh API
- Inspector tries to access file after it was deleted when the file was locked in Inspector window
- Changing Transform values in Search window Inspector loses focus while dragging and stopping mouse without releasing dragging action
- Saving changes on the dirty VFX Graph during the Play mode throws "The referenced script (Unknown) on this Behaviour is missing!" warnings
- VFX Graph Debug Info overlaps the "Initialize" block debug info by default
Resolution Note:
Thanks for the report. While we try to stay as close as possible to CSS, we don't guarantee exact same behavior and defaults.
In this case, there's no bug, other than inconsistency with CSS perhaps. The 50px padding of the parent is forcing the #expand-to-child-size to be 0 height. Without that padding, the #expand-to-child-size would indeed expand. The shrink=0 on #expand-to-child-size only applies when being flex-layouted with other siblings that wish to take up more space than available.
We may address this inconsistency with CSS in the future, but we now also have to contend with potentially breaking existing USS uses in existing projects that now rely on current behavior. It's not a simple as fixing this one bug.
Resolution Note (2023.3.X):
Thanks for the report. While we try to stay as close as possible to CSS, we don't guarantee exact same behavior and defaults.
In this case, there's no bug, other than inconsistency with CSS perhaps. The 50px padding of the parent is forcing the #expand-to-child-size to be 0 height. Without that padding, the #expand-to-child-size would indeed expand. The shrink=0 on #expand-to-child-size only applies when being flex-layouted with other siblings that wish to take up more space than available.
We may address this inconsistency with CSS in the future, but we now also have to contend with potentially breaking existing USS uses in existing projects that now rely on current behavior. It's not a simple as fixing this one bug.