GNOME Bugzilla – Bug 701495
curtain for no-password accounts
Last modified: 2013-08-07 08:37:26 UTC
When I installed F19 beta on one box, I was prompted for a password as the Live User after some time of inactivity, dismissing it by hitting Enter. If we do allow a user account not to be secured with a password, the behavior I would expect from screen blanking is the curtain simply lifting and revealing the session, rather than the authorization dialog. It might as well be a downstream bug, but I guess it's shell.
Created attachment 246308 [details] [review] ScreenShield: don't lock if the user has no password If the user has no configured password (like the default user in a live cd), the behavior should be as if the session was not locked at all.
Review of attachment 246308 [details] [review]: Is there really no other way to do this? Ugh. ::: js/ui/screenShield.js @@ +1302,3 @@ + let userManager = AccountsService.UserManager.get_default(); + let user = userManager.get_user(GLib.get_user_name()); There's no guarantee the accounts service is loaded at this point.
(In reply to comment #2) > Review of attachment 246308 [details] [review]: > > Is there really no other way to do this? Ugh. I also tried having UnlockDialog emit 'unlocked' on its own for password-less accounts, but the interactions with the lock screen are worse. This one basically makes it work like it was never locked in the first place, which is consistent in code and behavior. > ::: js/ui/screenShield.js > @@ +1302,3 @@ > > + let userManager = AccountsService.UserManager.get_default(); > + let user = userManager.get_user(GLib.get_user_name()); > > There's no guarantee the accounts service is loaded at this point. In theory, yes. In practice, the user menu loads the user object at startup (way before the animation), so by the time the user presses Super+L the user is already loaded.
Not all session modes use the user menu, and I have patches to remove the user menu as it's not in the new designs.
(In reply to comment #4) > Not all session modes use the user menu, and I have patches to remove the user > menu as it's not in the new designs. That's kind of a problem: what if the user loads while the user is about to press enter on the unlock dialog? Do we unlock anyway? How about instead precaching the current user at startup, and delaying the initialization like we do for the session mode loading? Having the guarantee that the current user is loaded would also clean up the avatar widgets.
Attachment 246308 [details] pushed as aefdf15 - ScreenShield: don't lock if the user has no password Reviewed by Jasper St. Pierre at Guadec.