1923833 - Window restoring doesn't work after the window was minimized on Wayland

Status: NEW

(Core :: Widget: Gtk, defect, P3)

Description

[Alexandra Borovova [:Sasha]]

While working on the bug 1857571, I've noticed that the restoring of the window after minimization doesn't work. If we call window.minimize() and then window.restore() the window stays hidden, sizemodechange event is also not fired (see try push). Maybe it's also related to the inability to set coordinates on Wayland.

Comment 1

[Alexandra Borovova [:Sasha]]

It seems like it might be a platform issue.

Comment 2

[Martin Stránský [:stransky] (ni? me)]

I don't think we have control over this.

Comment 3

[Henrik Skupin [:whimboo][⌚️UTC+2]]

CC'ing as well Karl in case he has an idea why that happens. It's unfortunate for our WebDriver users that they would have to restart Firefox after minimization to get the window back.

Comment 4

[Martin Stránský [:stransky] (ni? me)]

I think it's caused by Wayland by design. On Wayland any application can't promote itself on top without explicit user action. That prevents unwanted behavior like auto-opened popups and so on. To promote app on top you may need a launch token or focus token. Launch token is obtained when application is fired and focus token can be transferred from another already focused window of the application. If we want focus/move on top any window on wayland we need to use xdg_activation protocol to move focus to it (that has been already implemented for the automated tests and it's used when test windows are opened).

Comment 5

[Martin Stránský [:stransky] (ni? me)]

See nsWindow::SetFocus() and Wayland section there:
https://searchfox.org/mozilla-central/rev/faa7b1b2a7b509df04a8bafbf8520fc162ad1363/widget/gtk/nsWindow.cpp#3071

Comment 6

[Henrik Skupin [:whimboo][⌚️UTC+2]]

(In reply to Martin Stránský [:stransky] (ni? me) from comment #4)

If we want focus/move on top any window on wayland we need to use xdg_activation protocol to move focus to it (that has been already implemented for the automated tests and it's used when test windows are opened).

That's interesting. For which automated tests have this been implemented already? Are there special APIs that we would have to call from Marionette / Remote Agent to trigger that code path?

Comment 7

[Henrik Skupin [:whimboo][⌚️UTC+2]]

I've upgraded my Linux machine to Linux Mint 22 and tried to run the web-platform tests with Wayland (experimental support) enabled. While Firefox fails to restore the window it works just fine with Chrome. So that means there isn't a problem per-se with restoration of the window, but that we do something not correct.

Comment 8

[Henrik Skupin [:whimboo][⌚️UTC+2]]

After talking to Emilio on Matrix he mentioned to me that Chrome doesn't use Wayland by default and that it needs to get started with --enable-features=UseOzonePlatform --ozone-platform=wayland to force it to Wayland mode. When I actually do that Chrome crashes and as well resets my whole session. Given this fact I can say that when I run the wdspec tests Chrome indeed is using the X11 backend.

Also when I start Firefox with the environment variable MOZ_ENABLE_WAYLAND=0 set, which forces Wayland APIs not to be used in Firefox, I see that tests passing as well.

Robert, I've heard from Emilio that you also work (or worked) on mutter. Would that window server help us?

(In reply to Martin Stránský [:stransky] (ni? me) from comment #4)

If we want focus/move on top any window on wayland we need to use xdg_activation protocol to move focus to it (that has been already implemented for the automated tests and it's used when test windows are opened).

I would still be interested in how this would work.

Comment 9

[Robert Mader [:rmader]]

(In reply to Henrik Skupin [:whimboo][⌚️UTC+2] from comment #8)

After talking to Emilio on Matrix he mentioned to me that Chrome doesn't use Wayland by default and that it needs to get started with --enable-features=UseOzonePlatform --ozone-platform=wayland to force it to Wayland mode. When I actually do that Chrome crashes and as well resets my whole session. Given this fact I can say that when I run the wdspec tests Chrome indeed is using the X11 backend.

Huh, that quite surprising to me. Which DE / distro are you running - and is it by chance comparatively old (like Ubuntu 20.04 or so)? I'm working a lot with the chromium + Wayland ozone backend for my day job these days, with Mutter and Weston, and if Chromium could crash either of these in maintained versions I would have to fix it :)

Also when I start Firefox with the environment variable MOZ_ENABLE_WAYLAND=0 set, which forces Wayland APIs not to be used in Firefox, I see that tests passing as well.

Robert, I've heard from Emilio that you also work (or worked) on mutter. Would that window server help us?

Aren't you already using Mutter / Gnome for testing?

Anyhow, I think Martin is right: the way minimization is implemented on Wayland means a minimized window loses focus and may not be able to restore itself. Different compositors/display servers may have different policies here, though, and potentially things just work as needed for the test on one but not another.

Martins suggestion to use xdg_activation protocol sounds to me like the canonical solution, but there might be a more simple workaround. I think Martin knows better than me.

(In reply to Martin Stránský [:stransky] (ni? me) from comment #4)

If we want focus/move on top any window on wayland we need to use xdg_activation protocol to move focus to it (that has been already implemented for the automated tests and it's used when test windows are opened).

I would still be interested in how this would work.

Comment 10

[Henrik Skupin [:whimboo][⌚️UTC+2]]

(In reply to Robert Mader [:rmader] from comment #9)

(In reply to Henrik Skupin [:whimboo][⌚️UTC+2] from comment #8)

After talking to Emilio on Matrix he mentioned to me that Chrome doesn't use Wayland by default and that it needs to get started with --enable-features=UseOzonePlatform --ozone-platform=wayland to force it to Wayland mode. When I actually do that Chrome crashes and as well resets my whole session. Given this fact I can say that when I run the wdspec tests Chrome indeed is using the X11 backend.

Huh, that quite surprising to me. Which DE / distro are you running - and is it by chance comparatively old (like Ubuntu 20.04 or so)? I'm working a lot with the chromium + Wayland ozone backend for my day job these days, with Mutter and Weston, and if Chromium could crash either of these in maintained versions I would have to fix it :)

I'm running Linux Mint 22 on a Thinkpad Lenovo X230, and selected Cinnamon on Wayland (Experimental) on the logon screen. This version was released 2 months ago and is based on Ubuntu 24.04 LTS. If you need more details I'm happy to provide those.

Robert, I've heard from Emilio that you also work (or worked) on mutter. Would that window server help us?

Aren't you already using Mutter / Gnome for testing?

I'm not really a Linux user so not sure if Mutter is already part of some distro and used by default. The Linux workers in CI make use of Ubuntu 24.04 as well.

Martins suggestion to use xdg_activation protocol sounds to me like the canonical solution, but there might be a more simple workaround. I think Martin knows better than me.

I assume that whatever solution we need is related to any platform change.

Comment 11

[Martin Stránský [:stransky] (ni? me)]

(In reply to Henrik Skupin [:whimboo][⌚️UTC+2] from comment #10)

I'm not really a Linux user so not sure if Mutter is already part of some distro and used by default. The Linux workers in CI make use of Ubuntu 24.04 as well.

Wayland uses different architecture than X11 - every environment has it's own 'wayland display server' which is component what manages the whole session, renders application on screen, get keyboard input etc. That's essential part of the Wayland desktop.

Gnome uses Mutter and KDE runs Kwin, there's also Sway or Hyprland (both compositors & desktops) or Weston which is kind of example wayland compositor.
You can also run the compositor itself without whole environment which may be used for testing or various tasks like PGO builds.

Martins suggestion to use xdg_activation protocol sounds to me like the canonical solution, but there might be a more simple workaround. I think Martin knows better than me.

I assume that whatever solution we need is related to any platform change.

What I mean there is that Mutter (Gnome) doesn't allow you to create focus 'out of nowhere'. Focus needs to be transferred from another focused application window. Do we have any during the test?

There are some testsuites (mochitest for instance) which opens a Firefox window and then it runs the tests and opens/closes another Firefox windows per test batch or test unit or so. In this case the testsuite transfers the focus between Firefox windows and that's what I meant here. I have very limited knowledge about Firefox testsuite so I have no idea if such mechanism can be used in this particular test too.

(for instance if I run './mach test dom' on terminal I see focus changes between test windows on Wayland and that's what I mean).

Comment 12

[juraj.masiar]

Attachment: Thunderid Windows Cant Be Restored.mp4

I'm seeing maybe the same bug on Windows 11 24H2 using 128.4.1esr.
It started only a few days/weeks ago, this is maybe third time I see it.
As shown in the attached video, I can't restore the Thunderbird window.
The preview suggests it's been "compressed" from all sides.
After forcing the window to close and reopening Thunderbird, it's opened in this small "compressed" size in the upper left corner.
My PC just woke up from sleep, maybe it's related? I have many screens with many apps opened, but only Thunderbird broke so far.

Comment 13

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Juraj, this bug is specifically for Wayland on Linux. So if you think that this is a problem on Windows please file a separate bug. Thanks.