Reproduction Steps
This issue can be reproduced with a tree that looks like:
- Frame
AutomaticSize = XY- UIPadding (w/ padding set on all axes to some offset values)
- Frame
AutomaticSize = NoneandSize = {0, 400, 0, 100}- Frame
AutomaticSize = NoneandSize = {0, 10, 0, 10}(this frame causes AutomaticSize to break)
- Frame
The layout engine seems to incorrectly take into account children of statically-sized elements when determining the size of AutomaticSize elements, particularly when combined with UIPadding.
The following contains the original UI I was working with to cause this, multiple minimal repros, and two “correct” examples that are only correct because they’re missing padding or descendants.
UiPaddingAutomaticSizeBugRepro.rbxm (9.3 KB)
Note that this issue occurs even if the statically-sized child frame has its own child with a size and position of {0, 0, 0, 0} – any children seem to throw off the layout engine, regardless of their size. Setting the AnchorPoint, Size, and Position of the descendant frame can have other weird effects on the AutomaticSize frame.
Expected Behavior
I expect that a statically-sized frame inside of an AutomaticSize+UIPadding frame will be treated the same regardless of its descendants, such that the parent AutomaticSize Frame is big enough to contain the child statically-sized frame with padding.
Generally, I don’t expect an AutomaticSize Frame to take into account descendants at all, only its direct children.
Actual Behavior
Workaround
I have no good workaround for using UIPadding with AutomaticSize.
Bad workarounds, though:
- For a single, statically-sized frame it’s possible to use a UIGridLayout alongside UIPadding, which seems to fix this.
- A UISizeConstraint alongside the UIPadding updated by Lua to match the size of the static frame can fix this.
Issue Area: Engine
Issue Type: Display
Impact: Moderate
Frequency: Often
Date First Experienced: 2021-10-20 07:10:00 (-05:00)
Date Last Experienced: 2021-10-26 04:10:00 (-05:00)
