paperwm
On Xorg, after screen switches off after idling, windows slip under the top bar
Describe the bug On Xorg, after screen switches off after idling (and with lock screen disabled, I think this may be related) the windows of the screen no longer have a top border, and sit under the top bar. It takes closing or opening a window to get the windows to relayout properly.
To Reproduce Steps to reproduce the behavior:
- Let the screen switch off after inactivity, but not sleep
- Move the mouse to switch back on.
- Windows will have stretched up to behind the top bar
Expected behavior Windows should not resize or move after screen off
Screenshots Hard to get screenshots for this one
System information: Please provide system information: Using latest main branch Paperwm manually installed, on gnome 45.5, on latest nixos.
- if you installed via source code, please execute
./gather-system-info.shin you PaperWM clone and paste the information below
Distribution: NixOS
GNOME Shell 45.5
Display server: Xorg
PaperWM branch/tag: release
PaperWM commit: 282d385c1f152836915742f7c1af4a4f537de3b5
Enabled extensions:
- [email protected]
- [email protected]
- [email protected]
- just-perfection-desktop@just-perfection
- [email protected]
- [email protected]
- [email protected]
Hey @jonseppanen, I haven't been able to reproduce this one.
How did you disable the lockscreen?
Jay.
You can go to settings -> privacy -> screen lock -> automatic screen lock
Disable this setting and after your screen blanks (but before full sleep) , wake the machine with a mouse movement or something to see the effect.
@jtaala Could you let me know where the various suspend/wake/lock events are intercepted/handled and I will try take a look - this bug is getting super annoying for me. Thanks!
@jtaala Could you let me know where the various suspend/wake/lock events are intercepted/handled and I will try take a look - this bug is getting super annoying for me. Thanks!
Well, we don't handle any sleep/wake/lock events at all - Gnome does (Gnome will disable extensions on lock etc. events, and enable when they're back on).
You probably want to run the following if you can isolate when the desktop is back available:
spaces.forEach(s => s.layout());
I haven't been able to reproduce this - then again, it could be monitor specific, or xorg specific. Does this happen on wayland for you?
Other than that, you're best bet is https://github.com/paperwm/PaperWM/blob/469dcfd31fe5f9f17ffdcd6873dd6bb551a1d3a1/tiling.js#L2114
which should be called when monitors change (e.g. you can try put the layout() call in the finish function.
I've give this one another go in reproducing in xorg. Question - I'm assuming you have multiple monitors running (the slipping under the TopBar sounds like slipping under the fake topbar PaperWM elements on non-primary monitors).
Unfortunately, I can't reproduce this on fedora 39 (Gnome 45.5) in Xorg. Here's my setup lockscreen (does it look right?):
I'm running a 2 head VM instance in virt-manager for multi-monitor to try replicate your setup.
This is what I get if I leave it for a minute til the displays shutdown (then wake with mouse movement). This appears to be the correct behaviour (which is PaperWM gets disabled... then re-enabled on display wake):
Screencast from 2024-05-06 21-23-11 (trimmed).webm
Let me know if there's anything you're doing differently to me in the above test.
I just have a single, super ultrawide monitor.
I use nixos unstable, so everything is latest always. My settings are the same as yours, and have tried this with ONLY paperwm enabled.
Im totally stumped. Because Nixos is 100% reproducible so it is installed exactly the same on my 3 machines with the same bug but different hardware, I have also got gnome 45.5 installed, as im not game enough for 46 yet.
Doesnt occur on wayland!
I can reproduce this (void, Xorg). It happens as soon as I turn off my (singular) display, no lockscreen required. Is there anything I can do to help debug?
Thanks @glupi-borna - can I get you to open up PaperWM prefs and go to the About tab and click the Copy to Clipboard and paste the output here?
One other thing that will help, can both of you run the following command from a terminal:
journalctl -f /usr/bin/gnome-shell
and then turn off the display, wait a couple of seconds, then turn on the display, and paste the output here? I'm mainly looking for #PaperWM disabled and #PaperWM enabled outputs to see if screen off triggers and disable/enable event.
Here's the version info:
Distribution: Void
GNOME Shell: 45.5
Display server: Xorg
PaperWM version: 46.9.1
Enabled extensions:
- [email protected]
- [email protected]
- [email protected]
Unfortunately, void linux uses runit instead of systemd, so I don't have journald and can not install it. I'm looking into getting at the logs in some other way, will report back when I figure it out!
Alright, here's what got printed to gnome-shell's stderr between me turning off my display, and then turning it on again. I'm not sure that this is the right thing, but it looks like it might be (it includes the #PaperWM enabled line earlier in the log, from when I logged into the session).
(gnome-shell:16313): GNOME Shell-CRITICAL **: 12:11:59.888: TypeError: monitor is null
StackOverlay@file:///home/borna/.local/share/gnome-shell/extensions/[email protected]/stackoverlay.js:185:9
ClickOverlay@file:///home/borna/.local/share/gnome-shell/extensions/[email protected]/stackoverlay.js:133:21
monitorsChanged@file:///home/borna/.local/share/gnome-shell/extensions/[email protected]/tiling.js:2151:27
init/</<@file:///home/borna/.local/share/gnome-shell/extensions/[email protected]/tiling.js:2076:59
upgradeGnomeMonitors/<@file:///home/borna/.local/share/gnome-shell/extensions/[email protected]/utils.js:579:13
asyncCallback@resource:///org/gnome/gjs/modules/core/overrides/Gio.js:115:22
@resource:///org/gnome/shell/ui/init.js:21:20
(gnome-shell:16313): GNOME Shell-CRITICAL **: 12:11:59.888: TypeError: monitor is null
StackOverlay@file:///home/borna/.local/share/gnome-shell/extensions/[email protected]/stackoverlay.js:185:9
ClickOverlay@file:///home/borna/.local/share/gnome-shell/extensions/[email protected]/stackoverlay.js:133:21
monitorsChanged@file:///home/borna/.local/share/gnome-shell/extensions/[email protected]/tiling.js:2151:27
init/</<@file:///home/borna/.local/share/gnome-shell/extensions/[email protected]/tiling.js:2076:59
upgradeGnomeMonitors/<@file:///home/borna/.local/share/gnome-shell/extensions/[email protected]/utils.js:579:13
asyncCallback@resource:///org/gnome/gjs/modules/core/overrides/Gio.js:115:22
@resource:///org/gnome/shell/ui/init.js:21:20
(gnome-shell:16313): libmutter-CRITICAL **: 12:11:59.889: meta_display_get_monitor_geometry: assertion 'monitor >= 0 && monitor < n_logical_monitors' failed
(gnome-shell:16313): libmutter-CRITICAL **: 12:11:59.889: meta_display_get_monitor_geometry: assertion 'monitor >= 0 && monitor < n_logical_monitors' failed
(gnome-shell:16313): libmutter-CRITICAL **: 12:11:59.889: meta_display_get_monitor_geometry: assertion 'monitor >= 0 && monitor < n_logical_monitors' failed
(gnome-shell:16313): libmutter-CRITICAL **: 12:11:59.889: meta_display_get_monitor_geometry: assertion 'monitor >= 0 && monitor < n_logical_monitors' failed
(gnome-shell:16313): libmutter-CRITICAL **: 12:11:59.889: meta_display_get_monitor_geometry: assertion 'monitor >= 0 && monitor < n_logical_monitors' failed
(gsd-media-keys:16452): Gvc-CRITICAL **: 12:12:00.546: gvc_mixer_card_get_index: assertion 'GVC_IS_MIXER_CARD (card)' failed
(gnome-shell:16313): Clutter-WARNING **: 12:12:02.109: Can't update stage views actor <clone-container>[<StWidget>:0x557eaf8c60c0] is on because it needs an allocation.
(gnome-shell:16313): Clutter-WARNING **: 12:12:02.109: Can't update stage views actor <unnamed>[<ClutterActor>:0x557eb128f9f0] is on because it needs an allocation.
(gnome-shell:16313): Clutter-WARNING **: 12:12:02.109: Can't update stage views actor <unnamed>[<ClutterClone>:0x557eb11c0810] is on because it needs an allocation.
(gnome-shell:16313): Clutter-WARNING **: 12:12:02.109: Can't update stage views actor <unnamed>[<MetaWindowActorX11>:0x557eae2a1d30] is on because it needs an allocation.
(gnome-shell:16313): Clutter-WARNING **: 12:12:02.109: Can't update stage views actor <unnamed>[<MetaSurfaceActorX11>:0x557eae10e3f0] is on because it needs an allocation.
Note that there is no #PaperWM disabled logs at all. Just the one #PaperWM enabled from when I logged in.
... well I think you found the potential issue right here:
StackOverlay@file:///home/borna/.local/share/gnome-shell/extensions/[email protected]/stackoverlay.js:185:9
I still can't reproduce this, even with one monitor and xorg on my setup.
In any case, I've added a "no monitor" guard in StackOverlay.js. Can I get someone here to test this branch? and let me know if anything has changed on this branch (note: we might need to address a few corner-cases here).
git clone https://github.com/paperwm/PaperWM.git
cd PaperWM
git checkout fix-835-xorg-monitor-off-topbar-issue
./install.sh
(Note you might need to uninstall the extensions.gnome.org version first - you won't lose any settings or anything).
Then logout and login again and see if you can reproduce. If there's still issues, can you please paste the output (like you did above @glupi-borna) while turning off/on your monitor?
Thanks!
Still monitor is null, but now it's in monitorsChanged:
(gnome-shell:4583): GNOME Shell-CRITICAL **: 16:56:31.849: TypeError: monitor is null
monitorsChanged@file:///home/borna/.local/share/gnome-shell/extensions/[email protected]/tiling.js:2152:13
init/</<@file:///home/borna/.local/share/gnome-shell/extensions/[email protected]/tiling.js:2076:59
upgradeGnomeMonitors/<@file:///home/borna/.local/share/gnome-shell/extensions/[email protected]/utils.js:579:13
asyncCallback@resource:///org/gnome/gjs/modules/core/overrides/Gio.js:115:22
@resource:///org/gnome/shell/ui/init.js:21:20
(gnome-shell:4583): GNOME Shell-CRITICAL **: 16:56:31.849: TypeError: monitor is null
monitorsChanged@file:///home/borna/.local/share/gnome-shell/extensions/[email protected]/tiling.js:2152:13
init/</<@file:///home/borna/.local/share/gnome-shell/extensions/[email protected]/tiling.js:2076:59
upgradeGnomeMonitors/<@file:///home/borna/.local/share/gnome-shell/extensions/[email protected]/utils.js:579:13
asyncCallback@resource:///org/gnome/gjs/modules/core/overrides/Gio.js:115:22
@resource:///org/gnome/shell/ui/init.js:21:20
I went ahead and added another guard to the start of the loop there and tried it again:
(gnome-shell:9090): GNOME Shell-CRITICAL **: 17:03:51.814: TypeError: monitor is null
monitorsChanged@file:///home/borna/.local/share/gnome-shell/extensions/[email protected]/tiling.js:2224:34
init/</<@file:///home/borna/.local/share/gnome-shell/extensions/[email protected]/tiling.js:2076:59
upgradeGnomeMonitors/<@file:///home/borna/.local/share/gnome-shell/extensions/[email protected]/utils.js:579:13
asyncCallback@resource:///org/gnome/gjs/modules/core/overrides/Gio.js:115:22
@resource:///org/gnome/shell/ui/init.js:21:20
(gnome-shell:9090): GNOME Shell-CRITICAL **: 17:03:51.814: TypeError: monitor is null
monitorsChanged@file:///home/borna/.local/share/gnome-shell/extensions/[email protected]/tiling.js:2224:34
init/</<@file:///home/borna/.local/share/gnome-shell/extensions/[email protected]/tiling.js:2076:59
upgradeGnomeMonitors/<@file:///home/borna/.local/share/gnome-shell/extensions/[email protected]/utils.js:579:13
asyncCallback@resource:///org/gnome/gjs/modules/core/overrides/Gio.js:115:22
@resource:///org/gnome/shell/ui/init.js:21:20
I played whackamole like this for a bit, until errors were no longer showing up in the logs, but the problem still persists. I'm not familiar enough with the code to take it any further than that on my own, but I can try more stuff if you can point me in the right direction!
I also found some issues that look related: https://gitlab.gnome.org/tuxor1337/hidetopbar/-/issues/360 https://github.com/home-sweet-gnome/dash-to-panel/issues/508 https://github.com/home-sweet-gnome/dash-to-panel/issues/558
I'm not sure how useful any of that is, though.
Thanks @glupi-borna!
Could you take a fork and create a branch with your changes? Or something I can contribute too and get you to test? Let me know.
We may have disabled a bit too much (so layout call doesn't get triggered).
In any case, we may need to handle/address the case where monitor is null a bit more gracefully than currently.
Thanks for your work on this!
So weird that I still can't reproduce this at all, even on my Gnome 45.5 machine with one monitor.
git clone https://github.com/paperwm/PaperWM.git cd PaperWM git checkout fix-835-xorg-monitor-off-topbar-issue ./install.sh
I've made some changes to this branch @glupi-borna - when you get a chance could you check it out again and run the current code and let me know the output (and where is throws an exception?).
Done! This is logged now:
(gnome-shell:10410): GNOME Shell-CRITICAL **: 13:52:35.420: TypeError: monitor is null
monitorsChanged@file:///home/borna/.local/share/gnome-shell/extensions/[email protected]/tiling.js:2152:13
init/</<@file:///home/borna/.local/share/gnome-shell/extensions/[email protected]/tiling.js:2076:59
upgradeGnomeMonitors/<@file:///home/borna/.local/share/gnome-shell/extensions/[email protected]/utils.js:579:13
asyncCallback@resource:///org/gnome/gjs/modules/core/overrides/Gio.js:115:22
@resource:///org/gnome/shell/ui/init.js:21:20
So I tried the following:
monitorsChanged() {
// ...
let primary = Main.layoutManager.primaryMonitor;
// get monitors but ensure primary monitor is first
let monitors = Main.layoutManager.monitors.filter(m => m !== primary);
// only prepend the primary monitor if it exists
if (primary) {
monitors.unshift(primary);
}
// ...
I got more errors, which pointed to the setMonitor function. It seems to me that the problem stems from:
if (commit) {
this.monitor = monitor;
}
This sets this.monitor to null, which then has a bunch of knock-on effects all over the place. Obviously though, exiting this function early when monitor is null is not an option, like you said, since layout will never be called. I tried it anyway -- it just led to errors being thrown inside of the finish function in monitorsChanged, after activeSpace is set to undefined:
let activeSpace = recent?.[0] ?? this.monitors.get(primary);
activeSpace.activate(false, false); // activeSpace is undefined cause primary is null here
So weird that I still can't reproduce this at all, even on my Gnome 45.5 machine with one monitor.
Yeah, no idea why that is - I'm guessing that for some reason, my setup somehow causes the primary monitor to be reported as null, while yours does not. Maybe it's a DM issue? I'm using lightDM right now, I'll try switching to GDM and report back if that fixes the problem.
Could you take a fork and create a branch with your changes? Or something I can contribute too and get you to test? Let me know.
Sure, I can do that -- I'm just poking around though, since I'm really not that familiar with PaperWM's code yet, so most of the stuff I'm trying I just revert immediately. But honestly, I'm also fine with just using your branch, if that's less work for you. I can pull your stuff whenever and test it out, and if I figure anything out on my own, I'll let you know ASAP!
Thanks for your work on this!
Thank you! PaperWM is a breath of fresh air, coming from i3wm, and I'm very fortunate to have stumbled upon it, as I normally would not even have considered Gnome for my DE otherwise. It's great to see that it is well maintained, and I'm glad to be able to help, even if it's just a little bit. :)
Maybe it's a DM issue? I'm using lightDM right now, I'll try switching to GDM and report back if that fixes the problem.
I went ahead and tried this, and can confirm that the problem does not exist on GDM!
However, despite the behavior being good now, the same error is logged to the console still!
(gnome-shell:25748): GNOME Shell-CRITICAL **: 18:24:00.374: TypeError: monitor is null
monitorsChanged@file:///home/borna/.local/share/gnome-shell/extensions/[email protected]/tiling.js:2152:13
init/</<@file:///home/borna/.local/share/gnome-shell/extensions/[email protected]/tiling.js:2076:59
upgradeGnomeMonitors/<@file:///home/borna/.local/share/gnome-shell/extensions/[email protected]/utils.js:579:13
asyncCallback@resource:///org/gnome/gjs/modules/core/overrides/Gio.js:115:22
@resource:///org/gnome/shell/ui/init.js:21:20
Of note is that, on lightDM, this error is printed twice, while on GDM, the error is printed only once. I'm guessing that lightDM somehow triggers the monitor change event more than once?
EDIT: Actually, hold on, that might be wrong. Turns out that when I switched to GDM, my Gnome session started under Wayland instead of Xorg. For some reason, the Gnome on Xorg does not work at all from GDM.
Yes, it doesn't seem to be an issue on wayland at all.
In any case, unless I can reproduce this, there's little chance I'll be able to isolate and fix this (which means I'll have to leave it for someone else).
I haven't been able to reproduce this on Endeavour OS (Arch based) or Fedora (both 39 and 40). Last ditch attempt will be to install void linux or NixOS, and attempt to reproduce there.
I'll put up a help wanted label on this.
@Lythenas or @Thesola10, have you ever (or are you now) seeing this issue on X11?
Of note is that, on lightDM, this error is printed twice, while on GDM, the error is printed only once. I'm guessing that lightDM somehow triggers the monitor change event more than once?
@jtaala I think there's something to this -- the problem does not reproduce on Wayland, like you said. I did some more testing and found that, if I turn my display off and on when the layout is in the broken state, when the display comes on, it is fixed again.
Now, the main difference in the logs between Wayland and Xorg is that Xorg reports the (gnome-shell:25748): GNOME Shell-CRITICAL **: 18:24:00.374: TypeError: monitor is null error twice, but Wayland only reports it once.
So maybe the cause of the problem is the 'monitors-changed' event being fired twice on Xorg, which somehow messes up the internal state and causes the windows to be laid out wrong on the second time around. Wayland, then, does not have this problem because it only triggers the event once.
In any case, unless I can reproduce this, there's little chance I'll be able to isolate and fix this (which means I'll have to leave it for someone else).
If you're okay with it, I'm going to try and dedicate some more time to getting this fixed, and I'll write anything I find here, in case somebody else wants to have a go at it.
Thanks for your efforts here @glupi-borna. It's a bit hard, as I'm adding changes blind (can't test this).
On xorg on endeavour and Fedora, I still can't reproduce.
In any case, I've put in a few more changes to check monitors in monitorChanged function. Can you try/test and report back on behaviour in
git checkout fix-835-xorg-monitor-off-topbar-issue
git pull
logout/login as usual.
If you're okay with it, I'm going to try and dedicate some more time to getting this fixed, and I'll write anything I find here, in case somebody else wants to have a go at it.
100% - good luck, let me know what you find.
Sorry, I think I can't really help here. I tried to reproduce it but wasn't able to. I could try on my work laptop but there I'm still on Gnome 42, so not sure if that would help.
Sorry, I think I can't really help here. I tried to reproduce it but wasn't able to. I could try on my work laptop but there I'm still on Gnome 42, so not sure if that would help.
Thanks @Lythenas - it's very strange, it seems to affect only some distros when using X11.
I also can't reproduce this on my work laptop on Xorg. On Ubuntu 22 using gnome 42.9. But not sure if that is useful, since you have the issue on the latest version.