GNOME Bugzilla – Bug 752956
wayland: xscreensaver unlock dialog not focused in gnome-shell/mutter
Last modified: 2021-07-05 13:44:51 UTC
If xscreensaver gets started under GNOME Wayland (which happens if there is an xdg autostart desktop file installed along with the package), it runs in Xwayland. Because there is no such thing as explicit grabs in Wayland [1], the keyboard and pointer grab set by screensaver will succeed (from the xscreeensaver point of view) and therefore both GNOME Wayland screensaver and xscreensaver will run together. Things get more complicated when the user needs to unlock the session. GNOME Wayland locking dialog shows up and can be successfully unlocked and then the xscreensaver unlock dialog shows up, running in Xwayland. But mutter (gnome-shell) will not focus it, so that typing will actually not go to the xscreensaver unlock dialog but to whatever Wayland window is active (when it's irc, well, the user will unknowingly and happily type his password on irc - don't laugh, it happened to me) The solution would be *not* to start xscreesnaver and therefore remove the xdg autostart desktop file, which his the goal of the downstream bug https://bugzilla.redhat.com/show_bug.cgi?id=1200414 Yet, if xscreensaver gets started, the issue will still arise. Ideally, it would be better to avoid the focus issue in the first place. I modified xscreensaver to issue a XSetInputFocus() on its own window as soon as a MapNotify event is received (as it would be done in X11) to force input focus to be set on the unlock dialog and not rely solely on the grabs, but it still fails randomly in mutter/Xwayland because of this: "Focus change has no effect, because there is no matching wayland surface" So I suspect there is a race condition in mutter that prevents this from working randomly. Could be related to bug 726123 [1] http://wayland.freedesktop.org/docs/html/ch04.html#sect-Protocol-Input
Oof. That's bad. Why does the xscreensaver dialog appear on top? Is it set to be O-R?
Yeap, both the unlock dialog and the screensaver window are override redirect windows.
meta_display_sync_wayland_input_focus() gets called after GNOME screen shield is unlocked but, from what I can see, it's not focusing the xscreensaver window but the gnome-terminal window underneath it (gnome-terminal being the only other app running in my test).
Right, you're never supposed to focus O-R windows.
Yeap, agreed, a window manager should ignore o-r windows (it won't even receive map requests for those), but xscreensaver grabs the pointer and keyboard so, in X11, it doesn't even need the window manager to give it focus. Yet weston handles that gracefully but I'm not sure how. Still digging.
Created attachment 329956 [details] [review] [PATCH] window: Allow some O-R windows to be focused Some clients try to map a fullscreen override-redirect window while grabbing the pointer and keyboard to prompt the user for a password. While this works fine on X11 where active keyboard grabs are supported, this cannot work under Xwayland because Wayland doesn't have active grabs. As a result, when such an application is ran under Xwayland, not only the keyboard cannot be grabbed, but mutter will not focus override-redirect windows, so the keyboard focus will remain on another covered Wayland native window without the user knowing. To avoid this issue, allow mutter to set focus on override-redirect windows when covering an entire monitor.
Created attachment 330053 [details] [review] [PATCH] window: Allow some O-R windows to be focused v2: focus or not META_WINDOW_OVERRIDE_OTHER windows based solely on the meta_window_is_monitor_sized() - i.e. use "=" not "|=" so that we don't focus just any META_WINDOW_OVERRIDE_OTHER by mistake. Note: This patch is still mostly an RFC, but it seems it does fix the issue with https://bugs.freedesktop.org/show_bug.cgi?id=96547
Review of attachment 330053 [details] [review]: ::: src/core/window.c @@ -4263,3 @@ MetaWindow *modal_transient; - g_return_if_fail (!window->override_redirect); I'm not sure about this. Owen explicitly added these checks in commit 27fb5fbbca21a5af6e48bdb02e414a606865a32a , I'd like to have his opinion. Also relevant seems to be commit df8234c5e37f4bf234cc895f703f8a1fdaeda3a1 . In fact the early bail outs for OR windows added to meta_window_set_focused_internal() by that patch don't look correct to me since they mean we don't emit the ::focus signal on them and we're also not grabbing mouse button events necessary for click-to-focus .
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/mutter/-/issues/ Thank you for your understanding and your help.