GNOME Bugzilla – Bug 440515
Does not activate screensaver if menu is open
Last modified: 2014-08-20 19:15:10 UTC
[ Forwarded from http://bugs.debian.org/423570 ] The screensaver is not activated if a context menu ("right click menu"), is open. The following is printed in debug mode: [gs_grab_get_keyboard] gs-grab-x11.c:166 (19:59:35): Grabbing keyboard widget=1400003 [gs_grab_get_keyboard] gs-grab-x11.c:175 (19:59:35): Couldn't grab keyboard! (AlreadyGrabbed) [gs_grab_get_keyboard] gs-grab-x11.c:166 (19:59:36): Grabbing keyboard widget=1400003 [gs_grab_get_keyboard] gs-grab-x11.c:175 (19:59:36): Couldn't grab keyboard! (AlreadyGrabbed) [gs_grab_get_keyboard] gs-grab-x11.c:166 (19:59:37): Grabbing keyboard widget=1400003 [gs_grab_get_keyboard] gs-grab-x11.c:175 (19:59:37): Couldn't grab keyboard! (AlreadyGrabbed) [gs_grab_get_keyboard] gs-grab-x11.c:166 (19:59:38): Grabbing keyboard widget=1400003 [gs_grab_get_keyboard] gs-grab-x11.c:175 (19:59:38): Couldn't grab keyboard! (AlreadyGrabbed) [gs_grab_get_mouse] gs-grab-x11.c:195 (19:59:39): Grabbing mouse widget=1400003 [gs_grab_get_mouse] gs-grab-x11.c:195 (19:59:40): Grabbing mouse widget=1400003 [gs_grab_get_mouse] gs-grab-x11.c:195 (19:59:41): Grabbing mouse widget=1400003 [gs_grab_get_mouse] gs-grab-x11.c:195 (19:59:42): Grabbing mouse widget=1400003 [gs_grab_grab_window] gs-grab-x11.c:446 (19:59:43): Couldn't grab pointer! (AlreadyGrabbed) [watcher_idle_notice_cb] gs-monitor.c:183 (19:59:43): Could not grab the keyboard so not performing idle warning fade-out [_gs_watcher_set_session_idle_notice] gs-watcher-x11.c:500 (19:59:43): Changing idle notice state: 1 [idle_timer] gs-watcher-x11.c:1114 (19:59:43): in idle timer [watcher_idle_cb] gs-monitor.c:110 (19:59:43): Idle signal detected: 1 [gs_listener_set_session_idle] gs-listener-dbus.c:540 (19:59:43): Setting session idle: 1 [listener_check_activation] gs-listener-dbus.c:405 (19:59:43): Checking for activation [listener_check_activation] gs-listener-dbus.c:420 (19:59:43): Trying to activate [gs_grab_grab_root] gs-grab-x11.c:483 (19:59:43): Grabbing the root window [gs_grab_get_keyboard] gs-grab-x11.c:166 (19:59:43): Grabbing keyboard widget=4D [gs_grab_get_keyboard] gs-grab-x11.c:175 (19:59:43): Couldn't grab keyboard! (AlreadyGrabbed) [gs_grab_get_keyboard] gs-grab-x11.c:166 (19:59:44): Grabbing keyboard widget=4D [gs_grab_get_keyboard] gs-grab-x11.c:175 (19:59:44): Couldn't grab keyboard! (AlreadyGrabbed) [gs_grab_get_keyboard] gs-grab-x11.c:166 (19:59:45): Grabbing keyboard widget=4D [gs_grab_get_keyboard] gs-grab-x11.c:175 (19:59:45): Couldn't grab keyboard! (AlreadyGrabbed) [gs_grab_get_keyboard] gs-grab-x11.c:166 (19:59:46): Grabbing keyboard widget=4D [gs_grab_get_keyboard] gs-grab-x11.c:175 (19:59:46): Couldn't grab keyboard! (AlreadyGrabbed) [gs_grab_nuke_focus] gs-grab-x11.c:375 (19:59:47): Nuking focus [gs_grab_get_keyboard] gs-grab-x11.c:166 (19:59:47): Grabbing keyboard widget=4D [gs_grab_get_keyboard] gs-grab-x11.c:175 (19:59:47): Couldn't grab keyboard! (AlreadyGrabbed) [gs_grab_get_keyboard] gs-grab-x11.c:166 (19:59:48): Grabbing keyboard widget=4D [gs_grab_get_keyboard] gs-grab-x11.c:175 (19:59:48): Couldn't grab keyboard! (AlreadyGrabbed) [gs_grab_get_keyboard] gs-grab-x11.c:166 (19:59:49): Grabbing keyboard widget=4D [gs_grab_get_keyboard] gs-grab-x11.c:175 (19:59:49): Couldn't grab keyboard! (AlreadyGrabbed) [gs_grab_get_keyboard] gs-grab-x11.c:166 (19:59:50): Grabbing keyboard widget=4D [gs_grab_get_keyboard] gs-grab-x11.c:175 (19:59:50): Couldn't grab keyboard! (AlreadyGrabbed) [gs_grab_get_mouse] gs-grab-x11.c:195 (19:59:51): Grabbing mouse widget=4D [gs_grab_get_mouse] gs-grab-x11.c:195 (19:59:52): Grabbing mouse widget=4D [gs_grab_get_mouse] gs-grab-x11.c:195 (19:59:53): Grabbing mouse widget=4D [gs_grab_get_mouse] gs-grab-x11.c:195 (19:59:54): Grabbing mouse widget=4D [gs_grab_grab_window] gs-grab-x11.c:446 (19:59:55): Couldn't grab pointer! (AlreadyGrabbed) [listener_active_changed_cb] gs-monitor.c:277 (19:59:55): Unable to set manager active: 1 [gs_listener_set_active] gs-listener-dbus.c:517 (19:59:55): Active-changed signal not handled [gs_listener_set_session_idle] gs-listener-dbus.c:566 (19:59:55): Idle activation failed [_gs_watcher_set_session_idle] gs-watcher-x11.c:527 (19:59:55): Idle changed signal not handled: 1 [watcher_idle_notice_cb] gs-monitor.c:170 (19:59:55): Idle notice signal detected: 0 [watcher_idle_notice_cb] gs-monitor.c:194 (19:59:55): manager not active, performing fade cancellation [gs_fade_reset] gs-fade.c:634 (19:59:55): Resetting fade [_gs_watcher_set_session_idle_notice] gs-watcher-x11.c:500 (19:59:55): Changing idle notice state: 0 [maybe_send_signal] gs-watcher-x11.c:1068 (19:59:55): Idle signal was not handled, restarting watcher [gs_watcher_set_active] gs-watcher-x11.c:730 (19:59:55): turning watcher: OFF [_gs_watcher_set_active_internal] gs-watcher-x11.c:713 (19:59:55): Stopping idle watcher [gs_watcher_set_active] gs-watcher-x11.c:730 (19:59:55): turning watcher: ON [_gs_watcher_set_active_internal] gs-watcher-x11.c:717 (19:59:56): Starting idle watcher [gs_grab_release] gs-grab-x11.c:390 (19:59:56): Releasing all grabs [gs_grab_release_mouse] gs-grab-x11.c:239 (19:59:56): Ungrabbing pointer [gs_grab_release_keyboard] gs-grab-x11.c:221 (19:59:56): Ungrabbing keyboard [xorg_lock_smasher_set_active] gs-grab-x11.c:124 (19:59:56): Enabling the x.org grab smasher [xorg_lock_smasher_set_active] gs-grab-x11.c:146 (19:59:56): XF86MiscSetGrabKeysState(on) returned MiscExtGrabStateSuccess
This is actually a hard problem to solve. The menus grab the pointer because they want to know when you click outside of the menu area to make the menu go away. The screen saver can't lock if there is an active pointer grab though.
I don't know why does the ss have to grab the pointer. But assuming that it does, couldn't gtk be changed to add a timeout to menus? Such behaviour change should be clearly documented in the API docs. Optimally, long term, when gtk actually starts depending on D-Bus it could listen for a LockingTheScreen signal sent from a screensaver service and get rid of any menu at that point. That still sounds hacky though, IMHO. The problem seems to be in the X server. If it allowed for a special client (like a window manager) to override the grabs, but then we could have some security problems. I wonder how this works on windows and mac os x?
this noob points out: This occurs not only for right-click context menus, but also for any main panel menu. This bug can be confirmed by the following steps: 1) Click Applications, 2) keep the mouse hovering over any menu item 3) no screensaver or power-manager activity occurs at the requested times (aka, monitor stays powered up overnight) looks like windows behaves the same way, third bullet from the bottom: http://www.australianimagery.com.au/support.php If this is a pain to work around, one option could be to have a timeout for open menus. A configurable time limit (for example 5 minutes) that a menu stays open without external clicks or application selection. I've suggested this to the #usability group at gnome.org, but they weren't sure if it could be a gnome-screensaver bug ... and I have no clue where (which product) to bugzilla about this idea
This also prevents special keys (like volume/mute and similar) to not work when menus are opened, then, I am not sure if this is a gnome-screensaver fault
This looks like a gtk issue. I had problems with epiphany that freeze if there were open menus you cannot kill the applications or change to another window or ... Your whole gnome desktop gets unuseable.
This is still valid, and also should be moved out of "UNCONFIRMED" status (can be easily reproducible in all distributions) Thanks
This most likely won't be fixed, see related bug 465423, bug 555570, bug 308516, etc.
This bug is being watched by an Ubuntu bug, with this recent comment pointing out that it's not just open menus that cause problems: https://bugs.launchpad.net/ubuntu/+source/gnome-screensaver/+bug/49579/comments/5 I guess Firefox chose to implement their "Page Bookmarked" popup (Ctrl-D) in a similar way to that used for menus. Perhaps Mozilla, and other developers of software that works with GTK+, should be encouraged to consider avoiding that kind of usage until this bug is fixed? Presumably they could easily use a totally separate window instead, like Firefox's downloads list (Ctrl-Y), or an 'internal window' like Firefox's "Alert me when I submit information that's not encrypted" popup. Please could some developers let us know whether that is a sensible idea? If so, as I Firefox user I would volunteer to make the suggestion to Mozilla. What other software has anything similar to Firefox's "Page Bookmarked" popup, anyone? Early in 2008, comment 3 said 'looks like Microsoft Windows behaves the same way'. This is no longer the case. I have just tested Windows XP SP3 and found that having the Start Menu open does not prevent the screensaver & lock from coming on. I suppose the main concerns for this bug are security (screen not locking) and environment (screen not switching off), but comment 7 implies that the same underlying problem is also the reason why the 'global keyboard shortcuts', such as alt-tab or PrintScreen don't always work. The bugs mentioned in that comment lead on to numerous others, at least as far back as bug 100903. Generally they are filed against gtk+ and assigned to "gtk-bugs". (Should this one be changed from gnome-screensaver to gtk+ perhaps?) Bug 555570, comment 3 implies that some "brightness control keys" may work even when a menu is open. I don't suppose there's any chance this hints at a solution to the whole problem? Bug 144907, comment 11 suggests a limited workaround for individual GTK+ programs, which could perhaps help with the usability ('global keyboard shortcuts') aspect of this problem. It wouldn't help with the security or environment aspects, but for those we already have the "configurable time limit" workaround suggested in comment 3 above, which sounds sensible (and feasible?).
*** Bug 643671 has been marked as a duplicate of this bug. ***
the bug also appears with rdesktop - read https://bugs.launchpad.net/bugs/731274
The screensaver also doesn’t activate when the gnome-shell Activities menu is open. (Note that the Activities menu opens automatically when the last window on the current workspace is closed.)
> The menus grab the pointer because they want to know > when you click outside of the menu area to make the menu go away. Is this still true with XInput 2.x? I think that you can now receive mouse events without grabbing the pointer. This wouldn't fix the underlying issue, but it could finally allow menus to work with screen locking. Let me check if this is true.
This also prevents screen locking. For everyday users screen locking almost replaced login, eg. by the large use of standby mode today, so this bug has massive security implications. If I close my notebook's lid and go away, I do not expect anyone to gain access just by opening it again. This is espaccially true as more and more devices are always on, like phones and pads, leading to the expectation that standby and thus screen lock gave reliable security. I can't understand why it keeps unadressed for such a long time. I agree that this may involve X or GTK issues, so cooperation may be needed, but someone must make a start!
*** Bug 660722 has been marked as a duplicate of this bug. ***
gnome-screensaver is obsolete, and this particular bug has been worked around in gnome-shell itself. See bug 689106 for details. A proper fix is not possible on X11, though Wayland will fix this.