After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 752956 - wayland: xscreensaver unlock dialog not focused in gnome-shell/mutter
wayland: xscreensaver unlock dialog not focused in gnome-shell/mutter
Status: RESOLVED OBSOLETE
Product: mutter
Classification: Core
Component: wayland
3.16.x
Other Linux
: Normal normal
: ---
Assigned To: mutter-maint
mutter-maint
Depends on:
Blocks:
 
 
Reported: 2015-07-28 09:23 UTC by Olivier Fourdan
Modified: 2021-07-05 13:44 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
[PATCH] window: Allow some O-R windows to be focused (3.38 KB, patch)
2016-06-17 13:50 UTC, Olivier Fourdan
none Details | Review
[PATCH] window: Allow some O-R windows to be focused (3.37 KB, patch)
2016-06-20 08:49 UTC, Olivier Fourdan
none Details | Review

Description Olivier Fourdan 2015-07-28 09:23:15 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
Comment 1 Jasper St. Pierre (not reading bugmail) 2015-07-28 15:08:46 UTC
Oof. That's bad. Why does the xscreensaver dialog appear on top? Is it set to be O-R?
Comment 2 Olivier Fourdan 2015-07-28 15:13:41 UTC
Yeap, both the unlock dialog and the screensaver window are override redirect windows.
Comment 3 Olivier Fourdan 2015-07-29 07:35:04 UTC
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).
Comment 4 Jasper St. Pierre (not reading bugmail) 2015-07-29 15:48:56 UTC
Right, you're never supposed to focus O-R windows.
Comment 5 Olivier Fourdan 2015-07-29 15:59:18 UTC
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.
Comment 6 Olivier Fourdan 2016-06-17 13:50:02 UTC
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.
Comment 7 Olivier Fourdan 2016-06-20 08:49:41 UTC
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
Comment 8 Rui Matos 2016-07-08 16:00:50 UTC
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 .
Comment 9 GNOME Infrastructure Team 2021-07-05 13:44:51 UTC
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.