Opened the bug so upstream can access it.

Dirk, 

Could you describe your hardware setup a little more ?  Is this a desktop system with just a single monitor and the other systems have the same setup ? So that we are not comparing a desktop system with a single monitor to a laptop with an external display. 

What I understand from the original message is that you are locking the screen and then when you switch off and on the display, the lock screen is gone and the desktop is visible ?

(In reply to Raymond Wooninck from comment #2)
> Dirk, 
> 
> Could you describe your hardware setup a little more ?  Is this a desktop
> system with just a single monitor and the other systems have the same setup
> ? So that we are not comparing a desktop system with a single monitor to a
> laptop with an external display. 
both mentioned systems are desktop systems, both have a single monitor.

The affected system is a less than 2 years old HP Elitedesk 800 G1 TWR, I would consider it quite a "standard" system.

On two laptops (one of them with AMD video chip and the other one with Intel chip) I did not observe this, but I also can't really switch off the monitor :-)

For me the suspicious distinction between the two is the cable (DP vs. DVI) between PC and monitor.

> What I understand from the original message is that you are locking the
> screen and then when you switch off and on the display, the lock screen is
> gone and the desktop is visible ?
exactly.

steps to reproduce on the affected system:
when some applications are in use (konsole, Firefox, ...)  - I did not try with "blank" desktop

lock the screen (CTRL+Alt+L) and make sure it is locked
switch of the monitor
wait "some" (~5) seconds - I did not try very short power off time
switch on the monitor
the desktop is not locked, the arrangement of windows on the virtual desktops (or nowadays called activities?) are unchanged
there is no sign of some crash of the lock screen (no drkonqui), it is just gone as if the screen had not been locked at all.

bugbot adjusting priority

Upstream maintainer speaking.

From the xsession output it looks like the lockscreen successfully exited. It prints "Grab Released" which is in method

void KSldApp::doUnlock()

which is called from three places:
1) If the kscreenlocker_greet failed to start. This would print an error message "Greeter Process not available" which is not in the log
2) If logind send the Unlock dbus signal
3) If kscreenlocker_greet exits with exit code 0. This can happen after grace time (given description not the case), after logind Unlock or - the normal case - after the password was accepted successfully.

Given the information in the bug report I can exclude case 1), consider case 2) unlikely and am sure that the condition grace time of number 3) is not the case.

So I assume we found a new way to exit kscreenlocker_greet successfully. My gut feeling tells me it's related to Qt's utterly broken multi screen handling including crashes when screens are turned off (see "requesting unexisting screen 0" in log). But to figure that out we would need the debug output of kscreenlocker_greet which is only available since http://commits.kde.org/kscreenlocker/a68dda3dd2a8a60e7f03beb5f0e652ef10fedbaa

So we need to manually try that.

@Dirk: can you please try to run:
1) run "kscreenlocker_greet --testing" from a konsole
2) turn off the display

Afterwards please tell us whether the application exited or not. If it did, please add the debug output from the konsole.

Please note that kscreenlocker_greet is installed into the libexec directory and is not in $PATH. Unfortunately I do not know where openSUSE installs that file.

That would be at /usr/lib64/libexec/kscreenlocker_greet

Running /usr/lib64/libexec/kscreenlocker_greet --testing works right away. But just in case that commit Martin mentioned would be helpful, I backported it to plasma5-workspace 5.4.3. This patched version is available at https://build.opensuse.org/package/binaries/home:alarrosa:branches:bnc964548/plasma5-workspace?repository=standard . Dirk, maybe it would be nice if you could install it.

Thanks for the instructions, I will try to provide the logs tomorrow evening.

> @Dirk: can you please try to run:
> 1) run "kscreenlocker_greet --testing" from a konsole
> 2) turn off the display
> 
> Afterwards please tell us whether the application exited or not. If it did,
> please add the debug output from the konsole.

I followed the procedure.
after switching the monitor on again the kscreenlocker_greet was gone.

I attach the output of "kscreenlocker_greet --testing" and appended to it the content of .xsession-errors-:0

Also some check for the files which can not be opened according to the output of kscreenlocker_greet.

Created attachment 664478 [details]
output of kscreenlocker_greet --testing; .xsession-errors-:0

requested output of /usr/lib64/libexec/kscreenlocker_greet --testing

(In reply to Dirk Weber from comment #9)
> Created attachment 664478 [details]
> output of kscreenlocker_greet --testing; .xsession-errors-:0
> 
> requested output of /usr/lib64/libexec/kscreenlocker_greet --testing

additional observation: the output of kscreenlocker_greet --testing looks identical (except for the timestamp) on the affected system and on the not affected system.

The big difference is that on the not affected system the kscreenlocker_greet is still running after switching the monitor off and on.

Thank you. Interestingly I don't see anything odd in the output, but this gave me an idea. I'll try to verify with a test case.

Unfortunately I was not able to create a test case for the situation. X11 makes it difficult to test with dynamic XRandR screens (neither Xephyr nor Xvfb support XRandr, XWayland is broken), thus I decided to create the test case with Wayland.

Works fine, just that Qt makes kscreenlocker_greet crash in the situation and crashes are handled correctly, the screen stays locked.

The good part of that is that we can be quite certain that not many systems are affected as Qt used to crash on X11 as well.

Created attachment 664559 [details]
Possible patch

This is a possible patch against kscreenlocker to not exit when the last window closed. It compiles but I haven't tested it yet as I cannot reproduce the situation.

kscreenlocker used to be in plasma-workspace back in 5.4 release, but should apply nevertheless.

It would be awesome if this patch could be tested. If it works I'm going to contact KDE's security team about the issue.

I can reproduce the problem on a Gentoo box with Qt 5.6 from git (couple months old) and KF5/plasma from git (day or two old). My Plasma session was started on LVDS1, xrandr-ed to DP2, screen locked, and if I power-cycle my DP2 screen, the locker is gone.

After applying the patch, the locker bypass is gone, but there's a regression, another screen locker pops up immediately (but with a nice animation) after I unlock the older one. This only happens when there was a power cycle of the screen, and I can get back to my session after I've unlocked the second screenlocker.

I added the patch from #c13 to the packages at:

https://build.opensuse.org/package/show/home:alarrosa:branches:bnc964548/plasma5-workspace

Btw, Dirk, if you tried to download them before, please try again, I forgot to enable the "publish" flag, but it should be working now.

If you don't want to add a new repository ( http://download.opensuse.org/repositories/home:/alarrosa:/branches:/bnc964548/standard/ ) then you can install individual packages. In that case, I think just installing plasma5-workspace-5.4.3-10.1.x86_64.rpm and plasma5-workspace-libs-5.4.3-10.1.x86_64.rpm from https://build.opensuse.org/package/binaries/home:alarrosa:branches:bnc964548/plasma5-workspace?repository=standard should be enough.

(In reply to Antonio Larrosa from comment #15)
> I added the patch from #c13 to the packages at:
> 
> https://build.opensuse.org/package/show/home:alarrosa:branches:bnc964548/
> plasma5-workspace
> 
> Btw, Dirk, if you tried to download them before, please try again, I forgot
> to enable the "publish" flag, but it should be working now.
today I was able to download them.
 
> ... just installing plasma5-workspace-5.4.3-10.1.x86_64.rpm and
> plasma5-workspace-libs-5.4.3-10.1.x86_64.rpm from
> https://build.opensuse.org/package/binaries/home:alarrosa:branches:bnc964548/
> plasma5-workspace?repository=standard should be enough.
I installed 
plasma5-workspace-libs-5.4.3-10.1.x86_64.rpm
plasma5-workspace-5.4.3-10.1.x86_64.rpm

With these I have the same behavior as described in #c14:
after switching the monitor off and back on the screen is locked.
After unlocking it it gets immediately locked again. 
After unlocking the second time the desktop is accessible.

This happens when the screen is locked by CTRL-Alt-L and as well as when started by
/usr/lib64/libexec/kscreenlocker_greet --testing

Created attachment 664611 [details]
output of /usr/lib64/libexec/kscreenlocker_greet --testing with the patched version #c16

output when using the packages with the patch from #c15
description of the result see #c16

Would it make sense, when there are no more screens, to exit kscreenlocker_greet with exit value == 1, to notify that a valid log-in didn't take place?

(In reply to Lorenzo Desole from comment #18)
> Would it make sense, when there are no more screens, to exit
> kscreenlocker_greet with exit value == 1, to notify that a valid log-in
> didn't take place?

No, that's kind of a useless information in that case. Assuming we would do so, it would result in KSlD restarting the greeter which would exit again with 1, because there are no screens. Resulting in either a restart loop or in the emergency window being shown.

(In reply to Martin Gräßlin from comment #19)
> (In reply to Lorenzo Desole from comment #18)
> > Would it make sense, when there are no more screens, to exit
> > kscreenlocker_greet with exit value == 1, to notify that a valid log-in
> > didn't take place?
> 
> No, that's kind of a useless information in that case. Assuming we would do
> so, it would result in KSlD restarting the greeter which would exit again
> with 1, because there are no screens. Resulting in either a restart loop or
> in the emergency window being shown.

Not if the pre-condition is "there was a screen, now it's been removed, there are no screens left". I am currently testing a patch, so far so good. If it behaves, later I can submit it here for you to check.

(In reply to Lorenzo Desole from comment #20)
> (In reply to Martin Gräßlin from comment #19)
> > (In reply to Lorenzo Desole from comment #18)
> > > Would it make sense, when there are no more screens, to exit
> > > kscreenlocker_greet with exit value == 1, to notify that a valid log-in
> > > didn't take place?
> > 
> > No, that's kind of a useless information in that case. Assuming we would do
> > so, it would result in KSlD restarting the greeter which would exit again
> > with 1, because there are no screens. Resulting in either a restart loop or
> > in the emergency window being shown.
> 
> Not if the pre-condition is "there was a screen, now it's been removed,
> there are no screens left".

sorry, but that's totally useless information for KSld. It doesn't need to know about it and it's also a not needed information in future. With Qt 5.6 we will get proper dummy QScreens in case there is no screen and on Wayland, well KWin is not so stupid as to remove the last screen ;-)

Anyway concerning the issue: upstream security team is involved now.

(In reply to Martin Gräßlin from comment #21)
> (In reply to Lorenzo Desole from comment #20)
> > (In reply to Martin Gräßlin from comment #19)
> > > (In reply to Lorenzo Desole from comment #18)
> > > > Would it make sense, when there are no more screens, to exit
> > > > kscreenlocker_greet with exit value == 1, to notify that a valid log-in
> > > > didn't take place?
> > > 
> > > No, that's kind of a useless information in that case. Assuming we would do
> > > so, it would result in KSlD restarting the greeter which would exit again
> > > with 1, because there are no screens. Resulting in either a restart loop or
> > > in the emergency window being shown.
> > 
> > Not if the pre-condition is "there was a screen, now it's been removed,
> > there are no screens left".
> 
> sorry, but that's totally useless information for KSld. It doesn't need to
> know about it and it's also a not needed information in future. With Qt 5.6
> we will get proper dummy QScreens in case there is no screen and on Wayland,
> well KWin is not so stupid as to remove the last screen ;-)
> 
> Anyway concerning the issue: upstream security team is involved now.


Not even as a temporary fix? Because simply adding setQuitOnLastWindowClosed(false) leaves the screen locked but causes kscreenlocker_greet to crash. Which forces KSlD to take action and to respawn it. A clean exit would also force KSlD to respawn kscreenlocker_greet, but at least that happens at the proper time (i.e. when the last screen has been removed) hence you don't have to enter the password twice.

At least this is what happens in my test environment.

(In reply to Lorenzo Desole from comment #22)
> Not even as a temporary fix? Because simply adding
> setQuitOnLastWindowClosed(false) leaves the screen locked but causes
> kscreenlocker_greet to crash.

No way, we don't work around crashes, we fix them!

This is an autogenerated message for OBS integration:
This bug (964548) was mentioned in
https://build.opensuse.org/request/show/358584 Factory / kscreenlocker

CVE-2016-2312

(In reply to Martin Gräßlin from comment #23)
> (In reply to Lorenzo Desole from comment #22)
> > Not even as a temporary fix? Because simply adding
> > setQuitOnLastWindowClosed(false) leaves the screen locked but causes
> > kscreenlocker_greet to crash.
> 
> No way, we don't work around crashes, we fix them!

OpenSuse has updated kscreenlocker with the proposed patch. As a result kscreenlocker doesn't exit when the monitor is switched off, but switching the monitor off still breaks something, because entering the password doesn't unlock it.

Everything is fine if I don't switch the monitor off.

$ /usr/lib64/libexec/kscreenlocker_greet --testing
Locked at 1455376791
file:///usr/share/plasma/look-and-feel/org.openSUSE.desktop/contents/components/InfoPane.qml:52:22: Unable to assign [undefined] to int
file:///usr/share/plasma/look-and-feel/org.openSUSE.desktop/contents/components/UserPasswordPrompt.qml:25: ReferenceError: userModel is not defined
file:///usr/share/plasma/look-and-feel/org.openSUSE.desktop/contents/components/UserDelegate.qml:82:9: QML Image: Cannot open: file:///usr/share/plasma/look-and-feel/org.openSUSE.desktop/contents/components/user-identity
file:///usr/share/plasma/look-and-feel/org.openSUSE.desktop/contents/components/UserDelegate.qml:82:9: QML Image: Cannot open: file:///usr/share/plasma/look-and-feel/org.openSUSE.desktop/contents/components/system-log-out
file:///usr/share/plasma/look-and-feel/org.openSUSE.desktop/contents/components/UserDelegate.qml:82:9: QML Image: Cannot open: file:///usr/share/plasma/look-and-feel/org.openSUSE.desktop/contents/components/system-switch-user
org.kde.keyboardLayout: Layouts list changed:  ("it")
QXcbConnection: XCB error: 3 (BadWindow), sequence: 766, resource id: 0, major code: 21 (ListProperties), minor code: 0
file:///usr/share/plasma/look-and-feel/org.openSUSE.desktop/contents/components/InfoPane.qml:52:22: Unable to assign [undefined] to int
file:///usr/share/plasma/look-and-feel/org.openSUSE.desktop/contents/components/UserPasswordPrompt.qml:25: ReferenceError: userModel is not defined
file:///usr/share/plasma/look-and-feel/org.openSUSE.desktop/contents/components/UserDelegate.qml:82:9: QML Image: Cannot open: file:///usr/share/plasma/look-and-feel/org.openSUSE.desktop/contents/components/user-identity
file:///usr/share/plasma/look-and-feel/org.openSUSE.desktop/contents/components/UserDelegate.qml:82:9: QML Image: Cannot open: file:///usr/share/plasma/look-and-feel/org.openSUSE.desktop/contents/components/system-log-out
file:///usr/share/plasma/look-and-feel/org.openSUSE.desktop/contents/components/UserDelegate.qml:82:9: QML Image: Cannot open: file:///usr/share/plasma/look-and-feel/org.openSUSE.desktop/contents/components/system-switch-user
org.kde.keyboardLayout: Layouts list changed:  ("it")
file:///usr/share/plasma/look-and-feel/org.openSUSE.desktop/contents/lockscreen/MainBlock.qml:85: TypeError: Property 'tryUnlock' of object function() { [code] } is not a function

The last line is printed out each time the password is entered.

I don't know if this can be of some use nor do I know if it is a peculiarity of my setup.

I assumed that switching the monitor off is what causes kscreenlocker () to exit. That is incorrect. When the monitor is switched off, the screen  is not removed.  It is also worth noting that kscreenlocker (still without patch) works perfectly fine if it is executed when the monitor is off. It's when I switch it back on that the screen is removed and, after a split second, a new one is added. This causes all sorts of troubles to kscreenlocker.

I have modified UnlockApp::desktopResized() to printout the number of screen available and launched kscreenlocker in a loop:

$ while : ; do echo -e "\n\n\n*** starting at $(date)***"; echo "Monitor is $(cat /sys/class/drm/card0-DP-2/status)" ; greeter/kscreenlocker_greet --testing ; done

As soon as the login screen was shown, I switched off the monitor and waited for about a minute. This is the output I got:

*** starting at sab 13 feb 2016, 22.58.35, CET***
Monitor is connected
UnlockApp::desktopResized() - Screen count: 1
Locked at 1455400716
file:///usr/share/plasma/look-and-feel/org.openSUSE.desktop/contents/components/InfoPane.qml:52:22: Unable to assign [undefined] to int
file:///usr/share/plasma/look-and-feel/org.openSUSE.desktop/contents/components/UserPasswordPrompt.qml:25: ReferenceError: userModel is not defined
file:///usr/share/plasma/look-and-feel/org.openSUSE.desktop/contents/components/UserDelegate.qml:82:9: QML Image: Cannot open: file:///usr/share/plasma/look-and-feel/org.openSUSE.desktop/contents/components/user-identity
file:///usr/share/plasma/look-and-feel/org.openSUSE.desktop/contents/components/UserDelegate.qml:82:9: QML Image: Cannot open: file:///usr/share/plasma/look-and-feel/org.openSUSE.desktop/contents/components/system-log-out
file:///usr/share/plasma/look-and-feel/org.openSUSE.desktop/contents/components/UserDelegate.qml:82:9: QML Image: Cannot open: file:///usr/share/plasma/look-and-feel/org.openSUSE.desktop/contents/components/system-switch-user
org.kde.keyboardLayout: Layouts list changed:  ("it")
UnlockApp::desktopResized() - Screen count: 0



*** starting at sab 13 feb 2016, 22.59.32, CET***
Monitor is disconnected
UnlockApp::desktopResized() - Screen count: 1
Locked at 1455400772
QXcbConnection: XCB error: 148 (Unknown), sequence: 170, resource id: 0, major code: 140 (Unknown), minor code: 20
UnlockApp::desktopResized() - Screen count: 2
file:///usr/share/plasma/look-and-feel/org.openSUSE.desktop/contents/components/InfoPane.qml:52:22: Unable to assign [undefined] to int
file:///usr/share/plasma/look-and-feel/org.openSUSE.desktop/contents/components/UserPasswordPrompt.qml:25: ReferenceError: userModel is not defined
file:///usr/share/plasma/look-and-feel/org.openSUSE.desktop/contents/components/UserDelegate.qml:82:9: QML Image: Cannot open: file:///usr/share/plasma/look-and-feel/org.openSUSE.desktop/contents/components/user-identity
file:///usr/share/plasma/look-and-feel/org.openSUSE.desktop/contents/components/UserDelegate.qml:82:9: QML Image: Cannot open: file:///usr/share/plasma/look-and-feel/org.openSUSE.desktop/contents/components/system-log-out
file:///usr/share/plasma/look-and-feel/org.openSUSE.desktop/contents/components/UserDelegate.qml:82:9: QML Image: Cannot open: file:///usr/share/plasma/look-and-feel/org.openSUSE.desktop/contents/components/system-switch-user
org.kde.keyboardLayout: Layouts list changed:  ("it")
file:///usr/share/plasma/look-and-feel/org.openSUSE.desktop/contents/components/InfoPane.qml:52:22: Unable to assign [undefined] to int
file:///usr/share/plasma/look-and-feel/org.openSUSE.desktop/contents/components/UserPasswordPrompt.qml:25: ReferenceError: userModel is not defined
file:///usr/share/plasma/look-and-feel/org.openSUSE.desktop/contents/components/UserDelegate.qml:82:9: QML Image: Cannot open: file:///usr/share/plasma/look-and-feel/org.openSUSE.desktop/contents/components/user-identity
file:///usr/share/plasma/look-and-feel/org.openSUSE.desktop/contents/components/UserDelegate.qml:82:9: QML Image: Cannot open: file:///usr/share/plasma/look-and-feel/org.openSUSE.desktop/contents/components/system-log-out
file:///usr/share/plasma/look-and-feel/org.openSUSE.desktop/contents/components/UserDelegate.qml:82:9: QML Image: Cannot open: file:///usr/share/plasma/look-and-feel/org.openSUSE.desktop/contents/components/system-switch-user
org.kde.keyboardLayout: Layouts list changed:  ("it")

My deductions are:

1) kscreenlocker exited as soon I switched the monitor back on, not when I had previously switched it off.
2) the while/do loop immediately launched a new instance of kscreenlocker, but the monitor was still being reported off by Xrandr; UnlockApp::desktopResized() reports one screen though
3) there's a strange QXcbConnection: XCB error
4) A new (the real one) screen is added and UnlockApp::desktopResized() reports TWO screens, the fake/virtual/whatever one is not removed).
5) At that point kscreenlocker showed *two* password windows

If I add a "sleep 1" into the middle of the loop, the "QXcbConnection: XCB error doesn't happen", only one screen is reported by UnlockApp::desktopResized() and only one password window is shown.

Created attachment 665550 [details]
When the last windows gets closed, reset a few things and objects in kscreenlocker

app.setQuitOnLastWindowClosed(false) solves the security issue, but causes a regression: power cycling the monitor breaks kscreenlocker which, after that, refuses to accept the correct password.

The proposed patch resets a few internal things in kscreenlocker when a lastWindowClosed event is received.

It fixes the regression for me.

QT is not my cup of tea, I basically know nothing about the KDE internals, so I could have missed something or broken other stuff. But, still, it works for me.

The only real new code is the deletion of the Authenticator and the recreation of it. Everything else should already be done.

So the question is: why does the Authenticator needs to be recreated?

Personally I'm not really motivated in investigating it as with Qt 5.6 this should auto-resolve itself.

Otherwise I recommend to create a new bug report for the new issue (this one is about the vulnerability) and also to move it upstream (bugs.kde.org).

releasing for 42.1

(In reply to Andreas Stieger from comment #30)
> releasing for 42.1

I urge you to reconsider that.

Depending on the lockscreen theme in use, in case of monitor (un)plugging, you get:

1) a crash after entering the password; this will cause kscreenlocker to be respawned. It's a minor annoyance because you can re-enter the password and everything is fine

or

2) kscreenlocker can't be unlocked at all, i.e. you are locked out of your PC. This is a severe regression.

I get #1 with the internal fallback lockscreen.

I get #2 with the opensuse lockscreen.

Apparently this can't be fixed and upstream doesn't like the proposed workarounds.

openSUSE-RU-2016:0522-1: An update that solves one vulnerability and has one errata is now available.

Category: recommended (moderate)
Bug References: 954623,964548
CVE References: CVE-2016-2312
Sources used:
openSUSE Leap 42.1 (src):    bluedevil5-5.5.4-6.1, breeze-5.5.4-7.1, breeze4-style-5.5.4-7.1, kcm_sddm-5.5.4-7.1, kde-cli-tools5-5.5.4-6.1, kde-gtk-config5-5.5.4-6.1, kde-user-manager-5.5.4-6.1, kgamma5-5.5.4-6.1, khelpcenter5-5.5.4-6.2, khotkeys5-5.5.4-6.2, kinfocenter5-5.5.4-6.1, kmenuedit5-5.5.3-6.5, kscreen5-5.5.4-7.1, kscreenlocker-5.5.4-4.1, ksshaskpass5-5.5.4-6.1, ksysguard5-5.5.4-8.2, kwayland-5.5.4-9.1, kwayland-integration-5.5.4-6.1, kwin5-5.5.4-9.3, kwrited5-5.5.4-6.1, libkdecoration2-5.5.4-6.1, libkscreen2-5.5.4-6.1, libksysguard5-5.5.4-6.1, milou5-5.5.4-6.1, oxygen5-5.5.4-6.1, plasma-nm5-5.5.4-6.3, plasma5-addons-5.5.4-6.1, plasma5-desktop-5.5.4-9.2, plasma5-mediacenter-5.5.4-6.1, plasma5-openSUSE-13.3-29.1, plasma5-pa-5.5.4-6.1, plasma5-sdk-5.5.4-6.1, plasma5-session-5.5.4-6.1, plasma5-workspace-5.5.4-9.1, plasma5-workspace-wallpapers-5.5.4-6.1, polkit-kde-agent-5-5.5.4-6.1, powerdevil5-5.5.4-6.1, systemsettings5-5.5.4-6.1

Created attachment 666317 [details]
This should resolve the remaining issues

If anyone's interested, this patch should resolve the issues caused by patch 664559 till QT 5.6 comes out.
It also takes into account Martin's objection to my previous idea, i.e. "KSld doesn't need to know about [monitor unplugged] and it's also a not needed information in future".
It's a workaround at best, but at least it gives me a usable screenlocker.

What it does:

1) it catches the lastWindowClosed signal and executes QCoreApplication::exit() with retcode = 123
2) "main()" in main.cpp checks the return code after app.exec(). If it is 123, it re-creates the UnlockApp class and re-executes it, otherwise it exits.

Crashes are gone and so is the "ignore the correct password" problem.

can we get the proper fix to this in updates?

I too am affected by this and it's pretty embarrassing to deal with it - in a way that hurts OpenSUSE's reputation.

(In reply to Jason Newton from comment #34)
> can we get the proper fix to this in updates?

Redirecting this question tho the KDE maintainers?

(In reply to Andreas Stieger from comment #35)
> (In reply to Jason Newton from comment #34)
> > can we get the proper fix to this in updates?
> 
> Redirecting this question tho the KDE maintainers?

Please report any remaining issues on bugs.kde.org. Sorry, but I cannot monitor distribution bugtrackers in addition to bugs.kde.org - there are just too many distributions.

(In reply to Martin Gräßlin from comment #36)
> Please report any remaining issues on bugs.kde.org. Sorry, but I cannot
> monitor distribution bugtrackers in addition to bugs.kde.org - there are
> just too many distributions.

Thanks and agree, restoring previous state.

@Andreas , @Martin - let me clarify, I'm having the issue brought up by the patch that Lorenzo reports,

With "file:///usr/share/plasma/look-and-feel/org.openSUSE.desktop/contents/lockscreen/MainBlock.qml:85: TypeError: Property 'tryUnlock' of object function() { [code] } is not a function"

I note that it takes a little while after the monitor is turned off - and by turned off, I mean monitor suspend makes it happen.

If you still wish for me to file the bug at bugs.kde.org, will do so but I just wanted to make sure we weren't too suse specific since there's this patch mentioned in this thread.

well no, I'm not interested in bug reports about patched software :-)

(In reply to Martin Gräßlin from comment #39)
> well no, I'm not interested in bug reports about patched software :-)


I agree. There's however a tiny detail: it is your patch that causes it, mine was merely intended to print more debug stuff to help investigate the problem.

See comment #26.

(In reply to Lorenzo Desole from comment #40)
> (In reply to Martin Gräßlin from comment #39)
> > well no, I'm not interested in bug reports about patched software :-)
> 
> 
> I agree. There's however a tiny detail: it is your patch that causes it,
> mine was merely intended to print more debug stuff to help investigate the
> problem.
> 
> See comment #26.

To clear the issue: OpenSuse is now shipping kscreenlocker with the "setQuitOnLastWindowClosed(false)" patch. I.e. your patch. That same patch triggers a regression that manifests itself either with a crash (in which case kscreenlocker gets relaunched and eventually the user can log in) or with some obscure error that prevents the user from logging in.

so we're back to what is to be done here? I don't want to put expectations but it sounds like a pretty bad bug to ship with and have no resolution other than maybe what I'm trying...

I *may* get by with a qt 5.6 update / kde update by adding KDE:Frameworks5 and KDE:Qt5 repos - but I really wish I didn't have to and generally I don't like moving off base system Qt because applications may suffer...

Should we leave this as resolved as to my eyes it seems like it should be left open until a proper course of action is taken or work around listed.

If you have a chance, please test this patch I made:
https://bugzilla.opensuse.org/attachment.cgi?id=666317

Let me know if it fixes it for you like it does for me.

Regarding the status of this bug report, I agree that "Fixed" is not appropriate, kscreenlocker is still badly broken. More suitable would be "Reopened" or "Resolved -> WONTIFIX". The latter if the powers that be decide that the purpose of a screenlocker is actually lock you out of your PC.