Dash-to-panel: When unlocking lock screen maximized windows sometimes overlap the panel

[skontar]

Describe the bug
When unlocking lock screen, sometimes (5-10% times?) some maximized windows get maximized also under the panel, and sometimes they do not. Seems like a race condition when panel re-appears on unlock.

Linux distribution and version
Fedora 33

GNOME Shell version
GNOME Shell 3.38.2

Dash-to-Panel version
40

Where was Dash-to-Panel installed from?
The GNOME extensions website

Additional Info
It is easier to notice if the panel is transparent, however it also happens when it is opaque.

It is easier to test when "Unblank lock screen" extensions is installed, because you can lock without screen turning off - or you have to unlock really quickly :smile: before it turns off. I have checked that it does also happen with no extensions other than dash-to-panel. It is just convenient.

I have noticed similar issues with different extensions (their re-enabling after unlock seems to induce race conditions), so it may be caused by newer versions of GNOME shell.

[skontar]

It does not seem to happen on XOrg, only Wayland. On XOrg I can sometimes see the problem, but only for a fraction of a second, then it fixes itself.

It is most common with Firefox, sometimes Terminal, especially if those are in foreground.

It is easier to hit with some other extensions enabled (like "Tray Icons: Reloaded"), but it happens even without them, just less often.

[skontar]

No other extensions activated:

https://user-images.githubusercontent.com/10827040/103467975-d3be7c80-4d54-11eb-9bf2-4d6196b14fa4.mp4

[skontar]

Interestingly enough, downgrading to GNOME Shell to 3.38.1 resolves the issue.

You can also see that when multiple windows are maximized, on 3.38.2 maximized windows quickly blink through the panel before they are handled correctly. On 3.38.1 this just does not happen.

It is also easily reproducible in GNOME Boxes VM of Fedora 33.

[aswild]

As an extra data point, I can reproduce this pretty consistently on my machine. Arch Linux, gnome shell 3.38.2 (Arch version 1:3.38.2+22+g3a343a8aa-1), wayland, and dash to panel master commit ec13897509f08e62c1cd5e66a7a9064eda2ace44 installed from source.

It looks like the issue is more likely to happen when I have multiple monitors enabled. With a single screen, windows are usually maximized correctly after unlock.

[skontar]

You can also see that when multiple windows are maximized, on 3.38.2 maximized windows quickly blink through the panel before they are handled correctly. On 3.38.1 this just does not happen.

This can be actually seen in my video around 0:17, if you go frame-by-frame.

[mgrewe]

I can confirm the issue. However, I have the panel on top such that the window's title bar gets overlapped. I'm on Arch with gnome 3.28.2 and official dash-to-panel extensions version 40.

[icher]

Dash to dock (Ubuntu dock) also affected of this bug.

[aswild]

I bisected this issue to gnome-shell commit e6369547dd86f395a8d44eea71f999fa1e5fbe42. Reverting that commit on top of 3.38.3 fixes this issue with dash-to-panel for me.

This dash-to-dock issue appears to be the same bug: https://github.com/micheleg/dash-to-dock/issues/1370

[eraser215]

Can confirm I also have this issue on:
Fedora 33
gnome-shell-3.38.3-1
Dash to Panel 40 from extensions.gnome.org

[matteoarrighi]

Can confirm. It doesn't have to logout though, it also happens when the screen only goes blank and I can still access the session by pressing a key or moving the cursor, thus without logging in.
Fedora 33
gnome-shell 3.38.3
dash-to-panel 40 from extensions.gnome.org

[Jmennius]

Happens to me all the time on Wayland (I'd say the chance of this happening is much more than 50%).
Fedora 33 with GNOME 3.38.3, dash-to-panel from master (as well as v40).

I can help with testing/debugging.

[mmacura311]

Can confirm, happens most of the time but not always.
Fedora 33
gnome-shell-3.38.3 on wayland
dash-to-panel from extensions.gnome.org

[skontar]

As a workaround I have created a bash script which allows me to quickly disable/re-enable the plugin, so it is basically a reload and fixes any visual or layout glitches. I bound it to Super+R.

#!/bin/bash

PANEL="[email protected]"
ICONS="[email protected]"


reload() {
    extension="$1"

    extensions=$( gsettings get org.gnome.shell enabled-extensions )
    extensions_without=$( sed -r "s/'$extension'//;s/\[, /[/;s/, , /, /;s/, \]/]/" <<< "$extensions" )

    gsettings set org.gnome.shell enabled-extensions "$extensions_without"
    gsettings set org.gnome.shell enabled-extensions "$extensions"
}

reload "$PANEL"
reload "$ICONS"

As a followup I have created another script, which monitors unlock dbus messages and runs the first script with 0.5 second delay after unlock.

#!/bin/bash

dbus-monitor --session "type='signal', interface=org.gnome.ScreenSaver, member=WakeUpScreen" |
while read message; do
    if [[ "$message" =~ "WakeUpScreen" ]]; then
        sleep 0.5
        reload-panel
    fi
done

And finally I have created a desktop file in ~/.config/autostart to start listening for unlock events automatically.

[Desktop Entry]
Type=Application
Name=unlock-monitor
Exec=unlock-monitor

I know it is rather cumbersome but may be helpful to people who have to lock their screens often and do not want to use gnome-shell <=3.36.

[Jmennius]

@skontar thank you!
What's up with gnome-shell > 3.36, can you point us somewhere so that we can educate ourselves?

[skontar]

@Jmennius the problem was introduced with gnome-shell 3.38. If you downgrade gnome-shell to 3.36 the problem disappears. @aswild found an exact commit which caused it https://github.com/home-sweet-gnome/dash-to-panel/issues/1252#issuecomment-767666943 .

[aswild]

Looks like this got upstream attention in mutter: https://gitlab.gnome.org/GNOME/mutter/-/issues/1627 and https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1755

I'll try backporting that mutter commit to 3.38 when I get a chance.

Update: The Arch repos have updated to gnome 3.38.4, where this bug still exists. I tried backporting the mutter commit above to 3.38.4 but it didn't cherry-pick cleanly. Instead I first cherry-picked cda26b493eac599987a52fea885a098877086f3d to 3.38.4, which had smaller merge conflicts, then I was able to cherry-pick 236e9ec68fc56fad5af35e6f663a40ada1b6d0af.

It compiles and tests pass and I can no longer reproduce the issue, so that's a good sign. If anybody else wants to try recompiling mutter with this hastily backported fix, the patch file is here:
mutter-3.38.4-fix-window-size-on-unlock.patch.txt

[coling]

If anybody else wants to try recompiling mutter with this hastily backported fix, the patch file is here:
mutter-3.38.4-fix-window-size-on-unlock.patch.txt

Just for reference, I found this patch on top of mutter 3.38.3 fixed the issue for me in Firefox, but not Gnome Terminal (only minimal testing so far). Both are Wayland apps.

I'll try on top of 3.38.4 to see if other fixes there help.

[Jmennius]

I still observe the issue with GNOME 40 and people have also reported this in the upstream issue...