Pop-up windows instantly minimize on Fedora Linux 38 GNOME (DisplayServer regression)

[ghost]

---

Bugsquad note: This issue has been confirmed several times already. No need to confirm it further.

---

Godot version

4.0.3

System information

Fedora 38

Issue description

In the Godot editor, choosing to add a node to a (2D or 3D) scene will open the pop-up window, only to instantly minimize it. This seems to persist with every other dialogue/pop-up box throughout the editor. Other desktops I've tried (Cinnamon, KDE) do not encounter this issue.

Steps to reproduce

Open a project in the Godot 4 Editor.
Click the "+" button to add a node.
The pop-up will open, but instantly minimize.

Minimal reproduction project

project.zip

[Calinou]

• Related to Godot 4 hangs on popups/modals #60073.

Try using the --single-window command line argument as described there, or use a X11 session instead of Wayland.

[dannymate]

I have the same thing on Fedora Silverblue 38.
This occurs on all editor and popups with an inputfield.

It's intermittent but when I select an inputfield in the main editor or popup that window will minimise. Trying to bring it back up will minimise it again instantly. I have to in a split second mash escape to stop focus on the inputfield.

Edit:
Example:

Fedora.38.Gnome.Minimise.Issue.mp4

In the video I open up the Create > Resource popup. Click on a node and then the input field and causing it to minimise. Trying to bring it back up causes it to instantly minimise again.

Edit 2: As far as I can tell --single-window does prevent the issue from occurring.

[adamscott]

I confirm the issue on Fedora Linux 38 GNOME (Wayland), but I confirm too that it happened to me on:

• Ubuntu 22.04 GNOME (both Wayland and X11)
• Ubuntu 22.04 i3 (X11)

[Sauermann]

I have tested this with Godot v4.1.beta (824c139) - Debian 12 - X11 - Xfce - Vulkan and I am unable to replicate this issue.

[Riteo]

The Wayland reports could be related to some weird XWayland related issue/quirk so it doesn't surprise me as much but the X11 reports surprise me a lot.

@adamscott could you elaborate on your setup? i3 doesn't support minimizing AFAIK, what do you mean that you could reproduce this issue on it? Have you also tried a clean live ISO?

[adamscott]

Have you also tried a clean live ISO?

Good idea. I'll do that.

[hunterloftis]

--single-window does not prevent this issue on Godot v4.1.1.rc1 - Fedora Linux 38 (Workstation Edition) - Vulkan (Forward+) - integrated Intel(R) Graphics (ADL GT2) () - 12th Gen Intel(R) Core(TM) i7-1280P (20 Threads)

[Calinou]

@hunterloftis Are you on a X11 or Wayland session? Use echo $XDG_SESSION_TYPE in a terminal to know.

[hunterloftis]

@Calinou I'm on wayland (this is a close-to-stock Fedora 38 Thinkpad)

[PorkrollPosadist]

This bug is present on Gentoo (Gnome/Wayland) as well, in every version I've tried from 4.0-stable to HEAD (6588a4a). I'll try a couple more older stable releases to see if there is a version where it doesn't occur.

[Calinou]

I'll try a couple more older stable releases to see if there is a version where it doesn't occur.

This bug doesn't occur in 3.x to my knowledge, as it's related to the DisplayServer refactoring which landed in 4.0. so I'd recommend trying 4.0 alphas/betas/RCs first.

[PorkrollPosadist]

Reflects my experience so far. I just tried 3.5.1 and it seems to be working fine. I can attempt a bisect (git bisect tells me the merge base is 3.2-stable, so the bisect would run from 3.2 to 4.0). Forgive me if this is obvious, but is there a place I can look up which commits were tagged as release candidates? I only see tags for the stable releases.

[Calinou]

Forgive me if this is obvious, but is there a place I can look up which commits were tagged as release candidates? I only see tags for the stable releases.

We don't tag prereleases on GitHub by design, but you can use the script mentioned in Bisecting regressions to get the commit hash of a given prerelease.

[PorkrollPosadist]

First attempt at a bisect is... inconclusive. Git indicates d543ddf was the first bad commit, but looking at the diff, there is no way this is possible. I presume the bug failed to materialize at some point, and I flagged a bad commit as good.

I can't categorize the behavior of the bug exactly, but after testing at least 18 builds, I have developed certain paranoias. I think it may behave differently when the editor window is maximized. I performed all my tests with the editor window in a floating state. I also notice on some builds, the bug seems to trigger instantly and consistently, while on others the probability is apparently lower. I treated all builds where any whiff of the bug exhibited itself as a failure.

Here is my bisect log

# status: waiting for both good and bad commits
# bad: [92bee43adba8d2401ef40e2480e53087bcb1eaf1] Bump version to 4.0-stable \o/
git bisect bad 92bee43adba8d2401ef40e2480e53087bcb1eaf1
# good: [6fed1ffa313c6760fa88b368ae580378daaef0f0] Bump version to 3.5.1-stable
git bisect good 6fed1ffa313c6760fa88b368ae580378daaef0f0
# good: [4e7d75ccd350b98bccea517c034b367f52cf127e] Bump version to 3.2-stable \o/
git bisect good 4e7d75ccd350b98bccea517c034b367f52cf127e
# good: [a387094c25e8fba582f7a0b0c906f5d99ecf1aec] Merge pull request #55174 from clayjohn/Sky-SRGB
git bisect good a387094c25e8fba582f7a0b0c906f5d99ecf1aec
# good: [c7a7aad30d2b5a7a3ca6ddc3b8f556b797480d39] Merge pull request #59779 from rainerdeyke/constexpr-operators
git bisect good c7a7aad30d2b5a7a3ca6ddc3b8f556b797480d39
# good: [e5f0a565e2c9b9623bb5df5b31b60e480c248459] Merge pull request #67660 from Rindbee/improve-setter-for-Range
git bisect good e5f0a565e2c9b9623bb5df5b31b60e480c248459
# bad: [5551eed499efebd97875a7f3fc4ef57fd23e8d1d] Merge pull request #71806 from EricEzaM/71576-perspective-menu-perspectiveorthogonal-hotkey-display-inconsistency
git bisect bad 5551eed499efebd97875a7f3fc4ef57fd23e8d1d
# bad: [e9a659be5a430fbc84d4ae9bd6357090c40edf3c] Improve ResourcePreloader description
git bisect bad e9a659be5a430fbc84d4ae9bd6357090c40edf3c
# bad: [f16aa547955784f874a88c5050beacffb7643f18] Merge pull request #69981 from bruvzg/dyn_font_import_outline
git bisect bad f16aa547955784f874a88c5050beacffb7643f18
# good: [cc6321dfbeba4ef514131d1ed1afe45b8da7352f] Merge pull request #68998 from hackenshaw/makhak/avoid_error_spamming_in_animation_tree
git bisect good cc6321dfbeba4ef514131d1ed1afe45b8da7352f
# bad: [1ac7e5a3343ef9f4ecc7c494f7212b7c718520c8] Merge pull request #69518 from rune-scape/rune-analyze-values
git bisect bad 1ac7e5a3343ef9f4ecc7c494f7212b7c718520c8
# bad: [579d2e9da5e82f713b445f25e92637a755ae011e] Merge pull request #69760 from akien-mga/basisu_20221008
git bisect bad 579d2e9da5e82f713b445f25e92637a755ae011e
# bad: [829d49b0110edc7bf283c7cca30cddb967bccb70] Merge pull request #69719 from groud/fix_gdextension_bad_vformat_error
git bisect bad 829d49b0110edc7bf283c7cca30cddb967bccb70
# bad: [f9bd2ace0bc8839c5c0c6524ba578122b8bbfb34] Merge pull request #68682 from timothyqiu/camera-gizmo-size
git bisect bad f9bd2ace0bc8839c5c0c6524ba578122b8bbfb34
# bad: [b3c7822fad0fe0fa1b75721603c8e3f268b88fa4] Merge pull request #69638 from bruvzg/macos_notarytool
git bisect bad b3c7822fad0fe0fa1b75721603c8e3f268b88fa4
# bad: [5c635e8f24f052b85abd1aed2ded2e4f738d6b83] Merge pull request #69699 from aaronfranke/fix-variant-sname-inv
git bisect bad 5c635e8f24f052b85abd1aed2ded2e4f738d6b83
# bad: [d543ddf1c9e0aaa3766ceeeb9bb704399d4795dd] Fix Variant StringName `is_zero` being inverted
git bisect bad d543ddf1c9e0aaa3766ceeeb9bb704399d4795dd
# first bad commit: [d543ddf1c9e0aaa3766ceeeb9bb704399d4795dd] Fix Variant StringName `is_zero` being inverted

I'll give it another shot. At least, we know the bug was introduced before d543ddf.

[PorkrollPosadist]

Alright folks. I think I found it. 0f5b448

Broken behavior is evident before and after this commit, but the current behavior starts here.

My testing strategy has been rougly, create a new project, un-maximize the editor window,3D scene, add 5 nodes, add a script, open the project settings dialog, add five more nodes, save the scene, and quit. Each time a dialog opens, it has a chance of triggering the current bug. I noticed, before this commit (I can't say how far back it goes), the current bug doesn't occur, but saving the scene causes the editor window to be maximized for no reason. This stops and is replaced by the current behavior at 0f5b448

Bisect log for completeness:

git bisect start
# status: waiting for both good and bad commits
# bad: [d543ddf1c9e0aaa3766ceeeb9bb704399d4795dd] Fix Variant StringName `is_zero` being inverted
git bisect bad d543ddf1c9e0aaa3766ceeeb9bb704399d4795dd
# status: waiting for good commit(s), bad commit known
# good: [320f49f204cfbf9b480fe62aaa7718afb74920a5] Bump version to 3.1-stable \o/
git bisect good 320f49f204cfbf9b480fe62aaa7718afb74920a5
# good: [928fb7ae0faceb1afab75d15c3e3ee36ab534499] Merge pull request #48821 from Calinou/test-add-vector
git bisect good 928fb7ae0faceb1afab75d15c3e3ee36ab534499
# good: [cd5320a93d5569f29f98d1b0eaa0a47ca1895f87] Merge pull request #59110 from KoBeWi/Godot_for_embedded_systems
git bisect good cd5320a93d5569f29f98d1b0eaa0a47ca1895f87
# good: [d60db2dba884ba0dc97755bd01ea40f2a18e547b] Merge pull request #64468 from aaronfranke/editor-prop-visual-shader-mode
git bisect good d60db2dba884ba0dc97755bd01ea40f2a18e547b
# bad: [9cd62741bb0e2f410b2fb861f66e2cf10fe0334d] Merge pull request #66839 from aaronfranke/editor-prop-hide-slider
git bisect bad 9cd62741bb0e2f410b2fb861f66e2cf10fe0334d
# good: [bf3d981c60e2b64f5647bce0dcb549dda966bee6] Remove subcategory parameter from `AddOption` in visual shader editor
git bisect good bf3d981c60e2b64f5647bce0dcb549dda966bee6
# good: [7bf61e391289d2ada058140ebff0a7eeb2db0da9] Merge pull request #64359 from Mickeon/rename-camera-rotating
git bisect good 7bf61e391289d2ada058140ebff0a7eeb2db0da9
# good: [ba25a6e93bcfff0c30b440301edaeb3e2ca73f05] Merge pull request #66549 from MisterMX/tilemap-get-used-rect
git bisect good ba25a6e93bcfff0c30b440301edaeb3e2ca73f05
# bad: [5b735d000e714b3f5bd0f14a2af9b5e6999a30ed] Merge pull request #66815 from Rindbee/fix-blinking-line-gutter-icon
git bisect bad 5b735d000e714b3f5bd0f14a2af9b5e6999a30ed
# good: [e69b7083d45c5d8698508cce7086d361c4b1f44c] Merge pull request #65903 from groud/improve_terrain_painting
git bisect good e69b7083d45c5d8698508cce7086d361c4b1f44c
# bad: [498844f687bb8c0d8c44cc755182f2f48c854daa] Merge pull request #65276 from aaronfranke/shader
git bisect bad 498844f687bb8c0d8c44cc755182f2f48c854daa
# good: [adee79d7b544cf304158478970f67211c9695f59] Merge pull request #66715 from YeldhamDev/script_hide_port
git bisect good adee79d7b544cf304158478970f67211c9695f59
# bad: [d9a3888cea31f2b05a4a923e17e9eb5350863003] Merge pull request #66133 from aaronfranke/set-all
git bisect bad d9a3888cea31f2b05a4a923e17e9eb5350863003
# bad: [5c4d07f952d3431194028a7e052407d61cc3fee7] Merge pull request #66728 from MatthewZelriche/x11-state-fix
git bisect bad 5c4d07f952d3431194028a7e052407d61cc3fee7
# good: [cf6978f2869006ca4203d7dc438c5a99de7347f6] Merge pull request #64833 from MarcusElg/naninfprinting
git bisect good cf6978f2869006ca4203d7dc438c5a99de7347f6
# bad: [0f5b448a9c11d6f66942934c4156a87b387356a3] Fix inconsistent window state on X11.
git bisect bad 0f5b448a9c11d6f66942934c4156a87b387356a3
# first bad commit: [0f5b448a9c11d6f66942934c4156a87b387356a3] Fix inconsistent window state on X11.

[hunterloftis]

Thanks @PorkrollPosadist for spelunking. Hopefully pointing at the likely commit helps this to be resolved soon - this bug makes using Godot a huge chore on Fedora these days. I didn't realize how many pop-up dialogs the app had until every one of them was minimized by default!

[PorkrollPosadist]

NOT making any promises, but I finally have a debugging setup where I can set arbitrary breakpoints and inspect the stack. It is time for bed now, but if no one cracks this, I will continue fiddling around with it for a bit.

[hunterloftis]

A partial workaround that I've been successful with, for the most egregious case (F5 -> instantly backgrounded game window), is to set display/window/size/always_on_top to true.

edit: not perfect. Seems to help?

[PorkrollPosadist]

When the bug occurrs, it looks like things have gone wrong by the time DisplayServerX11::_validate_mode_on_map() is entered. The call stack looks like Window::popup() -> Window::set_visible() -> Window::_make_window() -> DisplayServerX11::show_window() -> DisplayServerX11::_validate_mode_on_map(). This method call occurs fairly late in the Window creation process. In X11 parlance, mapping a window is the act of flipping on its visibility, and is typically done after everything else is set up. Windows can also be mapped and unmapped by the window manager. This is typically how minimization ("iconization" in X11 parlance) is implemented. _validate_mode_on_map() gets called immediately after the window is mapped, as a sort of sanity check.

For some reason, by the time _validate_mode_on_map() is entered, wd.minimized evaluates to true, meanwhile DisplayServerX11::_window_minimize_check() evaluates to false, triggering a call to DisplayServerX11::_set_wm_minimized(true) to correct this discrepancy.

You can catch Godot in the act by setting a breakpoint on

godot/platform/linuxbsd/x11/display_server_x11.cpp

Line 2191 in 75f9c97

_set_wm_minimized(p_window, true);

Some of the logic involved with creating Windows and doing other X11 stuff seems inherently racey. The inconsistency of this bug also implies this. Whatever is happening here is likely being caused by some sort of race condition. A call to XFlush or XSync in the right or wrong place might make all the difference. I will continue debugging.

[adamscott]

I'll try to build locally the editor with a Wayland check to not execute 0f5b448.

[PorkrollPosadist]

Currently experimenting with an implementation of _window_minimize_check() which uses the EWMH properties to probe state instead of ICCCM (the current implementation). TENTATIVELY, it seems to be working, but I need to check some corner cases as well as different Wayland compositors and X11 window managers.

Potentially, it can fall back to the current implementation if it is not able to detect the _NET_WM_STATE or _NET_WM_STATE_HIDDEN atoms. On the other hand, EWMH appears to be assumed in other parts of the code and there may be no loss of backwards compatibility to be worried about. The EWMH spec dates to 2005, while ICCCM was published in 1994!

I guess if anyone else wants to try it, it's here: https://github.com/PorkrollPosadist/godot/tree/fix-wayland-window-behavior. I'd like to make sure this is working on a variety of platforms before I make a PR.

[adamscott]

I guess if anyone else wants to try it, it's here: https://github.com/PorkrollPosadist/godot/tree/fix-wayland-window-behavior. I'd like to make sure this is working on a variety of platforms before I make a PR.

@PorkrollPosadist I'd suggest you create a PR. When pushing a PR, the CI/CD setup builds artifacts that make it possible to test the PR without having to build it yourself.

[PorkrollPosadist]

I'm going to test this on at least one X11 system first to make sure I don't faceplant out of the gate, but expect it within a few hours.

[incdev96]

The bug is still available in the new release 4.2 dev 3. i'm on Ubuntu 23.04

[weitnow]

The bug is still available in the new release 4.2 dev 3. i'm on Ubuntu 23.04

Can confirm this....I hope it will be fixed in the near future...is quite annoying

[AThousandShips]

This has been fixed, but it isn't in dev3 (as you can see the comment was before the issue was closed), you will have to wait for dev4 or build yourself from source

[weitnow]

This has been fixed, but it isn't in dev3 (as you can see the comment was before the issue was closed), you will have to wait for dev4 or build yourself from source

thanks for the info...great to hear that it should be available in dev4 😀

[AThousandShips]

It will also be available in a future 4.1 patch

[xU77654x]

Godot v4.1.1.stable (bd6af8e) - Freedesktop SDK 22.08 (Flatpak runtime) - Vulkan (Forward+) - dedicated AMD Radeon RX 6600M (RADV NAVI23) () - AMD Ryzen 7 5800H with Radeon Graphics (16 Threads)

I have the same issue as well. I can open the window for "Create a New Resource" just fine--though it starts minimized. But, the window for "Save Resource As" cannot be opened at all as described in the .mp4 above. I also cannot interact with the main Godot window while the Save Resource As window is unable to be opened, until I force-close said window.

Hopefully this gets fixed very soon!

[AThousandShips]

It has been fixed, will hopefully be in 4.1.2 see above

[aljaz-zupan]

It has been fixed, will hopefully be in 4.1.2 see above

Fix is not in 4.1.2, but is in 4.2 beta 1.