UIGridLayout containers are suddenly sized incorrectly

[PeZsmistic]

Reproduction Steps
In my game just suddenly as of 1 hour and 50 minutes ago, all of my UI relying on AbsoluteContentSize broke.

The numbers returned appear to be either zero or very small, resulting in tweens and container sizes being wrong. This looks like a race condition because occasionally in the video uploaded below upon joining the game, the Favorites category is sized correctly and the images appear.

I do not have a precise repro case yet because I am at work, but this is completely breaking my game. Presumably a FFlag is involved.

The code that is going wrong through no change on my part is this:
buttons is a container for buttons that would normally be beneath headers in the Creatures tab of the UI shown.

	-- Give the layout a minute to catch up (must give the grid room to expand before we clamp the size of the container)
	buttons.Size = UDim2.new(
		buttons.Size.X.Scale, 
		buttons.Size.X.Offset, 
		buttons.Size.Y.Scale, 
		100000
	)
	
	-- Resize containing frame
	buttons.Size = UDim2.new(
		buttons.Size.X.Scale, 
		buttons.Size.X.Offset, 
		buttons.Size.Y.Scale, 
		buttons.UIGridLayout.AbsoluteContentSize.Y
	)
	
	buttons.UIGridLayout:GetPropertyChangedSignal("AbsoluteContentSize"):Connect(function()
		buttons.Size = UDim2.new(
			buttons.Size.X.Scale, 
			buttons.Size.X.Offset, 
			buttons.Size.Y.Scale, 
			buttons.UIGridLayout.AbsoluteContentSize.Y
		)
	end)

As far as I understand it, all users joining the game fresh are broken, but old users who have been ingame seem to be fine.

Be an Alien: Renewal

Expected Behavior
You should be able to see all of the buttons in my UI at the correct sizes.

Actual Behavior
UI is sized completely wrong and tween targets fall short. None of the buttons in my UI are visible because their containers have height 0. The second menu full of square floating buttons is supposed to swap offscreen.

Workaround
No workaround. This is breaking my game.

Issue Area: Engine
Issue Type: Other
Impact: High
Frequency: Constantly
Date First Experienced: 2021-09-02 12:09:00 (-05:00)

[PeZsmistic]

The FFlag responsible sounds like it may be FFlagUpdateAutomaticSizeWhenSetVisible4 because it was enabled around the time my players started reporting this, plus the above information.

[CharlieGordonnn]

Hi @PeZsmistic , thanks for your report. Trying to revert it now. And if possible, please do provide a place file to reproduce it when you have time. Thanks a lot!

[PeZsmistic]

Please see this reply for a repro case: UIGridLayout containers are suddenly sized incorrectly - #2 by Kiriot22

My UI starts disabled, which is consistent with the information their post provides.
Stepping through my code with the debugger shows that often the values when the signal returned by GetPropertyChangedSignal for AbsoluteContentSize fires are zero.

I can investigate further later if necessary.

---

I can see the flag has been turned off, and the issue is no longer occurring.
Thanks!

[CharlieGordonnn]

Hi @PeZsmistic and @Amiaa16 , thanks for the report and the repro file. We are looking into this issue right now. Meanwhile, I would like to explain the reason why this happens: it is that we wanted to cut off some unnecessary layouting/rendering work for invisible objects so that we can have our performance enhanced for developers and players! So I’m also trying to understand more from developers, what usually makes up the necessity to query the sizes of invisible objects? I would appreciate if you can provide any thoughts on these kinds of queries so that we can improve the experience. Thank you!

[PeZsmistic]

Thanks for the explanation!

My UI has multiple pages and sections that start disabled (i.e. invisible), but I run all of the setup code for these UI elements and pages all at once and only once when they are first created for the player. At this point during setup they are mostly all invisible.

E.g. I am populating the creature select menu once when the player joins, and it never changes for the duration of the game. This approach is not the most efficient in terms of memory usage, but it is very simple to implement.
E.g. I store a menu’s property table in the closed position for a tween at the start of a module script, which runs while the menu is not currently open and thus invisible.

I also try not to parent or make elements visible until they are finished being constructed, but I’m not sure if this has any notable performance benefit.

I think if you want to go ahead with a change like this, you cannot just turn it on all at once for everyone. This seems like a very fundamental change and breaks developer expectations in much the same manner as something like deferred signals. You might want to put this behavior on a workspace property to allow developers time to adapt code.

I would probably need to make a few changes to adapt my code to work with this change. The third party libraries I use however might be a significant hurdle depending on how unlucky I am.

[CharlieGordonnn]

Hi @PeZsmistic , thanks a lot for your quick response and examples. We will take them into consideration and work on better solutions that can cover most use cases.