Search Issue Tracker

By Design



Found in


Issue ID




UXML element parent and child size mismatch when the child element's width is set to Auto



Reproduction steps:
1. Open the attached “ReproProj” project
2. Open the “Assets/2023v6000-0-0f1.uxml“ file
3. In the Hierarchy window, expand the “#panel_background” element
4. Click on the “VisualElement” child element
5. Observe the Viewport window

Expected Result: The “#panel_background” and “VisualElement” are the same width
Actual Result: The “#panel_background” and “VisualElement” are not the same width

Reproducible with: 6000.0.0b1, 6000.0.4f1
Not reproducible with: 2021.3.38f1, 2022.3.30f1, 2023.3.0b10

Reproducible on: Windows 11 Pro, macOS 14.5 (reporter’s)
Not reproducible on: No other environments tested

- Reproducible in Standalone Player
- If the “VisualElement” element is resized even a bit, the “#panel_background” and “VisualElement” become the same size

  1. Resolution Note:

    We did multiples fixes to better conform with the css specification : In the process of fixing theses the result of a hierarchy where a parent depends on it's children intrinsic size (width/height = auto) and where the children have min/max expressed in percentage of the size of the parent has changed. This is an undefined behavior in css 2.0 and while the definition has been refined in css 2.1 (by ignoring the min/max in the beginning of the calculations) it remain that it is probably not the best way to specify the default size of an element.

    Before the fixes, the calculated intrinsic size of the children calculated for this undefine behavior was erroneous, filling the parent by accident and the max-value would effectively be the one limiting the size. Now, the calculated intrinsic size correctly represent the aggregated values of the padding, margin, border and content size of the children, but in the provided layout that size is too small for the max to have an impact horizontally.
    You can test what a web browser does with the same layout with the following link
    When tested in chrome and firefox we have a similar result as what we now obtain in the provided screenshot.

    To remedy those change, setting a default width other than auto for every element that have a child with a max-size expressed in percentage would probably get you the previous result. You could try with 100% (would let the max define the width of the parent) or the same % value as the current maximum. While theses option haven't been tried on my end, I think the "fixes" are probably done directly with your source asset and we will be happy to continue the conversation if you cannot achieve your desired goal with this method.

Add comment

Log in to post comment

All about bugs

View bugs we have successfully reproduced, and vote for the bugs you want to see fixed most urgently.