I’ve randomly started experiencing this issue as well, specifically when using AutomaticSize with ScrollingFrame’s. I had modified Cmdr’s UI slightly to use AutomaticSize and it worked perfectly fine approximately 4 days ago. I played around with it a bit and couldn’t replicate the problem with regular frames being descendants of other frames - it seemed to always be whenever a ScrollingFrame was involved.
My current workaround is to just use TextService’s GetTextSize.
How it used to be (gif recorded on February 1st, 2022):
How it is now (gif recorded on February 5th, 2022):
Hi @Maxx_J , thanks for your report and the repro files. We’ve investigated the files you provided, in the cases you are using AutomaticSize or AutomaticCanvasSize, we expect the child objects to have offset sizes instead of scaled sizes so that the AutomaticSize can be calculated based on those fixed sizes. AutomaticSize + ScaleSize will not always work as expected.
For example, in the OriginalLootGUI.rbxm, the Container has a size of {0.5, 0},{0, 0}, the ScrollingFrame has a size of {1, 0},{1, 0} which gives it 0px in Y size so the Window Size of the ScrollingFrame is 0px, which is the reason there is nothing displaying. If you give the ScrollingFrame’s Size a fixed Y, the items should display fine. Please go ahead and try out this solution and let me know if it doesn’t work.
Hi @Scriptos , thanks for your report and nice GIFs, we’d like to investigate the issue you ran into. Meanwhile, we’d appreciate it if you can provide some repro files.
The two frames on the left side are normal (not ScrollingFrames), for comparison.
I have the sizes of the container frames (the ones with AutomaticSize enabled) set to {0, 0},{0, 0}.
The frames inside of the AutomaticSize frames have their sizes set to {0, 100},{0, 100}.
The TextLabel’s have their sizes set to {0, 0},{0, 0}, with AutomaticSize XY enabled.
Until recently, all of the frames in this ScreenGui would’ve looked the same (except for the scrollbar, of course).
Edit: Ah, important thing to mention. The problem seems to be caused by the UIPadding. If you delete the padding then it’s “fixed”, except I can no longer easily create nice padding around the sides of the frame. The gifs in my previous post had padding as well, including the gif showing that it used to work on February 1st.
I’ve tried a few different variations of this version as well, but I’ve never managed to prevent the list of frames from sticking out of the container.
I suppose the top two variations came closest to what I previously had, but not quite.
AutomaticSize tends to overwrite the AutomaticCanvasSize fully, which I’m guessing is intentional. I’m assuming the previous automaticscaling behavior didn’t fully adhere to this behavior, which allowed me to make UI with several frames while retaining a scrollbar.
Designed it like that since I didn’t want the user scrolling unless the frame would become large to a point where it’d be obtrusive.
In other words - wanted to prevent showing one element/frame at a time, while retaining scrolling behavior.
Been having this problem for some months now, really annoying! It seems to be caused by UIPadding, where AutomaticSize isn’t factoring in the padding for the size calculation, hence the clipping.
Hi @Maxx_J , I had a previous response which now I believe I might have misunderstood your expected behavior here. So I would like to double-check with you, that the expected result should be a scrollable ScrollingFrame with a fixed window size (e.g. four rows) and a correct drop shadow underneath. Does this sound correct?
Actually on a second thought, I think the previous response may still make some sense, because you did mention that the list always sticks out of the container. The reason might be the container’s style is DropShadow, which tends to be smaller than its initial size. Changing the Style to Custom would fix the size issue. Please verify and let us know if that’s not fixing the issue.
That is the closest I could get to remotely matching what it previously used to look like.
