Node::move_child doesn't update Control-draw-order in Viewport

[Sauermann]

Godot version

v4.0.beta.custom_build [bc5d67c]

System information

Llinux X11

Issue description

Considering the following two SceneTrees:

When running the project with the SceneTree in each variant:

• with the configuration of the left picture Button2 is drawn over Button
• with the configuration of the right picture Button is drawn over Button2

However modifying the SceneTree while the project is running with the following command between the two configurations:

func _on_button_pressed():
	$"/root/Control".move_child(get_parent(), 0)

results in no display-change.
I would expect, that the draw order of Control-nodes get updated, when their position in the SceneTree changes.

A simple

diff --git a/scene/main/node.cpp b/scene/main/node.cpp
index 680c4cd7e4..b6254abdd9 100644
--- a/scene/main/node.cpp
+++ b/scene/main/node.cpp
@@ -396,6 +396,10 @@ void Node::_move_child(Node *p_child, int p_index, bool p_ignore_end) {
        p_child->_propagate_groups_dirty();
 
        data.blocked--;
+       if (get_viewport()) {
+               get_viewport()->gui_set_root_order_dirty();
+               get_viewport()->update_canvas_items();
+       }
 }
 
 void Node::_propagate_groups_dirty() {

did not solve the problem.

Steps to reproduce

1. Load and run MRP.
2. Click on the buttons in order to change the ordering of their parent Nodes.

I would expect, that the draw order of the Control nodes changes, but they stay in the same order.

Minimal reproduction project

BugMoveChildRootUpdate.zip

[KyleTiley]

Running into the same issue but with Node2Ds. Any temp solutions or workarounds found to "force update" the draw order?

[Sauermann]

@KyleTiley You could try to change the nodes Node and Node2 in the above example from type Node to type Node2D.

[KyleTiley]

@Sauermann same results, order is not what the hierarchy dictates it should be. However, I noticed that if the scene tree is updated (a node is added or removed) then the nodes jump to the correct draw order. Not sure why this works, but my current workaround is to add a basic Node2D to the scene and then immediately queue_free it.