You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Specifically in the case of the AcceptDialog and ConfirmationDialog, if either of them have FlowContainers as children, their first instance of popping up via the popup() methods will occur with rect_size skewed to an extremely large value. HFlowContainers cause the height to skew, whereas VFlowContainers affect the width. If both FlowContainers are children, the effect stacks. See example below (where the red rectangle represents the Rect2 passed to the popup() method):
2022-08-16.22-43-19.mp4
There are a few specifics surrounding this bug:
For one, it will occur regardless of whether the FlowContainer is a direct or indirect child of the dialog, so long as its part of the dialogs sorting chain. To clarify, if the FlowContainer were to be the child of another container class (i.e. HBoxContainer), the bug would occur. But if it was the child of a base Control node which does no sorting to its children, the bug would not occur.
The second specific is that the FlowContainer must have at least one child Control node. This leads me to believe there's some kind of clash happening between the dialogs sorting and the FlowContainers sorting.
The last specific is that the bug only occurs on the first popup() call. All subsequent ones behave normally with the dialog being of the specified size. You can see this happening in the example .gif. I tried adding and removing child nodes inbetween popups but neither action caused the issue to repeat.
So to summarize the above:
I tried replicating this behavior in all the other Popup derived nodes and none of them exhibited it. You'd expect the PopupPanel to since it sorts direct children in a similar manner to the Accept and Confirmation dialogs, but it does not. Also just to be clear, when I talk of the AcceptDialog & ConfirmationDialogs sorting, I'm referring to the way they automatically bound child Control nodes to their margins when resizing.
Steps to reproduce
Create an AcceptDialog or ConfirmationDialog.
Add an HFlowContainer or VFlowContainer to the dialog.
Add a Control node to the flow container.
Attach a script to the dialog and declare a _ready() function with popup_centered() as the first & only line.
Run the project and observe the dialog being stretched way beyond the edge of the screen bounds.
Godot version
3.5.stable
System information
Windows 10, GLES3, GTX 1070
Issue description
Specifically in the case of the AcceptDialog and ConfirmationDialog, if either of them have FlowContainers as children, their first instance of popping up via the popup() methods will occur with
rect_size
skewed to an extremely large value. HFlowContainers cause the height to skew, whereas VFlowContainers affect the width. If both FlowContainers are children, the effect stacks. See example below (where the red rectangle represents the Rect2 passed to the popup() method):2022-08-16.22-43-19.mp4
There are a few specifics surrounding this bug:
For one, it will occur regardless of whether the FlowContainer is a direct or indirect child of the dialog, so long as its part of the dialogs sorting chain. To clarify, if the FlowContainer were to be the child of another container class (i.e. HBoxContainer), the bug would occur. But if it was the child of a base Control node which does no sorting to its children, the bug would not occur.
The second specific is that the FlowContainer must have at least one child Control node. This leads me to believe there's some kind of clash happening between the dialogs sorting and the FlowContainers sorting.
The last specific is that the bug only occurs on the first popup() call. All subsequent ones behave normally with the dialog being of the specified size. You can see this happening in the example .gif. I tried adding and removing child nodes inbetween popups but neither action caused the issue to repeat.
So to summarize the above:
I tried replicating this behavior in all the other Popup derived nodes and none of them exhibited it. You'd expect the PopupPanel to since it sorts direct children in a similar manner to the Accept and Confirmation dialogs, but it does not. Also just to be clear, when I talk of the AcceptDialog & ConfirmationDialogs sorting, I'm referring to the way they automatically bound child Control nodes to their margins when resizing.
Steps to reproduce
Minimal reproduction project
FlowContainerInDialogBug.zip
The text was updated successfully, but these errors were encountered: