#1094 Windows Can Bypass Xscreensaver Lock Screen

[Jdogzz]

Windows, such as the notifications in Chromium and Steam, can bypass the lock screen in xscreensaver. To quote the help found on the FAQ at the Xscreensaver website,
"you should be mapping windows with XRestackWindows instead of XRaiseWindow, to ensure that managed windows always appear below override-redirect windows."
http://www.jwz.org/xscreensaver/faq.html#popup-windows

[Mario Rugiero]

From the same link:
"It is also possible that the application that is popping up the window is doing so using an override-redirect window of its own. (This is currently the case with GTK_WINDOW_POPUP style dialogs.) In that case, it is impossible for either xscreensaver or the window manager to prevent those windows from popping up, since override-redirect windows, by definition, bypass the window manager."

I might check later how Fluxbox handles it, but I bet Chromium's case is unsolvable. I don't know about Steam, though.

[Thomas Luebking]

override_redirect'ed windows are ignored by the WM

xscreensaver will have to "protect" itself against those by catching MapNotify events and re-raise itself. This isn't 100% secure (the new window will be on top for a roundtrip) but the only thing that can be done here (and not by the WM)

As a "feature" fluxbox could detect xscreensaver and do what it should do, but that's not the WMs job and pretty wonky (because of "detect" being heuristic and limited to certain screensaver implementations)

[Thomas Luebking]

Those notifications are indeed override_redirects, so this is a "bug" between the client (chromium) and xscreensaver. Managing override_redirects from the WM perverts the idea of override_redirect, bears some overhead (for we'd need to track the clients actions) and can easily lead to races (if the client desperately tries to get the window and top and the WM desperately tries to prevent that)