https://bugs.kde.org/show_bug.cgi?id=370676
--- Comment #38 from nyanpasu64 <nyanpas...@tuta.io> --- I think qtvirtualkeyboard-plugin doesn't so much "fix" kscreenlocker but workaround the bug. Pressing Tab leaves the entire screen invisible, but once you move your mouse, the virtual keyboard button (not the password field) is focused, and typing your password does nothing. I think this is a bug in of itself. The bug lies in Qt Quick, where pressing Tab when *all* focusable items have invisible *parents* hangs the app. Installing the virtual keyboard causes kscreenlocker to add an extra button which itself becomes invisible while its parent remains visible (https://invent.kde.org/plasma/plasma-workspace/-/blob/0d491641f3ea148417283819994228aab6896041/lookandfeel/contents/lockscreen/LockScreenUi.qml#L523-535). This coincidentally avoids the condition necessary to trigger the Qt Quick hang bug. The upstream bug reports are: - I reported https://bugreports.qt.io/browse/QTBUG-96762 (marked as duplicate of below) - https://bugreports.qt.io/browse/QTBUG-87190 (unfixed) Qt Quick has a long history of tab focus bugs: - https://bugreports.qt.io/browse/QTBUG-81839 (marked as duplicate of below) - https://bugreports.qt.io/browse/QTBUG-81510 (fixed in 5.14.2 and 5.15.0) - https://bugreports.qt.io/browse/QTBUG-65943 (unfixed) - https://bugreports.qt.io/browse/QTBUG-59181 (fixed in 5.12.0) (And Qt Widgets has scenarios where Tab followed by Shift+Tab doesn't return to the starting widget, which is less severe than a hang. Tab navigation is hard.) Idea: When the password entry is hidden, intercept Tab presses and treat it like moving the mouse (show the lock screen and focus the password field), rather than letting Qt search for an item to focus. When the password entry is shown, let Tab switch widgets as usual. -- You are receiving this mail because: You are watching all bug changes.
