SUMMARY When enabling maliit, sometimes the time-based lock screen will just break and the unlock button doesn't work. This can require a hard reset of the machine unless the user figures out how to get it unstuck again (which is usually possible via opening/closing maliit a few times, which due to https://github.com/maliit/keyboard/issues/223 and https://github.com/maliit/keyboard/issues/222 is almost impossible to physically do). Somehow I only ever see this with the time-based lock screen that comes up after some idle time, not any manually activated screen lock. STEPS TO REPRODUCE 1. Use a device with a touch screen, enable maliit. Having a touch screen probably required since it may depend on how a button is pressed later. If possible, disconnect any regular mouse entirely. Hardware keyboards can be connected. 2. Set the idle lock screen timer to something short like 1 minute. 3. Wait for the lock screen to come up and wait the additional seconds required so that entering the password is guaranteed to be mandatory. 4. You can enter a password via maliit, don't touch a physical keyboard or mouse. Entering a password can also be skipped and sometimes helps with the bug occurring more often, but that's of course not a common use case. Afterward, press the password input button via your finger. OBSERVED RESULT See attached video. The button sometimes just breaks and doesn't work anymore. EXPECTED RESULT The unlock button works. SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: postmarketOS Edge (available in About System) KDE Plasma Version: 6.1.2 KDE Frameworks Version: 6.3.0 Qt Version: 6.6.3 ADDITIONAL INFORMATION
Created attachment 171326 [details] Video showing the unlock button not working
I found a reliable workaround: "Switch User" brings up SDDM instead, which doesn't seem to have this issue. But since this workaround isn't very obvious, I feel like many users are still prone to get stuck at the lock screen and may be desperate enough to hard reset their machine. So this feels like a relatively high impact issue nevertheless.
Sadly, "Switch Users" seems to be broken on latest Alpine Linux for some possibly unrelated reason, seemingly upgrading this to an unavoidable hard lock again for users without a physical keyboard attached.
Is there something I can provide to help fix this? This seems to be fairly high impact.
Sorry we were not able to get to this yet! Can you see if it still happens in Plasma 6.3.5 or later, either in exactly the same form, or in one of the following slightly different ones? - Pressing the button makes all the UI elements enter a disabled state, but it doesn't unlock - Pressing the button makes everything disappear and an "Unlock" button appears, but pressing it does nothing Thanks a lot!
There is for sure still weird stuff going on with 6.3.5, like: 1. tapping "Virtual keyboard" causes the password input box to shift upward while maliit comes up, 2. putting your finger on the submit arrow button (without releasing it) will close maliit but along with also shifting the password input box and the button downward, from under your finger! That doesn't seem like it should be happening. Also, sometimes maliit will open up on top of the password input box without it shifting up, or sometimes the input box will flicker up/down for like a frame or two. In overall, it doesn't feel like whatever code is doing the vertical positioning is working as intended. I didn't manage to lock myself out easily, but it's kind of random so that doesn't necessarily say anything about whether it's gone. Based on the weird movement behavior, my guess is that it's not.
Okay, I just managed to hit it again. The state where pressing the unlock arrow button next to the password input box just does nothing, it won't check the password and won't allow you to login.
An additional note: the input elements don't disappear when pressing the broken button, you can see it in the video. Just nothing happens, the button gets visibly pressed and nothing else changes or happens.
Thanks for re-testing! Please don't change the version field; this is supposed to be used for the *first* version it was reported in, not the latest version it was encountered in.
Oops, sorry, my bad!
No worries. That's why I just had the field name changed to indicate what it's for.
(In reply to Ellie from comment #7) > Okay, I just managed to hit it again. The state where pressing the unlock > arrow button next to the password input box just does nothing, it won't > check the password and won't allow you to login. When this happens, if you wait for the password box to disappear on its own and then re-appear again, does the button start working? If so, this is Bug 500339.
🐛🧹 ⚠️ This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information, then set the bug status to REPORTED. If there is no change for at least 30 days, it will be automatically closed as RESOLVED WORKSFORME. For more information about our bug triaging procedures, please read https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging. Thank you for helping us make KDE software even better for everyone!
🐛🧹 This bug has been in NEEDSINFO status with no change for at least 30 days. Closing as RESOLVED WORKSFORME.
I haven't seen it happen in the last two weeks, that's why I didn't respond. But I didn't use the affected device too much. So if it's okay I'll reopen for now, I don't think that allows a conclusion whether this is fixed or not at this point.
I'm using plasma 6.4.5 on the affected device, so if it's fixed like suggested in the other bug, I shouldn't see it pop up again in the future. My suggestion is I'll keep looking out for this happening again, since it's kind of sporadic, and if it doesn't happen for another month I'll close this ticket.
(Setting it back to waiting for info, to be reported back by myself.)