Hello, when you open a menu of e.g. KDE konqueror, GNOME nautilus or firefox then the screensaver wouldn't start in my tests. First I thought its a KDE bug http://bugs.kde.org/show_bug.cgi?id=176637 but the same behaviour can be reproduced with gnome. Or if you open a pull down menu on a website with firefox/iceweasel the screensaver will not start. It is reproducible with installed gnome-screensaver and not installed xscreensaver so I think its not xscreensaver specific. If xscreensaver is used you can see the following: xscreensaver reported the following lines when the timeout expired: xscreensaver: 20:16:02: couldn't grab keyboard! (AlreadyGrabbed) xscreensaver: 20:16:06: couldn't grab keyboard! (AlreadyGrabbed) xscreensaver: 20:16:10: couldn't grab pointer! (AlreadyGrabbed) xscreensaver: 20:16:10: unable to grab keyboard or mouse! Blanking aborted. The source code comment says: xscreensaver-5.07/driver/xscreensaver.c ... if (! blank_screen (si)) { /* We were unable to grab either the keyboard or mouse. This means we did not (and must not) blank the screen. If we were to blank the screen while some other program is holding both the mouse and keyboard grabbed, then we would never be able to un-blank it! We would never see any events, and the display would be wedged. So, just go around the loop again and wait for the next bout of idleness. (If the user remains idle, we will next try to blank the screen again in no more than 60 seconds.) */ I don't know if opening a menu in an application grabs mouse and keyboard. this is answered by Michel in http://bugs.debian.org/514036 --8<-- Michel Dänzer <daenzer at debian.org> It does; it's the only way the menu can receive input events while the pointer is outside of it. AFAIK this is a pretty deep X11 design issue, so I'm afraid this can't be fixed easily. Feel free to bring it up upstream though. --8<-- Sorry but I don't know which is the correct component for this topic.
I'm not clear that there is definitely a need for a keyboard grab to implement menus with access keys, even though that is what toolkits often do. It may be convenient from the perspective that events are directed to the menu window. But in most cases the main application window would have focus and so the application can receive keyboard events there. If for some reason a client does not normally receive focus in the main window, I wonder whether it should negotiate keyboard focus (perhaps under the Globally Active Input model) rather than stealing a keyboard grab, which cannot be overridden until the client releases.
Is this bug still relevant? I just tested this, and xscreensaver successfully locks even with a menu active. x11-base/xorg-x11-7.4-r1 running x11-wm/openbox-3.5.0-r1 (Gentoo). Can we close this bug?
*** This bug has been marked as a duplicate of bug 4286 ***
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.