GNOME Bugzilla – Bug 771235
Open menu blocks Screen lock
Last modified: 2016-11-02 13:24:37 UTC
If any menu is kept open, screen lock fails. How to reproduce: 1. Open gnome-terminal (any app with classic menu). 2. Click some menu and keep it open. 3. Idle till the time required to lock the screen Result: A notification is shown that some application blocked lock screen. Expected Result: Lock/Fade screen as configured. This can also be reproduced with right click menus. Say, the right click menu in Nautilus file/directory view (not the one in the sidebar or the main menu (F10))
This is a limitation of X. Apps/toolkits usually grab the keyboard and pointer when showing a popup menu, which means that the lock screen cannot grab those devices anymore. With no grab, all input on the lock screen (read: your password) would actually be send to the focused application, which is obviously not what you would want. The only other option we have is to fail (and communicate that to the user), which is what we do ...
This also happens in wayland. Tested using nautilus and gnome-terminal. Feel free to close the bug if that's too expected.
(In reply to Mohammed Sadiq from comment #2) > This also happens in wayland. No it doesn't. At least, it doesn't here. Are you 100% sure you tested on a wayland session?
Created attachment 337610 [details] Fail to lock notification screenshot (image) I can reproduce this on Debian testing. The packages I have: gnome-shell: 3.22.0 wayland-protocols: 1.7 libwayland-bin: 1.11 Please see the attached screenshot. Thanks
Created attachment 338609 [details] [review] End an existing wayland popup grab when starting other grab types Wayland popup grabs, unlike other grab types, can be safely cancelled so there's no reason to deny new grab requests if a wayland popup is on. In particular, this allows entering the overview via a keybinding or locking the screen while a wayland popup has a grab which is something that's been advertised as a wayland improvement over X. -- Ironically we were already able to lock the screen when X popups were on...
Review of attachment 338609 [details] [review]: ::: src/core/display.c @@ +1837,3 @@ + { + MetaWaylandSeat *seat = meta_wayland_compositor_get_default ()->seat; + meta_wayland_pointer_end_popup_grab (seat->pointer); What exactly does this fix? It's not necessary for GRAB_OP_COMPOSITOR, and all other grab ops I tried are still blocked by the popup ...
Created attachment 338832 [details] [review] compositor: End a wayland popup grab when starting a compositor grab Wayland popup grabs, unlike other grab types, can be safely cancelled so there's no reason to deny compositor grab requests if a wayland popup is on. In particular, this allows entering the overview via a keybinding or locking the screen while a wayland popup has a grab which is something that's been advertised as a wayland improvement over X. -- (In reply to Florian Müllner from comment #6) > What exactly does this fix? It's not necessary for GRAB_OP_COMPOSITOR, and > all other grab ops I tried are still blocked by the popup ... Right, I added it to meta_display_begin_grab_op() too just for consistency but it's true that all grab ops started through that function are currently (and I suppose it won't change) triggered from input events which themselves either don't make sense on popups like keyboard window move/resize or cancel the grab like button events on other windows. So, I removed that hunk.
Review of attachment 338832 [details] [review]: LGTM
Attachment 338832 [details] pushed as 236417b - compositor: End a wayland popup grab when starting a compositor grab