Bug 19946

Summary:	screensaver doesn't start when a menu is open
Product:	xorg	Reporter:	Noèl Köthe <noel>
Component:	Server/Input/Core	Assignee:	Xorg Project Team <xorg-team>
Status:	RESOLVED DUPLICATE	QA Contact:	Xorg Project Team <xorg-team>
Severity:	enhancement
Priority:	medium	CC:	brice.goglin, bugs.freedesktop
Version:	7.4 (2008.09)
Hardware:	All
OS:	Linux (All)
URL:	http://bugs.debian.org/514036
Whiteboard:
i915 platform:		i915 features:

Description Noèl Köthe 2009-02-04 01:16:28 UTC

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.

Comment 1 Karl Tomlinson 2011-03-15 15:58:42 UTC

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.

Comment 2 Homer 2012-04-12 00:15:01 UTC

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?

Comment 3 Adam Jackson 2018-06-12 16:16:01 UTC


*** 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.