i also started a reddit thread on /r/openbox to see if anyone else is having the same issue, it appears that at least one person is. (link: http://www.reddit.com/r/openbox/comments/unw58/openbox_menu_xscreensaver_not_allowing/)
i've copied and pasted the info from my submission below:
i'm running crunchbang statler, mostly a standard installation of #! with some additions to the menu.xml.
i got distracted after bringing up the menu and left my computer for a time, to return, long past when the screensaver should have kicked on, and the screen should have locked, to find that the screen had gone blank, but the screen had not locked.
i've since tried reducing the idle time, and confirmed the screensaver initiates and the screen locks without the menu up, but if the menu is up, usually the screensaver doesn't start, and if it does, then the screen does not lock.
i've also tried using screensavers besides the blank screen, with the same results.
the other person having the same issue is running mandriva with openbox (3.5.0).
this other person also mentioned that sometimes the screensaver + lock doesn't work at all for him, i also experienced this 1 or 2 times, seemingly following repeatedly forcing the screensaver to activate and the screen to lock. i was unable to reproduce this, however.
versions:
xscreensaver v5.11 (default)
openbox v 3.4.11.1 (default)
X v1.7.7 (default)
configs:
openbox - http://pastebin.com/GViaL1EJ
xscreensaver - http://pastebin.com/XmiBsfML
.Xresources - http://pastebin.com/TyV5Uxgp
this is my first bug report, so apologies if i'm including too much or too little. if i receive a link to this report, i intend to send it to the developer of xscreensaver as well, as the issue seems narrowed down and not limited to crunchbang linux.
short version: activate openbox menu and leave menu up, xscreensaver does not activate, screen does not lock.
i just received a response from jamie zawinski, developer of xcreensaver:
Short answer: your application is holding the keyboard grabbed for a very long time. That is antisocial. A screen locker cannot function properly while that is the case.
Longer answer, from the source:
/* 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.
In particular, without that keyboard grab, we will be
unable to ever read keypresses on the unlock dialog.
You can't unlock if you can't type your password.
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've tried with the following applications, just to be sure:
thunar file manager: does not load screensaver or lock screen
chromium: does not load screensaver or lock screen
terminator: does not load screensaver or lock screen
networkmanager applet: does not load screensaver or lock screen
truecrypt: does not load screensaver or lock screen
i also fired up my ubuntu 12.04 VM to see what happens there:
firefox: screen blanks quickly, does not lock, sometimes locks after mouse movement and click (unsure what app it uses for blanking/locking)
nautilus: screen blanks quickly, does not lock, sometimes locks after mouse movement and click
so is this looking more like a gtk issue?
Well, in X you have to grab the mouse and keyboard when you have a menu open, more or less, or it won't close when you click outside it. When you grab the mouse and keyboard, obviously the screensaver can't. Not really much we can do about it, sorry. (openbox doesn't use gtk+ but it's the same issue). If the guy has some great suggestion let us know though. It's not like we can just randomly close the menu after 30 seconds.
ok. the only suggestion from the dev of xscreensaver was to code whatever (gtk, whatever else) to steal back kb/mouse from an inactive menu, or, cancel the menu after a time.
completely unrelated and off-topic, it does appear that windows (7 at least) cancels the menu and loads screen saver/screen lock.
i understand the desire to leave control of as much of a system as possible with the user, but, wouldn't canceling the menu to lock the screen be the behavior of a "responsible" system, taking reasonable security precautions?
again, apologies if this isn't the place for this type of discussion. just tossing it out there.
The problem is that xscreensaver doesn't know how to tell the program it wants to grab, and the program has no idea that xscreensaver wants to lock. You would need to invent some new crazy protocol probably, and then it would still only work with stuff that implements it.
i just received a response from jamie zawinski, developer of xcreensaver: Short answer: your application is holding the keyboard grabbed for a very long time. That is antisocial. A screen locker cannot function properly while that is the case. Longer answer, from the source: /* 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. In particular, without that keyboard grab, we will be unable to ever read keypresses on the unlock dialog. You can't unlock if you can't type your password. 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.) */