Bug 312833

Summary: Screen lock dialog is always displayed
Product: [Unmaintained] kscreensaver Reporter: Baokai Lei <leibaokai>
Component: lockerAssignee: kscreensaver bugs tracking <kscreensaver-bugs-null>
Status: RESOLVED DUPLICATE    
Severity: normal CC: bugs, kaysimon
Priority: NOR    
Version: 4.9.98 RC3   
Target Milestone: ---   
Platform: Ubuntu   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:

Description Baokai Lei 2013-01-07 17:25:17 UTC
I'm running Kubuntu Quantal x64 and upgraded from Kde 4.9.5 to 4.10 RC2 using the Kubuntu beta repository.

Before the upgrade, I had the screen locker and password prompt turned off. After upgrading, I was surprised to find that, in System settings > Display > Screenlock, "Screen locker type" was set to "Simple locker" instead of "Screen saver".
I changed it to "Screen saver", clicked on "Apply" and closed System settings.

However, as soon as the screen saver starts, the screen lock dialog is displayed, which shouldn't be there at all, as the password prompt is turned off (as I already wrote, it was turned off before the upgrade as well, this was never changed). This happens every time the screen saver starts.
I've then tried out the testing option on the Screen lock page by clicking on the "Test" button and found that the screen saver runs normally there, without showing a screen lock dialog.

Reproducible: Always

Steps to Reproduce:
1. In System settings > Display > Screenlock, set "Screen locker type" to "Screen saver"
2. Make sure the password prompt option is turned off (unchecked)
Actual Results:  
As soon as the time set in the "start automatically after" option has elapsed, the screen saver starts and instantly shows the screen lock dialog.

Expected Results:  
When the screen saver starts, the screen lock dialog should not be shown (unless it has been enabled).
Comment 1 Baokai Lei 2013-01-07 20:31:13 UTC
Just two more things:

1. To prevent misunderstandings: When the screensaver starts (or better, *should* start), the screen lock dialog doesn't appear *on top* of the screensaver, but *instead* of the screensaver, on a black screen. If I move the mouse shortly after it appears, the desktop returns without me having to enter the password. If I wait for a while before moving the mouse, I have to enter the password to unlock the screen and return to the desktop. It seems there's a grace period, but I have no idea how long it is. I haven't set up anything like that in the first place.

2. What I just noticed is that, after returning to the desktop, there's a yellow question mark in the system tray. Clicking on it, it told me that /usr/bin/kslideshow.kss crashed. It didn't present me with a crashlog, so I can't post it here. I tried it some more, and the yellow crash icon appears every time afterwards - I just didn't notice it before.
Comment 2 Baokai Lei 2013-01-07 20:37:49 UTC
Edit: It's a yellow exclamation mark, not a question mark. (Why can't you edit your comments here?) More precisely even, it's a black exlamation mark in a yellow jagged balloon. I've never seen this appear when a Kde application crashed.
Comment 3 Baokai Lei 2013-01-21 15:41:16 UTC
Just updated to 4.10 RC3 (4.9.98) and rebooted, but the bug is still the same.
Comment 4 Baokai Lei 2013-01-23 14:42:12 UTC
Further information:

- If you don't have the option checked that a password is required to quit the screen saver, then you will need to enter a password right away when the screen lock dialog (with black background) appears.

- If you *do* have the password required option checked however, it's different:
-- When the timeout you've set there isn't up yet after the screen lock dialog appears, then the screen lock dialog will simply disappear again when you move the mouse, without having to enter anything.
-- When the timeout from the password option is up, then moving the mouse won't do anything, and you'll have to enter the password normally to return to the desktop. However, when you move the mouse and do nothing otherwise, then the screen saver will run normally on top of the screen lock dialog after a very short pause (seems like one minute, much shorter than what is set for the screensaver timeout).
When you *don't* move the mouse after the screen lock dialog comes up, then the screen saver will *never* run, and you'll always only have the screen lock dialog on a black background, regardless for how long (generally until the power saving options become active and turn off the screen).
Comment 5 Baokai Lei 2013-01-24 00:28:47 UTC
After a full update and reboot, I did another test now. Results were somewhat different now:

I went to the screen lock settings dialog and unchecked the "password required after..." checkbox, to see if the error when it's unchecked is still the same (see above). What I found was:
Once the timeout set for the screensaver is up, the screen lock dialog (on a black background) still appears, *but* the screen saver starts simultaneously with it now, and is drawn on top of it, hiding it eventually. The screensaver doesn't crash anymore! When you move the mouse after that, the desktop instantly appears, i.e. no password input required.
Overall, a good improvement!

Retried it, and it's reproducable. Rebooted (just in case), and it's still reproducible every time.

What is left to do now is:

- Don't show the screen lock dialog when the "password required" checkbox is unchecked.
- Hide the mouse cursor! When the timeout was up and the screen lock dialog with the screen saver running on top of it appeared, the mouse cursor stayed visible all the time.
Comment 6 Baokai Lei 2013-01-24 00:31:32 UTC
Changed Importance from "crash" to "normal", as the screensaver doesn't crash anymore.
Comment 7 Baokai Lei 2013-01-24 22:34:40 UTC
Addendum:
If the screen saver has been running for a while and you move the mouse, the screen lock dialog reappears, and you have to enter your password - even if the "password required" option is unchecked.
So, regardless if the "password required" option is checked or not, after the screensaver has started, there is still a timeout (can't say how long) after which a password will be required.
Comment 8 Baokai Lei 2013-02-07 16:19:15 UTC
Updated to 4.10 final and rebooted.
There's little change:

- Once the timeout for the screensaver is up, the screen lock dialog still appears, but now, it has the nice 4.10 default wallpaper as background instead of a black background, which looks much better. However, the scaling of the image to my resolution (1920x1200) doesn't work properly, as the image appears quite jaggy.

- The first time after a reboot or login, the screensaver crashes when the timeout is up, and you only have the screen lock dialog. On all consecutive times, the screensaver runs normally on top of the screen lock dialog.

- Mouse cursor stays visible all the time. It should be hidden when the screensaver is running.

- It's still completely ignored if you have the "password required" checkbox checked or not, and always behaves as if it's checked, so you'll *always* have to enter your password if the time given here has elapsed.

- The maximum amount possible for the "password required" timeout is 300 seconds (5 minutes), which is *way* too short. First off, it makes no sense to have this in seconds, rather than minutes. Second, as this option is broken and you can't turn it off (same behaviour with it checked and unchecked), you'll *always* have to enter your password after a maximum of 5 minutes after the screensaver started, which is very annoying. If it allowed bigger time spans (like 1 or 2 hours), you could at least keep the required entering of your password to a bearable minimum.
Comment 9 Graeme Hewson 2013-02-07 18:11:00 UTC
I confirm this in 4.10 final.

Whether ~/.kde/share/config/kscreensaverrc contains Lock=true, Lock=false or no Lock line at all (which was the case after the upgrade from 4.9.5), the screen is locked after the screen save starts, plus the grace period (LockGrace in the rc file specifies the period in milliseconds).
Comment 10 Graeme Hewson 2013-02-07 18:22:04 UTC
Duplicate of bug 310871
Comment 11 Christoph Feck 2013-02-19 00:36:44 UTC

*** This bug has been marked as a duplicate of bug 310871 ***