Comment 1 for bug 995500

Apparently it's not a "regression".

$ uname -a
Linux alain-desktop 2.6.32-41-generic #88-Ubuntu SMP Thu Mar 29 13:10:32 UTC 2012 x86_64 GNU/Linux

$ gnome-screensaver-command -V
gnome-screensaver-command 2.30.0

Almost same happens on Lucid.

The manipulations under *Solution 1* give the same behavior: the screen is never locked, but goes to lock immediately after the menu (we speak of Gnome menus here) is close.

The manipulations under *Solution 2* give a slightly different result. When the sleep timer is done on the command line, the screen is NOT locked. So the gnome-screensaver-command -l seams to be ignored too. But as soon as the menu is closed, the screens locks (same as in 1).
The "bug" in this second manipulation happens when a gnome-panel or applet menu is open, or when a terminal menu is opened. It does not happen when another application has an opened menu, in which case said menu is closed prior to put the screen to lock.

What makes it worse in Unity, is that now any application that has a menu opened will trigger the behaviour... because application menus are now at Unity level instead of being at the application level.

WHAT SHOULD HAPPEN
-------------------------------

Same as with gnome 2.3, when another application is opened and as described with the command line: any menu opened should be closed, and the screen lock should be engaged.