Setting a ScrollingFrame’s CanvasSize to UDim2.fromScale(0, 2) changes the Y axis of it’s AbsoluteCanvasSize to report equal to it’s ancestor ScreenGui’s AbsoluteSize.Y. This has never been the default behavior.
AbsoluteWindowSize is calculcated incorrectly, according to it’s description:
“The size in pixels of the frame without the scrollbars.”
When changing the ScrollBarThickness property of a ScrollingFrame, the AbsoluteWindowSize changes accordingly.
Expected behavior
Using Scale in CanvasSize should influence the AbsoluteCanvasSize of a ScrollingFrame as a multiple of it’s AbsoluteSize.
AbsoluteWindowSize should reflect the same value as AbsoluteSize does.
As an aside, it’s worth noting that there are even more semantic “off by one” bugs involving the dance between CanvasSize, AbsoluteCanvasSize, and AbsoluteWindowSize. These involve any combination of Offset and/or Scale usage with CanvasSize.
They are easy to find by playing around with the values yourself, but are difficult to explain without lengthy step by step instructions. I’d like to ask that the math calculating these values be revised/double checked entirely.
I hope this reply finds you well. I apologize for the delayed response.
Regarding your questions:
I completely understand your concern about the confusion surrounding the canvasSize of the scrollingFrame. It’s indeed designed to be calculated based on the parent’s size, which, in this scenario, refers to the ScreenGui’s size.
As for the AbsoluteWindowSize, it’s intended to include the size of the frame without the scrollbars, as mentioned in the documentation. Essentially, it represents the scrollingFrame size minus the scrollbar size. However, if you’d like the canvasSize to reflect the windowSize width, you could utilize the VerticalScrollBarInset property.
Please let me know if you need any further clarification or assistance. Thank you!