1850959 - [Wayland] Window moves to primary monitor after resuming from suspend on Linux/Wayland

Status: UNCONFIRMED

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

Description

[VZ]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Firefox/102.0

Steps to reproduce:

Running FF 102.14.0esr on Debian Bookworm with MOZ_ENABLE_WAYLAND=1.

1. Open 2 FF windows, one is maximized on the primary monitor (DPI 200%), another is maximized on a secondary monitor (DPI 100%).
2. Suspend the machine.
3. Resume the machine.

Actual results:

Both windows appear (still maximized) on the primary monitor.

Expected results:

The second window should remain on the secondary monitor.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Widget: Win32' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[VZ]

Not sure if "GTK" is the correct component, but "Win32" is definitely a wrong one.

Comment 3

[Ross Lopata]

I have a triple monitor setup, all monitors identical. When resuming from suspend all Firefox windows get moved to the primary monitor.

Comment 4

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

On Wayland Fixefox can't control its placement. I suggest to report it to against Wayland compositor you use (in case of Gnome it's Mutter - https://gitlab.gnome.org/GNOME/mutter/-/issues)

Comment 5

[VZ]

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

On Wayland Fixefox can't control its placement.

This is true, but Firefox must be doing something to prevent the compositor from even remembering the display its windows were on because it does work fine for the other applications: e.g. I also have several Foot (terminal emulator) windows open and they invariable reopen on the same display where they were the last time.

I suggest to report it to against Wayland compositor you use (in case of Gnome it's Mutter - https://gitlab.gnome.org/GNOME/mutter/-/issues)

IMO this one is not a bug in mutter (unlike plenty of others...) because the wrong behaviour can't be reproduced with a simple GTK application.

Comment 6

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

(In reply to VZ from comment #5)

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

On Wayland Fixefox can't control its placement.

This is true, but Firefox must be doing something to prevent the compositor from even remembering the display its windows were on because it does work fine for the other applications: e.g. I also have several Foot (terminal emulator) windows open and they invariable reopen on the same display where they were the last time.

I suggest to report it to against Wayland compositor you use (in case of Gnome it's Mutter - https://gitlab.gnome.org/GNOME/mutter/-/issues)

IMO this one is not a bug in mutter (unlike plenty of others...) because the wrong behaviour can't be reproduced with a simple GTK application.

Really? Do for instance gedit or gnome-terminal work correctly? Please try one Firefox window (not multiple ones) and also one gedit/gnome-terminal window and compare the behavior after resume.

Thanks.

Comment 7

[VZ]

Really?

Yes. With my display setup (see here https://ibb.co/Gv1bZfL) if I open a Foot (terminal emulator which I use) on the display "3" and open Firefox in a new profile (so no extensions or anything) on the same display, after resume Foot window stays on the display "3" in the same position it was before suspending, while Firefox window jumps to display "1".

So while there is probably something mutter could do to prevent it from happening (because everything works correctly under Sway, to which I've switched due to another mutter bug that is just too annoying to live with), it still looks that there is something wrong with Firefox itself too.

Comment 8

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

Hm, that's interesting. Can you please run Foot from another terminal with WAYLAND_DEBUG=1 env variable, do suspend/resume and attach the log here?
Thanks.

Comment 9

[VZ]

Attachment: foot-wayland-debug.log

Here is the (very slightly redacted) debug log for Foot where I just opened it (from another Foot instance running on the same monitor (3)), suspended, resumed and quit it.

Comment 10

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

Thanks for the log. Looking at it I can't find any specific call which places the foot to particular desktop. I wonder how it manages it then...

Comment 11

[VZ]

Sorry, I don't know what to say here. The obvious guess would be that Foot doesn't do anything special and that mutter does put things where they belong on its own by default, but it's Firefox which does something that prevents this from working, but I have no idea what nor how to debug it, to be honest.

Comment 12

[Ross Lopata]

Update on the issue:

My setup consists of a triple monitor configuration using Arch Linux with GNOME on Wayland, and an AMD GPU. The primary monitor is positioned in the center. I've observed that if I launch Firefox and quickly move my mouse to a secondary monitor—allowing Firefox to restore the last session on that monitor—and then manually rearrange the windows across the monitors as desired, they maintain their positions on the secondary monitors after a suspend/resume cycle. However, any windows that I place on the primary monitor still shift to a different monitor upon resuming.

Comment 13

[Ross Lopata]

I've just found that un-maximizing and then re-maximizing the windows on the primary monitor before suspending helps retain their positions through the suspend/resume cycle.

Comment 14

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

I guess we need to wait to Wayland protocol extension here.
Meantime you may use Gnome extension like https://github.com/nlpsuge/gnome-shell-extension-another-window-session-manager
IMHO if the restore works not I guess it's pure luck as this is not part of Wayland protocol and it's in compositor itself where the application is located (I wonder if Foot has any particular feature which makes compositor to place it on particular screen but I don't see any from the log).

Comment 15

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

https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/264 is the recent work here.