VisualShader node window closes when main window is in focus, breaks tiling WMs

[Slabity]

Godot version

v4.0.2.stable

System information

Linux NixOS, using Sway as a tiling WM

Issue description

When using the VisualShader system, if I try to add a node using either the "Add Node..." button or right-clicking on the graph, the new menu briefly appears as a new window but instantly closes when the main window is in focus.

This especially breaks on Linux tiling window managers such as Sway or i3 (when not using floating-layout) as the main window stays focused to prevent popups from forcibly grabbing focus.

Other types of windows, such as Editor Settings, do not have this issue as they stay open even if focus switches back to the main window.

I'd like to change this behavior to prevent the window from closing if the main window is in focus.

Steps to reproduce

1. Open up any project that has a VisualShader resource.
2. Either click on "Add Node..." or right-click on the visual graph to make the node selector menu appear.
3. Bring your mouse back to the main window.
4. The node selector menu disappears without any other input.

Minimal reproduction project

N/A

[Slabity]

Okay, so while debugging this, I think I see two issues here:

1. On Linux, certain windows in Godot are not properly following the XDG shell protocol. Specifically, some popups in Godot are not properly being created as xdg_popup, but rather as a regular xdg_surface. This causes compositors to see them as their own root window and treat them differently. Some popup windows, such as the menu that appears when you right-click on text, do work properly.
2. Popup windows expect to close themselves if they are not in focus. This isn't really a bad behavior, but when combined with the first point, it causes the window to immediately disappear on systems that treat xdg_surface as their own window and not as a popup (in my case, Sway).

[Slabity]

Enabling Single Window Mode in the Editor Settings allows me to use it properly. If anyone else runs into this issue, you can likely do the same.

[compese]

Other tiling WM issues FYI
#74587 (comment)
#74378 (comment)

[Calinou]

Enabling Single Window Mode in the Editor Settings allows me to use it properly. If anyone else runs into this issue, you can likely do the same.

Is there a way to reliably detect whether a tiling WM is being used (e.g. an environment variable or the presence of a file)? We could force single-window mode in this case, so that the user doesn't have to do it manually.

[Slabity]

Is there a way to reliably detect whether a tiling WM is being used (e.g. an environment variable or the presence of a file)? We could force single-window mode in this case, so that the user doesn't have to do it manually.

There's a couple of $XDG_* environment variables that you could use to determine this. For example, XDG_CURRENT_DESKTOP will be set to i3 or sway on those environments. But that just tells you which environment you're in, there's not really any way to determine the behavior of the current desktop environment.

The best you'd be able to do is maintain a list of different environments and hardcode the default for each. But even that's difficult because some environments like GNOME and KDE have unofficial extensions that turn them into tiling WMs. I believe there's also some Windows and MacOS plugins for tiling functionality, and even some desktop environments made for VR (I have no idea how this behavior works on any of these).

The safe method would be to just use single-window mode as the default (or the default for Linux) until Wayland support is better fleshed out and window types more accurately follow the XDG Shell Protocol (or whatever the issue with Xorg is).

[Riteo]

Can this also be replicated on i3? Otherwise I think it would be appropriate to put it in the XWayland issues tracker (yes there are enough issues to warrant one, the situation is that bad).