*** If you're not sure this is actually a bug, instead post about it at https://discuss.kde.org If you're reporting a crash, attach a backtrace with debug symbols; see https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports Please remove this comment after reading and before submitting - thanks! *** SUMMARY The lock screen immediately prompts for password. The screen should be locked, then once user presses any key, it should ask for password. The impact of this is the fingerprint reader activates with a 30 second timeout upon locking the screen. STEPS TO REPRODUCE 1. Press Lock Screen shortcut (Meta+L) OBSERVED RESULT Lock screen immediately asks for password and activates fingerprint reader. EXPECTED RESULT Lock screen should lock the screen with just the time and date showing. Instead it prompts for password and activates fingerprint reader. Fingerprint reader should only be activated upon return of user to the screen. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Fedora KDE KDE Plasma Version: 6.2.5 KDE Frameworks Version: 6.10.0 Qt Version: 6.8.2
I cannot reproduce this bug; may I ask you to include a screen recording? (or even just record the monitor with a phone, just to see how the system behaves!)
Created attachment 178048 [details] lock screen prompting for password upon locking screen
I can reproduce this on my Fedora KDE 41 desktop and a KDE Neon VM (Plasma 6.3.0 on both). On those devices, the immediate presentation of the password prompt occurs whether locking happens via a keyboard shortcut, the Application Launcher menu item, or because of the idle timer. For what it's worth, when the screen locks due to idle time, the "Delay before password required" setting is still honored, even though the password prompt is displayed.
Same issue here on Arch Linux since a few weeks. Happy to help with debugging. Not sure if it is related, but I end up hitting the "max login attempts exceeded" after some time, even if I press "unlock" within the grace period.
It's racy; sometimes it does this, and sometimes it doesn't.
I am experiencing the exact same issue under Fedora 41 since I performed the updates on Feb. 8 Since I am using a U2F USB Security Key as second factor, that is prompting for touching it (blinking LED). Since when I am not on the computer (the reason for the Lock Screen to be activated), the USB Security key always runs into a timeout. And this timeout always results in an unlock failure after I enter the password. solution so far without spamming the logs with invalid logins: disable U2F. But lets be hones, this is not really the sense of having U2F, is ist? List of updates: user@fedora:~$ dnf4 history info 49 Transaction ID : 49 Begin time : Sa 08 Feb 2025 14:07:40 Begin rpmdb : 2fe1084659b88218b76181af29368bce886b4549ee4c0cc5717f551d0281765b End time : Sa 08 Feb 2025 14:08:22 (42 seconds) End rpmdb : e5591d0be4ea5dc81fa7e2f59466a7e6c4b22c47d119fb831c492a4b44214068 User : user <user> Return-Code : Success Releasever : Command Line : Comment : Packages Altered: Install openxr-libs-1.1.43-1.fc41.x86_64 @updates Install assimp-5.3.1-3.fc41.x86_64 @fedora Install jsoncpp-1.9.5-8.fc41.x86_64 @fedora Install poly2tri-0.0^20130501hg26242d0aa7b8-2.fc41.x86_64 @fedora Install pugixml-1.13-6.fc41.x86_64 @fedora Upgrade accountsservice-23.13.9-8.fc41.x86_64 @updates Upgrade brlapi-0.8.5-22.fc41.x86_64 @updates Upgrade brltty-6.6-22.fc41.x86_64 @updates Upgrade clang-19.1.7-2.fc41.x86_64 @updates Upgrade clang-devel-19.1.7-2.fc41.x86_64 @updates Upgrade clang-libs-19.1.7-2.fc41.x86_64 @updates Upgrade clang-resource-filesystem-19.1.7-2.fc41.x86_64 @updates Upgrade clang-tools-extra-19.1.7-2.fc41.x86_64 @updates Upgrade compiler-rt-19.1.7-2.fc41.x86_64 @updates Upgrade fakeroot-1.37-1.fc41.x86_64 @updates Upgrade fakeroot-libs-1.37-1.fc41.x86_64 @updates Upgrade firefox-135.0-1.fc41.x86_64 @updates Upgrade firefox-langpacks-135.0-1.fc41.x86_64 @updates Upgrade geos-3.12.2-3.fc41.x86_64 @updates Upgrade hwdata-0.392-1.fc41.noarch @updates Upgrade ibus-typing-booster-2.27.16-1.fc41.noarch @updates Upgrade libX11-1.8.11-1.fc41.x86_64 @updates Upgrade libX11-common-1.8.11-1.fc41.noarch @updates Upgrade libX11-devel-1.8.11-1.fc41.x86_64 @updates Upgrade libX11-xcb-1.8.11-1.fc41.x86_64 @updates Upgrade libnfsidmap-1:2.8.1-7.rc2.fc41.x86_64 @updates Upgrade libomp-19.1.7-2.fc41.x86_64 @updates Upgrade libomp-devel-19.1.7-2.fc41.x86_64 @updates Upgrade libusb1-1.0.27-9.fc41.x86_64 @updates Upgrade llvm-libs-19.1.7-2.fc41.x86_64 @updates Upgrade nfs-utils-1:2.8.1-7.rc2.fc41.x86_64 @updates Upgrade plasma-integration-6.2.5-2.fc41.x86_64 @updates Upgrade plasma-integration-qt5-6.2.5-2.fc41.x86_64 @updates Upgrade python3-babel-2.17.0-1.fc41.noarch @updates Upgrade python3-boto3-1.36.12-1.fc41.noarch @updates Upgrade python3-botocore-1.36.12-1.fc41.noarch @updates Upgrade python3-brlapi-0.8.5-22.fc41.x86_64 @updates Upgrade python3-unbound-1.22.0-11.fc41.x86_64 @updates Upgrade qt6-filesystem-6.8.2-1.fc41.x86_64 @updates Upgrade qt6-qt5compat-6.8.2-1.fc41.x86_64 @updates Upgrade qt6-qtbase-6.8.2-2.fc41.x86_64 @updates Upgrade qt6-qtbase-common-6.8.2-2.fc41.noarch @updates Upgrade qt6-qtbase-gui-6.8.2-2.fc41.x86_64 @updates Upgrade qt6-qtbase-mysql-6.8.2-2.fc41.x86_64 @updates Upgrade qt6-qtconnectivity-6.8.2-1.fc41.x86_64 @updates Upgrade qt6-qtdeclarative-6.8.2-1.fc41.x86_64 @updates Upgrade qt6-qtimageformats-6.8.2-1.fc41.x86_64 @updates Upgrade qt6-qtmultimedia-6.8.2-1.fc41.x86_64 @updates Upgrade qt6-qtnetworkauth-6.8.2-1.fc41.x86_64 @updates Upgrade qt6-qtpdf-6.8.2-1.fc41.x86_64 @updates Upgrade qt6-qtpositioning-6.8.2-1.fc41.x86_64 @updates Upgrade qt6-qtquick3d-6.8.2-1.fc41.x86_64 @updates Upgrade qt6-qtquicktimeline-6.8.2-1.fc41.x86_64 @updates Upgrade qt6-qtscxml-6.8.2-1.fc41.x86_64 @updates Upgrade qt6-qtsensors-6.8.2-1.fc41.x86_64 @updates Upgrade qt6-qtserialport-6.8.2-1.fc41.x86_64 @updates Upgrade qt6-qtshadertools-6.8.2-1.fc41.x86_64 @updates Upgrade qt6-qtspeech-6.8.2-1.fc41.x86_64 @updates Upgrade qt6-qtspeech-flite-6.8.2-1.fc41.x86_64 @updates Upgrade qt6-qtspeech-speechd-6.8.2-1.fc41.x86_64 @updates Upgrade qt6-qtsvg-6.8.2-1.fc41.x86_64 @updates Upgrade qt6-qttools-6.8.2-1.fc41.x86_64 @updates Upgrade qt6-qttools-common-6.8.2-1.fc41.noarch @updates Upgrade qt6-qttranslations-6.8.2-1.fc41.noarch @updates Upgrade qt6-qtvirtualkeyboard-6.8.2-1.fc41.x86_64 @updates Upgrade qt6-qtwayland-6.8.2-1.fc41.x86_64 @updates Upgrade qt6-qtwebchannel-6.8.2-1.fc41.x86_64 @updates Upgrade qt6-qtwebengine-6.8.2-1.fc41.x86_64 @updates Upgrade qt6-qtwebsockets-6.8.2-1.fc41.x86_64 @updates Upgrade qt6-qtwebview-6.8.2-1.fc41.x86_64 @updates Upgrade qt6-srpm-macros-6.8.2-1.fc41.noarch @updates Upgrade rpm-sequoia-1.7.0-5.fc41.x86_64 @updates Upgrade selinux-policy-41.32-1.fc41.noarch @updates Upgrade selinux-policy-targeted-41.32-1.fc41.noarch @updates Upgrade unbound-anchor-1.22.0-11.fc41.x86_64 @updates Upgrade unbound-libs-1.22.0-11.fc41.x86_64 @updates Upgrade xorg-x11-server-Xwayland-24.1.5-1.fc41.x86_64 @updates
Since I am experiencing this issue since Feb 8. I could tackle it down to some updated packages (see list in the post before). The issue is definitly KDE related (no issue with Gnome), so there are these updates: plasma-integration-6.2.5-2.fc41.x86_64 plasma-integration-qt5-6.2.5-2.fc41.x86_64 and also some QT6 packages. Since the issue appeared BEFORE the upgrade to Plasma 6.3 (which was pushed on Feb. 12), I would say it appeared with Plasma 6.2.5.
I've been seeing this 'immediate password prompt' issue on several systems, all running Arch. I've compared package versions between affected and not-affected systems and have concluded that it is the update of Qt 6.8.1 -> 6.8.2 causing this. I added some additional logging output to LockScreenUi.qml (/usr/share/plasma/shells/org.kde.plasma.desktop/contents/lockscreen/) and it seems that Item::MouseArea::onPositionChanged is being called immediately even when the system is idle (no mouse movement), setting uiVisible = true. A quick search of the Qt 6.8.2 release notes finds QTBUG-127122 - this is an intentional change emitting the positionChanged event in response to a QEvent::HoverEnter event. No matter where the pointer is positioned, it will enter the newly created full-screen MouseArea when the lock screen is displayed and onPositionChanged will be called. I have temporarily fixed the issue on a couple of systems by introducing a new boolean property 'ignorePositionChanged' and using it to make the first call of onPositionChanged a no-op (uiVisible = !ignorePositionChanged; ignorePositionChanged = false). I don't have any experience with Qt so perhaps there is a more elegant solution.
(In reply to Marc Payne from comment #8) > I've been seeing this 'immediate password prompt' issue on several systems, > all running Arch. I've compared package versions between affected and > not-affected systems and have concluded that it is the update of Qt 6.8.1 -> > 6.8.2 causing this. That would fit with what I experienced, since I have the issue since the upgrade of Qt to 6.8.2 > I added some additional logging output to LockScreenUi.qml > (/usr/share/plasma/shells/org.kde.plasma.desktop/contents/lockscreen/) and > it seems that Item::MouseArea::onPositionChanged is being called immediately > even when the system is idle (no mouse movement), setting uiVisible = true. > A quick search of the Qt 6.8.2 release notes finds QTBUG-127122 - this is an > intentional change emitting the positionChanged event in response to a > QEvent::HoverEnter event. No matter where the pointer is positioned, it will > enter the newly created full-screen MouseArea when the lock screen is > displayed and onPositionChanged will be called. Amazing work that you could tackle it down, thank you! Wouldn't it be an idea to file a Qt bug about this regression?
What QTBUG-127122 mentions is: I can't find out why this signal is not triggered when the mouse enters for the first time in the MouseArea So it could be that when the lock screen is enabled, the MouseArea is created. Since the mouse is not really entering the MouseArea but is more or less already in the MouseArea since creation, this well could an unintentional regression. But to be hones, I have no experience how it coded, it's just an idea.
(In reply to fhortner from comment #10) > What QTBUG-127122 mentions is: > I can't find out why this signal is not triggered when the mouse enters for > the first time in the MouseArea > > So it could be that when the lock screen is enabled, the MouseArea is > created. > Since the mouse is not really entering the MouseArea but is more or less > already in the MouseArea since creation, this well could an unintentional > regression. > > But to be hones, I have no experience how it coded, it's just an idea. Yes, the MouseArea is essentially being created underneath the mouse pointer so the pointer is already deemed to have entered it. A QEvent::HoverEnter event is fired as a result which I think is reasonable. The change in QTBUG-127122 causes the HoverEnter handler to now emit the positionChanged signal. In the case of the lock screen, the pointer hasn't actually moved but usually a HoverEnter would be occurring as a result of pointer movement and so a positionChanged signal makes sense, which I think was the point being made in the Qt bug report. I'm not sure the Qt Company will be particularly interested in complicating their code to deal with this edge case. If this behavior had been in place from the start, KDE would have needed to work around it anyway.
Well, I do understand "the mouse to enter" as being moved activly into the MouseArea. But I would definitely say that "enter" does not mean "find itself in the MouseArea upon creation". It makes sense to fire a QEvent::HoverEnter event. But does it make sense to emit a positionChanged signal? I would say the positionChanged signal should only be emitted in case the mouse was actually moved and changed it's position. This is not the case when the system is idle and a new MouseArea is created. That's why I see it as a Qt regression.
(In reply to Marc Payne from comment #11) > Yes, the MouseArea is essentially being created underneath the mouse pointer > so the pointer is already deemed to have entered it. A QEvent::HoverEnter > event is fired as a result which I think is reasonable. The change in > QTBUG-127122 causes the HoverEnter handler to now emit the positionChanged > signal. In the case of the lock screen, the pointer hasn't actually moved > but usually a HoverEnter would be occurring as a result of pointer movement > and so a positionChanged signal makes sense, which I think was the point > being made in the Qt bug report. I'm not sure the Qt Company will be > particularly interested in complicating their code to deal with this edge > case. If this behavior had been in place from the start, KDE would have > needed to work around it anyway. The point being made in the QTBUG-127122 was, that the after actively moving of the mouse into the MouseArea for the first time, the positionChanged signal was not fired. The Mouse was moved from -1,-1 to 25,25, so it was positioned from outside the MouseArea into it upon movement. Have a look at the QDEBUG messages within the bug rebort: The onPositionChanged signal is missing for the first time. this is the kind of output I got ``` QDEBUG : MouseArea::test_mouse_move() qml: move to -1,-1 QDEBUG : MouseArea::test_mouse_move() qml: move to 25,25 QDEBUG : MouseArea::test_mouse_move() qml: onEntered QDEBUG : MouseArea::test_mouse_move() qml: move to 50,50 QDEBUG : MouseArea::test_mouse_move() qml: onPositionChanged 50 , 50 QDEBUG : MouseArea::test_mouse_move() qml: move to 100,100 QDEBUG : MouseArea::test_mouse_move() qml: onExited QDEBUG : MouseArea::test_mouse_move() qml: move to 150,150 QDEBUG : MouseArea::test_mouse_move() qml: onEntered QDEBUG : MouseArea::test_mouse_move() qml: move to 175,175 QDEBUG : MouseArea::test_mouse_move() qml: onPositionChanged 175 , 175 ```
Qt Bug Report: https://bugreports.qt.io/browse/QTBUG-135099
(In reply to Marc Payne from comment #8) > I've been seeing this 'immediate password prompt' issue on several systems, > all running Arch. I've compared package versions between affected and > not-affected systems and have concluded that it is the update of Qt 6.8.1 -> > 6.8.2 causing this. > > I added some additional logging output to LockScreenUi.qml > (/usr/share/plasma/shells/org.kde.plasma.desktop/contents/lockscreen/) and > it seems that Item::MouseArea::onPositionChanged is being called immediately > even when the system is idle (no mouse movement), setting uiVisible = true. > A quick search of the Qt 6.8.2 release notes finds QTBUG-127122 - this is an > intentional change emitting the positionChanged event in response to a > QEvent::HoverEnter event. No matter where the pointer is positioned, it will > enter the newly created full-screen MouseArea when the lock screen is > displayed and onPositionChanged will be called. > > I have temporarily fixed the issue on a couple of systems by introducing a > new boolean property 'ignorePositionChanged' and using it to make the first > call of onPositionChanged a no-op (uiVisible = !ignorePositionChanged; > ignorePositionChanged = false). I don't have any experience with Qt so > perhaps there is a more elegant solution. Are you able to share what you've changed in the LockScreenUI.qml file to temporarily fix this? Or even attach your edited LockScreenUI.qml file? Thank you!
Created attachment 179700 [details] Temporary fix
(In reply to Ketan from comment #15) > (In reply to Marc Payne from comment #8) > > I've been seeing this 'immediate password prompt' issue on several systems, > > all running Arch. I've compared package versions between affected and > > not-affected systems and have concluded that it is the update of Qt 6.8.1 -> > > 6.8.2 causing this. > > > > I added some additional logging output to LockScreenUi.qml > > (/usr/share/plasma/shells/org.kde.plasma.desktop/contents/lockscreen/) and > > it seems that Item::MouseArea::onPositionChanged is being called immediately > > even when the system is idle (no mouse movement), setting uiVisible = true. > > A quick search of the Qt 6.8.2 release notes finds QTBUG-127122 - this is an > > intentional change emitting the positionChanged event in response to a > > QEvent::HoverEnter event. No matter where the pointer is positioned, it will > > enter the newly created full-screen MouseArea when the lock screen is > > displayed and onPositionChanged will be called. > > > > I have temporarily fixed the issue on a couple of systems by introducing a > > new boolean property 'ignorePositionChanged' and using it to make the first > > call of onPositionChanged a no-op (uiVisible = !ignorePositionChanged; > > ignorePositionChanged = false). I don't have any experience with Qt so > > perhaps there is a more elegant solution. > > Are you able to share what you've changed in the LockScreenUI.qml file to > temporarily fix this? Or even attach your edited LockScreenUI.qml file? > Thank you! Sure, I've attached a diff which will apply with the patch command. Or you can apply the changes by hand. It just introduces an additional boolean property and modifies the onPositionChanged handler.
(In reply to Marc Payne from comment #17) > (In reply to Ketan from comment #15) > > (In reply to Marc Payne from comment #8) > > > I've been seeing this 'immediate password prompt' issue on several systems, > > > all running Arch. I've compared package versions between affected and > > > not-affected systems and have concluded that it is the update of Qt 6.8.1 -> > > > 6.8.2 causing this. > > > > > > I added some additional logging output to LockScreenUi.qml > > > (/usr/share/plasma/shells/org.kde.plasma.desktop/contents/lockscreen/) and > > > it seems that Item::MouseArea::onPositionChanged is being called immediately > > > even when the system is idle (no mouse movement), setting uiVisible = true. > > > A quick search of the Qt 6.8.2 release notes finds QTBUG-127122 - this is an > > > intentional change emitting the positionChanged event in response to a > > > QEvent::HoverEnter event. No matter where the pointer is positioned, it will > > > enter the newly created full-screen MouseArea when the lock screen is > > > displayed and onPositionChanged will be called. > > > > > > I have temporarily fixed the issue on a couple of systems by introducing a > > > new boolean property 'ignorePositionChanged' and using it to make the first > > > call of onPositionChanged a no-op (uiVisible = !ignorePositionChanged; > > > ignorePositionChanged = false). I don't have any experience with Qt so > > > perhaps there is a more elegant solution. > > > > Are you able to share what you've changed in the LockScreenUI.qml file to > > temporarily fix this? Or even attach your edited LockScreenUI.qml file? > > Thank you! > > Sure, I've attached a diff which will apply with the patch command. Or you > can apply the changes by hand. It just introduces an additional boolean > property and modifies the onPositionChanged handler. thank you so much! this fix worked perfectly!
*** Bug 500694 has been marked as a duplicate of this bug. ***
*** Bug 499893 has been marked as a duplicate of this bug. ***
*** Bug 500357 has been marked as a duplicate of this bug. ***
Will the temporary fix be included upstream in one of the next plasma releases?
(In reply to Xwang from comment #22) > Will the temporary fix be included upstream in one of the next plasma > releases? The way for a code fix to get incorporated into Plasma would be for it to be submitted as a merge request via KDE Invent (GitLab): https://community.kde.org/Infrastructure/GitLab#Submitting_a_merge_request - Marc, if you're able to submit that then folks can help either get it merged or figure out whatever tweaks would be needed to fix :-)
*** Bug 505222 has been marked as a duplicate of this bug. ***
The temporary fix works for me on Kubuntu 25.04 (KDE Plasma Version: 6.3.4, KDE Frameworks Version: 6.12.0, Qt Version: 6.8.3)
The fix works in my Arch system too, but if the screen is locked for a long time, unlocking by using the fingerprint is not proposed.
That's unrelated, and cannot be fixed without technical changes in fprint right now.
(In reply to Nate Graham from comment #27) > That's unrelated, and cannot be fixed without technical changes in fprint > right now. Can you please elaborate on that? I'm trying to understand what is happening. Maybe I'm wrong but it seems that every time I move the mouse the fprintd.service is restarted. Then if the fingerprint is used before a timeout (30 second I presume), the service is deactivated. Otherwise it seems it remains open and prevents the login with fingerprint. Is it something like this?
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/3103
Git commit c0d12c52198a660629dcd194f85ad750196fdd68 by Nate Graham, on behalf of Marc Payne. Committed on 11/07/2025 at 17:01. Pushed by ngraham into branch 'master'. lockscreen: prevent immediate prompting for the password As of Qt 6.8.2, the fix for QTBUG-127122 causes a positionChanged event to be emitted when handling QEvent::HoverEnter. The lockscreen creates a full screen MouseArea on every connected screen, one of which will cover the current position of the mouse pointer. This causes QEvent::HoverEnter and then the positionChanged event to be raised immediately. The mouse position did not change. Ignore the spurious (first) positionChanged event, show the password UI as usual in response to further events. M +5 -1 desktoppackage/contents/lockscreen/LockScreenUi.qml https://invent.kde.org/plasma/plasma-desktop/-/commit/c0d12c52198a660629dcd194f85ad750196fdd68
Git commit fc4981c4ec73cd2d1f15dbacc13fc8dc4d047a18 by Nate Graham. Committed on 11/07/2025 at 17:06. Pushed by ngraham into branch 'Plasma/6.4'. lockscreen: prevent immediate prompting for the password As of Qt 6.8.2, the fix for QTBUG-127122 causes a positionChanged event to be emitted when handling QEvent::HoverEnter. The lockscreen creates a full screen MouseArea on every connected screen, one of which will cover the current position of the mouse pointer. This causes QEvent::HoverEnter and then the positionChanged event to be raised immediately. The mouse position did not change. Ignore the spurious (first) positionChanged event, show the password UI as usual in response to further events. (cherry picked from commit c0d12c52198a660629dcd194f85ad750196fdd68) Co-authored-by: Marc Payne <marc.payne@mdpsys.co.uk> M +5 -1 desktoppackage/contents/lockscreen/LockScreenUi.qml https://invent.kde.org/plasma/plasma-desktop/-/commit/fc4981c4ec73cd2d1f15dbacc13fc8dc4d047a18
I have upgraded to 6.4.3, and this doesn't seem to work for my use case: I use fcitx5 as input method, it has a feature to show a small IME popup whenever (text input) focus changes. E.g. when I click the browser URL bar, a small popup showing my current IME will show up. So whenever I lock screen, this IME popup will show up, probably because the password field always take focus after entering lockscreen, and this IME popup will in turn bring up the whole password prompt. As a result, in 6.4.3, password prompt still shows up immediately after locking screen. Disabling the fcitx5 focus change popup feature makes it normal. By the way I am not sure whether this is a kscreenlocker issue or fcitx5 issue :|
Still an issue for me with 6.3.4 on Kubuntu. I just did a dist upgrade from 24.04. Honestly don't know what version of Plasma I was running before the upgrade but it worked fine then.
That makes sense, since the issue is fixed in Plasma 6.4.3.