GNOME Bugzilla – Bug 670820
user menu "suspend" option doesn't lock the session
Last modified: 2012-03-23 23:48:14 UTC
Preconditions: - screensaver is enabled (I set 10 min.) - session locking enabled and set to anything besides "after the screen goes blank" (I set 30 min.) - NVidia binary blob graphics device driver (don't know if this is related) Experienced behaviour: When I use the suspend functionality in the g-s user menu, the shell is unlocked after resuming and I experience the same symptoms as https://bbs.archlinux.org/viewtopic.php?pid=1007305#p1007305. Expected behaviour: After resuming the shell is locked and requires the user's password to unlock. If I do however make the changes in the patch, everything works as I expect it. I don't know though, if this behaves correctly™ in other use cases. See also: https://bugs.launchpad.net/ubuntu/+source/gnome-session/+bug/847814
Created attachment 208434 [details] [review] Lock session instead of activating the screensaver
Review of attachment 208434 [details] [review]: Locking the screen is what we want to do here not activating the screensaver so the patch makes sense even though it isn't clear to me why the screen doesn't get locked when activating the screensaver. Can you attach a proper patch? (using git format-patch) ?
(In reply to comment #2) > Review of attachment 208434 [details] [review]: > > Locking the screen is what we want to do here not activating the screensaver so > the patch makes sense even though it isn't clear to me why the screen doesn't > get locked when activating the screensaver. Maybe because in my configuration screen locking doesn't depend on the screen saver or vice-versa.
Created attachment 208449 [details] [review] Lock session instead of activating the screensaver
Comment on attachment 208449 [details] [review] Lock session instead of activating the screensaver generated with git format-patch
Thanks, pushed.
Created attachment 208595 [details] [review] Patch to fix the commited patch While the original patch was ok, the commited one contains a typo which makes suspending impossible. I'm attaching a fix.
Review of attachment 208595 [details] [review]: Looks right - please re-attach with a proper commit message.
Created attachment 208919 [details] [review] userMenu: Fix LockRemote call Commit 37cbfe29 replace the SetActiveRemote with a LockRemote call but didn't change the paramters, so remove the incorrect boolean parameter. --- Same patch with a fixed commit message.
Review of attachment 208919 [details] [review]: Go ahead.
Attachment 208919 [details] pushed as 1f9c83d - userMenu: Fix LockRemote call
In the preferences, I have unchecked "Require my password when waking from suspend", and it asks me for my password when suspending from the menu (but not on closing the lid). It's on Ubuntu Precise, so it might be distro-specific though.
Ok, so instead of locking the session unconditionally we need to check, if automatic session locking is enabled and act accordingly. Should Julien or I open a new bug for this?