AutomaticCanvasSize adds wrong axis to AbsoluteCanvasSize

Bug Reports Engine Bugs
,
#1

Recently, we’ve been noticing patterns between bugs we’ve been dealing with in regard to AutomaticCanvasSize. AutomaticCanvasSize adds the wrong axis’ length to AbsoluteCanvasSize via a linear relationship. Because of the complexity of this issue, I will give bullet points on how to reproduce this issue with the repro file I’ve given below:

Case A:

  1. Observe the horizontal ScrollingFrame’s AbsoluteCanvasSize (300, 300). Observe it’s UIListLayout’s AbsoluteContentSize (540, 300). Observe it’s AutomaticCanvasSize axis (X). The AbsoluteCanvasSize of the horizontal ScrollingFrame should be (540, 300), not (300, 300).
  2. Observe the invisible frame named toggle-visibility, and it’s Size, {0, 0}, {1, 0}. This magical frame gives us the power to scroll again.
  3. When toggle-visibility’s Visible property is equal to false, the horizontal ScrollingFrame’s AbsoluteCanvasSize is equal to (300, 300). When Visibility is equal to true, our ScrollingFrame’s AbsoluteCanvasSize == (540, 300).
  4. toggle-visibility’s X axis length is 0, yet, when it’s Visiblity is equal to true, horizontal ScrollingFrame’s AbsoluteCanvasSize.X increases by 240px, and scrolling is now possible. This is the only known way to get around this bug at the moment.

Case B:

  1. Observe the vertical ScrollingFrame’s AbsoluteCanvasSize (300, 250). Observe it’s UIListLayout’s AbsoluteContentSize (300, 300). Observe it’s AutomaticCanvasSize axis (Y). The AbsoluteCanvasSize of the vertical ScrollingFrame should be (300, 300), not (300, 250).
  2. Observe the frame named toggle-visibility, and it’s Size, {0, 250}, {1, 0}. Changing this magical frame’s size introduces a linearly scaling relationship to the vertical component of our ScrollingFrame’s AbsoluteCanvasSize, and this applies when working in Scale, too.
  3. Set the size of toggle-visibility to {0, 251}, {1, 0}. Notice how the ScrollBar is now visible and the ScrollingFrame’s AbsoluteCanvasSize is now (300, 251).
  4. Set the size of toggle-visibility to {0, 275}, {1, 0}. Notice how the ScrollBar extends to include more room to scroll, but that we can’t scroll to the end of our content, and that ScrollingFrame’s AbsoluteCanvasSize is now (300, 275). So far as the X component of toggle-visibility is greater than the Y component of ScrollingFrame.AbsoluteWindowSize, the difference between the two components will be added to ScrollingFrame.AbsoluteCanvasSize.Y
  5. Finally, set the size of toggle-visibility to {1, 0}, {1, 0}. Notice how the ScrollBar extends entirely to the bottom of our canvas, AbsoluteCanvasSize == (300, 300), and we can see and scroll to everything. Set toggle-visibility’s Size back to {0, 250}, {1, 0} and watch the ScrollBar disappear.

automatic-canvas-size-adds-wrong-axis-length-of-items-to-absolute-canvas-size.rbxl (63.5 KB)

Expected behavior

The scrolling-relevant axis of AbsoluteCanvasSize should reflect or be the same calculation as what a UIListLayout calculates to be it’s AbsoluteContentSize (respective to the scrolling axis/direction). UIListLayouts seem to be the only reliable source of truth for what CanvasSize should be.

Our UI artists are struggling to create UI that uses ScrollingFrames efficiently, because AutomaticCanvasSize is unreliable. If we have to listen to a UIListLayout in order to set the CanvasSize property with code, then AutomaticCanvasSize loses it’s reason to exist.

2 Likes
#2

This is just an acknowledgment announcement!

We’ve filed a ticket to our internal database, and we’ll follow up when we have an update!

Thanks for the report!

2 Likes