Open Xfce4 Applications Menu prevents XScreenSaver lock on lid close and suspend

[andrewdavidwong]

Qubes OS version:

R3.2

Affected component(s):

Xfce4 4.12 + XScreenSaver 5.36

---

Steps to reproduce the behavior:

1. Set the Xfce4 power settings to suspend (S3 sleep) when the laptop lid is closed.
2. Set XScreenSaver to lock the screen when the laptop lid is closed.
3. Set XScreenSaver to lock the screen on suspended (S3 sleep).
4. Verify that it works by closing the laptop lid, waiting for suspend, and opening the lid again.
5. XScreenSaver prompts you to enter your passphrase, as expected. Enter your passphrase to unlock the screen.
6. Now, click on the Xfce4 Applications Menu (aka "Start Menu").
7. Leaving the menu open, close the laptop lid.
8. Wait for the laptop to suspend.
9. Open the lid again.
10. The screen is completely unlocked, and you have full access to the system without having to enter the screen locker passphrase.

Expected behavior:

The screen should lock properly regardless of which menus are open in dom0.

Actual behavior:

Having the Applications Menu open prevents the screen from locking. Similarly, having a "Launcher" menu open (a type of task bar widget for holding shortcut buttons) prevents screen locking in the same way.

On my machine, this is reliably reproducible every time.

General notes:

In Qubes, one of the main purposes of the screen locker is to protect the system from physical threats. For example, a user may need to quickly shut her laptop lid when confronted by an adversary, or a thief may close the laptop while snatching it from a user in a coffee shop. In both cases, if the user had the Applications Menu or a Launcher menu open when the lid was shut, an attacker with no technical skill would be able to gain full access to the system simply by opening the lid.

---

Related issues:

#1917

[andrewdavidwong]

Similarly, having the Applications Menu or a Launcher menu open prevents using a keyboard shortcut to lock the screen:

1. Assign a keyboard shortcut to lock the screen.
2. Open the Applications Menu.
3. Press the keyboard shortcut.
4. The screen does not lock.

[andrewdavidwong]

Similarly, having the Applications Menu or a Launcher menu open prevents using a keyboard shortcut to lock the screen:

1. Assign a keyboard shortcut to lock the screen.
2. Open the Applications Menu.
3. Press the keyboard shortcut.
4. The screen does not lock.

[esote]

I can reproduce this on R4. I have the same power saving settings (lock & suspend on lid close). If I open the application menu and close the lid, it does not suspend. As I open the lid, it is unlocked (I can see all open windows as if it were unlocked), but then locks within 1 or 2 seconds.

However, as you point out, this problem is not exclusive to the application menu. When I open "Screensaver Preferences", and click the dropdown for "Mode", leave the dropdown open, and close the lid, it does not suspend or lock. Ctrl+Alt+Delete does not lock the screen as well when the dropdown is open.

I wonder if it has to do with the fact that it tries to both lock and suspend at the same time (maybe?), when it should instead lock first then suspend. Just a guess.

[esote]

I can reproduce this on R4. I have the same power saving settings (lock & suspend on lid close). If I open the application menu and close the lid, it does not suspend. As I open the lid, it is unlocked (I can see all open windows as if it were unlocked), but then locks within 1 or 2 seconds.

However, as you point out, this problem is not exclusive to the application menu. When I open "Screensaver Preferences", and click the dropdown for "Mode", leave the dropdown open, and close the lid, it does not suspend or lock. Ctrl+Alt+Delete does not lock the screen as well when the dropdown is open.

I wonder if it has to do with the fact that it tries to both lock and suspend at the same time (maybe?), when it should instead lock first then suspend. Just a guess.

[esote]

I have found more information that may prove relevant:

Per the ArchLinux wiki, an alternative is light-locker with xfce4 because "light-locker integrates well with xfce4-power-manager" -- so it may be worth investigation.

light-locker is forked from gnome-screensaver and relies upon lightdm (appears to be already installed in dom0), for what it's worth. Although I would prefer fixing xscreensaver before changing to a different screen locker.

[esote]

I have found more information that may prove relevant:

Per the ArchLinux wiki, an alternative is light-locker with xfce4 because "light-locker integrates well with xfce4-power-manager" -- so it may be worth investigation.

light-locker is forked from gnome-screensaver and relies upon lightdm (appears to be already installed in dom0), for what it's worth. Although I would prefer fixing xscreensaver before changing to a different screen locker.

[marmarek]

Background: the problem here is because inherent problem with X11. Open menus and some other things can get GrabKeyboard, preventing other applications from receiving keys (and switching focus), and also from getting GrabKeyboard. This means that:

• When such menu is open, whatever part of xfce is responsible for handling screen lock key combo, it doesn't receive it immediately.
• Even when xscreensaver is triggered anyway, it tries to get GrabKeyboard, and must wait for other application to release it.

Note that thanks to Qubes GUI, this all is accessible only to dom0 application.

light-locker might indeed be an option, as it starts separate X server for the locker application, so it isn't blocked by anything in the original one (as long as screenlock is triggered). At least in theory. But starting second X server in dom0 cause problems on Qubes. I think it should be better in 4.0 (thanks to QubesOS/qubes-gui-daemon@a333f7c), but for 3.2 it isn't that simple.

[marmarek]

Background: the problem here is because inherent problem with X11. Open menus and some other things can get GrabKeyboard, preventing other applications from receiving keys (and switching focus), and also from getting GrabKeyboard. This means that:

• When such menu is open, whatever part of xfce is responsible for handling screen lock key combo, it doesn't receive it immediately.
• Even when xscreensaver is triggered anyway, it tries to get GrabKeyboard, and must wait for other application to release it.

Note that thanks to Qubes GUI, this all is accessible only to dom0 application.

light-locker might indeed be an option, as it starts separate X server for the locker application, so it isn't blocked by anything in the original one (as long as screenlock is triggered). At least in theory. But starting second X server in dom0 cause problems on Qubes. I think it should be better in 4.0 (thanks to QubesOS/qubes-gui-daemon@a333f7c), but for 3.2 it isn't that simple.

[donob4n]

Well, at least I can confirm this not happening in KDE which also seems more stable and reliable in Qubes 4 than 3.2.

[donob4n]

Well, at least I can confirm this not happening in KDE which also seems more stable and reliable in Qubes 4 than 3.2.