First keystroke not captured by password input in screen lock since bc91867

[Frederick888]

Description

When screen lock is on, the first keystroke is no longer captured by password input as the first character of the password.

It only happens when the password input shows up for the first time though.

Steps to reproduce

1. Apply Materia Dark in both System Settings Global Theme and Kvantum
2. Keyboard shortcut to lock screen
3. Start typing password
4. First character is not captured
5. Esc to make password input disappear, or clear password and wait for timeout
6. Start typing again
7. First character is captured this time

Additional info

I did a bisect and the first bad commit was bc91867782e3bf1f89a84cea9ed9fd690849373d

System: Arch Packages:

pacman -Q $(pacman -Qq --groups plasma kf5)

bluedevil 1:5.25.4-1
breeze 5.25.4-1
breeze-gtk 5.25.4-1
drkonqi 5.25.4-1
kactivitymanagerd 5.25.4-1
kde-cli-tools 5.25.4-1
kde-gtk-config 5.25.4-1
kdecoration 5.25.4-1
kdeplasma-addons 5.25.4-1
kgamma5 5.25.4-1
khotkeys 5.25.4-1
kinfocenter 5.25.4-1
kmenuedit 5.25.4-1
kscreen 5.25.4-1
kscreenlocker 5.25.4-1
ksshaskpass 5.25.4-1
ksystemstats 5.25.4-1
kwallet-pam 5.25.4-1
kwayland-integration 5.25.4-1
kwin 5.25.4-1
kwrited 5.25.4-1
layer-shell-qt 5.25.4-1
libkscreen 5.25.4-1
libksysguard 5.25.4-1
milou 5.25.4-1
oxygen 5.25.4-1
oxygen-sounds 5.25.4-1
plasma-browser-integration 5.25.4-1
plasma-desktop 5.25.4-1
plasma-disks 5.25.4-1
plasma-integration 5.25.4-1
plasma-nm 5.25.4-1
plasma-pa 5.25.4-1
plasma-sdk 5.25.4-1
plasma-thunderbolt 5.25.4-1
plasma-workspace 5.25.4-1
plasma-workspace-wallpapers 5.25.4-1
polkit-kde-agent 5.25.4-1
powerdevil 5.25.4-1
sddm-kcm 5.25.4-1
systemsettings 5.25.4-1
xdg-desktop-portal-kde 5.25.4-1
attica 5.97.0-1
baloo 5.97.0-1
bluez-qt 5.97.0-1
breeze-icons 5.97.0-1
extra-cmake-modules 5.97.0-1
frameworkintegration 5.97.0-1
kactivities 5.97.0-1
kactivities-stats 5.97.0-1
karchive 5.97.0-1
kauth 5.97.0-1
kbookmarks 5.97.0-1
kcmutils 5.97.0-1
kcodecs 5.97.0-1
kcompletion 5.97.0-1
kconfig 5.97.0-1
kconfigwidgets 5.97.0-1
kcontacts 1:5.97.0-1
kcoreaddons 5.97.0-1
kcrash 5.97.0-1
kdbusaddons 5.97.0-1
kdeclarative 5.97.0-1
kded 5.97.0-1
kdesu 5.97.0-1
kdnssd 5.97.0-1
kdoctools 5.97.0-1
kemoticons 5.97.0-1
kfilemetadata 5.97.0-1
kglobalaccel 5.97.0-1
kguiaddons 5.97.0-1
kholidays 1:5.97.0-1
ki18n 5.97.0-1
kiconthemes 5.97.0-1
kidletime 5.97.0-1
kinit 5.97.0-1
kio 5.97.0-1
kirigami2 5.97.0-1
kitemmodels 5.97.0-1
kitemviews 5.97.0-1
kjobwidgets 5.97.0-1
knewstuff 5.97.0-1
knotifications 5.97.0-1
knotifyconfig 5.97.0-1
kpackage 5.97.0-1
kparts 5.97.0-1
kpeople 5.97.0-1
kpty 5.97.0-1
kquickcharts 5.97.0-1
krunner 5.97.0-1
kservice 5.97.0-1
ktexteditor 5.97.0-1
ktextwidgets 5.97.0-1
kunitconversion 5.97.0-1
kwallet 5.97.0-2
kwayland 5.97.0-1
kwidgetsaddons 5.97.0-1
kwindowsystem 5.97.0-1
kxmlgui 5.97.0-1
modemmanager-qt 5.97.0-1
networkmanager-qt 5.97.0-1
plasma-framework 5.97.0-1
prison 5.97.0-1
purpose 5.97.0-1
qqc2-desktop-style 5.97.0-1
solid 5.97.0-1
sonnet 5.97.0-1
syndication 5.97.0-1
syntax-highlighting 5.97.0-1
threadweaver 5.97.0-1

Originally reported at https://bugs.kde.org/show_bug.cgi?id=457874

[varlesh]

If you move the mouse or press any key, the dialog will appear and will work normally. It's so intended... Logically, how can you enter a password without even seeing the input field?

[varlesh]

By default, the dialog is hidden for security. But in order for it to appear, some action is required from you. Mouse movement or keystroke.

[Frederick888]

@varlesh Thank you for the quick response! However

1. This is an extra step that slows users down
2. It is not consistent with Breeze. Of cos Materia UX doesn't need to be the same as that of Breeze in every way, but as an official Plasma L&P, it should at least set an example to a degree
3. Materia itself is not consistent across the board either. If it's considered more secure (which I tbh don't think so...), why is the keystroke captured when the password input shows up for the second time?
4. Personally I use Yubico OTP for screen lock, where the YubiKey acts as a keyboard and 'types' OTPs in. It'd been extremely convenient for me to plug in YubiKey, tap on it, and boom, screen unlocked. I understand that not everyone's got the same workflow, but with a focus on efficiency and ergonomics, I believe the old behaviour was a smoother and more enjoyable experience.

Would you please kindly reconsider this design? Thanks again!

[varlesh]

Actually, this is how it works. If you like Breeze, please use it. I don't have to and I don't have to follow their security guidelines. I have expressed and explained my point of view, but it's up to you.

[varlesh]

After all, this is the power of open source code, not the ability to adapt to others!

[varlesh]

By the way, the developer of the Kvantum engine spat on the development of KDE and Karigami. But, what does it change?

[varlesh]

You are currently using the Kvantum engine, which is denied by the KDE developers. Are they ignoring him or don't you see it?

[varlesh]

And after that, who forbids me to use my style, should I follow their worldview? Don't you think it's silly and inappropriate?

[varlesh]

KDE developers, answer one simple question. If Breeze is everything for you, then why do you need stores and different design engines and different design themes? You contradict yourself!

[varlesh]

@tsujan Look at this madness. I'm already giving up on creating anything for KDE

[varlesh]

Password entry must be visible and monitored. This is security! I refuse and do not accept this request! Sorry

[tsujan]

I don't use KDE — although I have it for testing under it — but Kvantum has nothing to do with capturing or not capturing key strokes. Perhaps it's related to Plasma theme plus a bug in Plasma

Plasma 5.25 was so buggy that Manjaro (the distro I use) hasn't put it in its Testing branch yet. I still have Plasma 5.24.6 ;)

[tsujan]

BTW, although my Qt style is Kvantum under KDE, I left the Plasma style to be Breeze — didn't have time for more Plasma bugs.

[varlesh]

@tsujan No, they say here that I have to follow the KDE or Breeze standards. But what about freedom of will and freedom of development? You are one of the best developers for me. I appreciate it and respect it for your dedication to you.

[tsujan]

Quoting from https://bugs.kde.org/show_bug.cgi?id=457874: "Does it happen with other screen locker themes?" Isn't the screen locker theme related to Plasma theme? Apparently, there's a backward-incompatible change in the screen locker.

And yes, this reminds me of https://stopthemingmy.app/. Recently, I had to add its link to a few comments, to show that KDE devs aren't far behind GNOME devs ;)

I think, if you want to "fix" this, you'll have to make changes to your screen locker theme, by following what's done in the Breeze screen locker theme. Sorry that I can't be of any help. Dealing with Plasma themes exceeds the threshold of my tolerance.

[varlesh]

I'm sad for KDE. What has he turned into? Where is he going? Only sadness and sadness in the heart...

[tsujan]

BTW, don't rely on my words about screen locker! Please investigate it yourself. My area is Qt itself, not what they do in KDE Plasma.

If you find something, please also let me know.

I'm sad for KDE.

My feelings went beyond sadness several years ago ;) Whenever I log in to KDE from LXQt, I can find a regression — to say nothing of new bugs.

As a developer, I know that bugs are inevitable and regressions sometimes happen. But, with this amount of problems, I started to see KDE as a DE for constant experiments of its developers, not a stable DE to use.

[Pointedstick]

Nobody's forcing anyone to do anything. As far as I can see, this is just a bug report. If you want to have a lock screen in your Plasma theme that behaves differently from how Breeze behaves, that's fine.

[dominichayesferen]

^ this.

Nitrux, Feren OS, etc. don't conform with the usual lockscreen designs and behaviour, even if they are or aren't based on Breeze's code.

Additionally, a KDE Plasma Lock Screen has 0 QStyle involvement iirc, as the Plasma Style's own renderer is used instead for controls on the lock screen, so there was literally 0 reason Kvantum had to be pulled into this.

Anyway, I just tried it in KDE Plasma 5.25.4, and I cannot reproduce the issue - the first keystroke successfully registers in the password field, despite the screen being in the invisible state, as intended (also nice design btw). Edit: Nevermind, got it on my second try. Edit 2: misread the earlier chat, and thought it was 100% unrelated to the lock screen, my bad.

[dominichayesferen]

Ok, look at it this way, re:the design of triggering the lockscreen: Without the OP's design wishes in the equation, the bug here is that the design intention of it registering the first input as only triggering the visibility of the field is not consistent - the field is focused on subsequent attempts, meaning it types into the field in the process.

Now, there might be a way to unfocus the field when the timer expires to hide the UI - that, you'll have to find yourself as I forget how one does that. Edit: Check below PR

[varlesh]

@dominichayesferen I'm test your PR, it's not worked for me... Plasma 5.25.4

[varlesh]

@Frederick888 fixed