GNOME Bugzilla – Bug 668551
Desktop often shown before lock screen when resuming from suspend or inactivity
Last modified: 2013-01-19 22:31:04 UTC
I'm on Fedora Rawhide, with mostly GNOME 3.3 packages now and gnome-screensaver-3.2.0-2.fc17.x86_64 . I have dual heads - both Dell 20" 1920x1080 screens in portrait orientation. Often, when I wake up from suspend or just come back from a timeout-induced screen lock, the monitors will show my desktop for a few seconds before fading out to the lock screen. Sometimes I can even interact with the desktop during this time, so this has security implications as well as simply being very bad polish. I think this was mostly 'fixed' for a bit during F16 release time frame, but has since gotten worse again.
how do you suspend it in the first place?
if it's upower initiating the sleep then it gets screensaver 1 second to lock before suspending. That's racy, of course. Especially since the lock fade is 1 second long. It would be good if settings daemon could just-in-time inhibit suspend rather than racing against the clock. That has security ramifications on multi-user systems too though. dropping the fade out on explicit screen locks is the easiest way to mitigate this problem, but it's not fool proof.
okay so the sleep is actually initiated from the g-s-d power plugin on lid close. that same plugin ties to the sleep-notify signal which is inherently racy. I guess instead it should lock explicitly before calling Suspend. This has a problem that if Suspend fails for security policy reasons, I guess, the screen will still lock, though.
i'll push a commit to shorten the screensaver fade out but we should fix this in power plugin. (i'm taking a leap and assuming the answer to comment 1 is "close the lid")
My system's actually a desktop, so I suspend it from the GNOME user menu.
Comedically, the system fails to suspend with the new 3.3 kernel, so it's going to be harder to test this. Sigh. I'll try and dig out a 3.2 kernel if you need me to check anything.
interesting, so screensaver must be returning from Lock() before it locks.
Indeed, if (dbus_message_is_method_call (message, GS_SERVICE, "Lock")) { g_signal_emit (listener, signals [LOCK], 0); return send_success_reply (connection, message); } we send the reply as soon as we fire off the machinery. we don't wait for it to finish.
since there's two problems i've cloned this bug as bug 668877 to cover the screensaver half. I'll leave this bug number for g-s-d
I haven't seen this bug in a long time. Can we close the g-s-d bit now too?
I was still seeing bad behaviour - or maybe it came back - on this system with F17, before I updated to F18. I'd get solid blue background. I think that may come down to interaction with revelation (the password manager app I run), though. revelation seems possibly to do something a bit odd with its unlock dialog. I can't say what the status is on F18 right now because I've had the lock screen disabled for other reasons, though I may turn it back on soon.
Adam, any news here?
Upgraded this laptop to F18 the other day and haven't seen any trouble since, so sure, we can probably close this out. Still have lock screen disabled on the desktop. If I ever turn it back on I'll check this out.