Unresponsive desktop after unlock

[divVerent]

When light-locker starts while input is already grabbed, it tries to force the grab like this:

https://github.com/the-cavalry/light-locker/blob/master/src/gs-grab-x11.c#L498

        XSetInputFocus (GDK_DISPLAY_XDISPLAY (gdk_display_get_default ()), None, RevertToNone, CurrentTime);

The direct consequence of this is:

• Focus is lost from the current window (that's probably the intended part; your idea probably is that doing this sends a FocusOut to possible context menus, which likely will close themselves on receiving that and thereby relinquish their grab).
• Focus can be regained by switching to another application window and then back.

However, this also has some unintended consequences:

• Window manager shortcuts such as Alt-Tab stop working. This is unfortunate as these would otherwise be quite effective at restoring focus after unlock. Why do they break? Because they're typically passive grabs, which only are active on the path from root window to focus window and all the focus window's children.
• If the only application window active is a fullscreen window, regaining focus may require closing the application. If it is even a fullscreen window using the _NET_WM_STATE_FULLSCREEN hint, then it has no window decorations; many such windows are created by games only supporting keyboard input in many situations, so this can cause a situation where the desktop is permanently unresponsive.

(BTW in the concrete case this has been caused by running another screen locker [doesn't matter which one, reproduced using slock and xsecurelock] inside Xfce4 while not knowing that light-locker was enabled too; of course that was clearly misconfiguration but nevertheless there are more situations causing this and it's simply never a good thing to happen)

In fact, ICCCM even says about XSetInputFocus:

Clients that set the input focus need to decide a value for the revert-to field of the SetInputFocus request. This determines the behavior of the input focus if the window the focus has been set to becomes not viewable. The value can be any of the following: [...] None - Using this value causes problems if the window manager reparents the window, as most window managers will, and then crashes. The input focus will be None, and there will probably be no way to change it.

Note that neither PointerRoot nor None is really safe to use.

I suggest one or more of the following fixes:

• Use PointerRoot rather than None. This switches focus to the root window, so window manager key bindings stay active and thus the user can fix focus using Alt-Tab again.
• Use your own window rather than None. Window manager keeps control, but the set of passive grabs that may apply is lower. Again, user can fix focus using Alt-Tab again.
• Given you're already calling XGetInputFocus beforehand but not using its returned window of previous window, just restore the focus back whenever the grab succeeds or you're exiting, whichever comes first. Of course, as the window may be gone by then, this may need handling X11 errors, which you can't prevent by doing this inside a XGrabServer critical section as you're relying on other applications to cooperate.
• Try another method of forcing your input focus in; xsecurelock e.g. solves the same issue by enumerating all windows top to bottom, unmapping them, trying if grabbing now works (one by one, to limit damage), and mapping them again. This is still quite intrusive and may cause rearrangement of windows especially in tiling window managers, but does not require any cooperation of other applications unlike the XSetInputFocus method which relies on context menus closing in response to that. Because of that you can even do this inside a XGrabServer critical section and not worry about race conditions.