https://bugs.kde.org/show_bug.cgi?id=500339
--- Comment #29 from Ardo Kirsipuu <[email protected]> --- I'm also having the issue of sometimes not being able to log in (Enter/button doesn't do anything). Here are my findings after several days of debugging: None of the following will reproduce it always, it fails rarely (~5%), works most of the time: * I can reproduce it when it's initiated by timeout (e.g. 1 minute) - different timings and other settings like grace period doesn't seem to affect it * I cannot reproduce when I initiate it myself by via Meta+L (gave it some good ~100 attempts) * However, I can reproduce it by directly executing from command line `/usr/libexec/kscreenlocker_greet`, which is strange Some of the workarounds I found when the problem hits (no restart needed): * "Switch User" button exits the lock screen (kscreenlocker) and opens the log-in view (SDDM), where the logging in works * Clear the input field and wait for 10 seconds until the inputs get hidden and then try again This led me to investigate `/usr/share/plasma/shells/org.kde.plasma.desktop/contents/lockscreen/LockScreenUi.qml` file and I tried to add some "logging" in there. Being new to Linux, didn't know where the console.log would be found + writing to file is a bit restricted in there = so I just created a new UI element to dump my "logs" into. Initially I thought there might be some race condition in there with how the states of `uiVisible` and `blockUI` are handled in the event handler functions, but currently my hypothesis is that the bug is not in that file, because: * `onPasswordResult` gets called * when it fails then `onSucceeded` nor `onFailed` ever get called (is there a third option besides success and fail?) I don't have any insight what happens or should happen between `onPasswordResult` and `onSucceeded`/`onFailed`, hopefully somebody knows better and can make some sense out of this all. PROBABLY IMPORTANT: If the `authenticator.startAuthenticating()` is also added to the `onBlockUIChanged` event handler, then I could not reproduce the bug anymore for some reason. Maybe because the probability goes to 0.05*0.05=0.0025 and my ~100 attempts wasn't enough to reveal it? I guess better understanding of the backend is needed here. I have also attached journalctl logs, my custom LockScreenUi.qml file and a screenshot of it: There are multiple successful attempts (for comparison) before 02:30 and then the screenshot is about the failure at 02:30:29 (+ 3 additional attempts to press Enter or click the button) followed by the workaround of clearing the input and waiting for 10 second timeout for the UI to disappear to try again (and succeed). Oh, and here's my system info: Operating System: Fedora Linux 42 KDE Plasma Version: 6.4.0 KDE Frameworks Version: 6.15.0 Qt Version: 6.9.1 Kernel Version: 6.14.11-300.fc42.x86_64 (64-bit) Graphics Platform: Wayland Processors: 2 × AMD A6-9210 RADEON R4, 5 COMPUTE CORES 2C+3G Memory: 16 GiB of RAM (15.1 GiB usable) Graphics Processor: AMD Radeon R4 Graphics Manufacturer: LENOVO Product Name: 80S9 System Version: Lenovo YOGA 510-14AST -- You are receiving this mail because: You are watching all bug changes.
