Sorry :(

Edit:

There's also a TextInput.canRedo property

I'm going to add that anyway.
It will fix one of the two open bugs.

@broulik
does that change your opinion on this.

I'm against reverting this. I think this is a very important feature for touch input and nowadays we support a touch keyboard directly in the login screen. Given that the reveal button is IMHO a must have feature.

On most touch platforms, only the last character in password prompts is revealed, one-at-a-time. It might make more sense to implement that than to keep the reveal button.

In D9040#173465, @ngraham wrote:

On most touch platforms, only the last character in password prompts is revealed, one-at-a-time. It might make more sense to implement that than to keep the reveal button.

On touch platforms: yes, but this is hybrid. Do you want your password being revealed on a big screen when entering with keyboard? Probably not. Thus the reveal button is a better solution than reveal while typing in this case.

People here know that I'm a security fanatic. And I honestly fail to see the issue with the button. Yes, if you enter half your password and move away someone else could reveal your password. Similar if you mistype and move away someone could see your password. This is a highly unrealistic scenario and doesn't allow to get the real password. It's only a problem if you use a password like 08041985 (my birthday) and someone would know that 09041985 has an obvious error. If you use such kind of password it doesn't matter at all: your friends will be able to break it.

Yes I see the concerns, but just because there are concerns means we need to destroy the usability here. Security and usability are always in conflict with each other and one needs to find the right level. Sometimes the security should win, sometimes the usability. In this case usability should win. If there are valid security concerns we should address them. I could imagine:

• show info that the password got revealed
• clear the text fields after certain amount of inactivity
• clear the text field after incorrect password
• make button not clickable, but only on touch (might not work on X, but heck)

If the icon is not fixed in the login screen, I'm definitely pushing the SDDM side for 5.12.
An invisible hit area is not usability.

As for the lock screen:

• the rationale for introducing was originally consistency, it isn't.
• The virtual keyboard is a relevant point, which we should do something with.

A button that a user has to press every single time isn't an ideal solution. If visual feedback is needed, visual feedback is needed.

Ideally we do want that echo mode that Nate described (PasswordEchoOnEdit unfortuantely isn't it) then switch between them based on whether we're showing the input panel.

I'll try and look into that.

We have several customer systems that have arcane password requirements and have spill proof keyboards. Those keyboards make it easy to mess up a keystroke or two for which this feature is indispensable. Maybe default to off but allow configuration to enable this feature.

My apologies to resurrect such an old issue, but for me this is a notable regression. My use case are children aged 7-10 logging in on a desktop PC. They are not completely firm in keyboard usage and need some kind of help to enter their passwords. The “reveal password” button is essential for them being able to log in theirselves.

The missing button was immediately noticed by them after a Kubuntu 18.04 => 20.04 upgrade.

I understand the case for consistency, but at the same time I assume other groups of users, like elderly or persons with Parkinson’s or poor eyesight, would also benefit from re-adding the button.

Yes, my own children make use of the "Show password" button on our family Windows 10 machine (Which I plan to put KDE Neon on soon) and I can confirm your exact use case and how this regresses it.

Could you please file a bug report on plasmashell | Theme - Breeze on https://bugs.kde.org so we can track it and discuss there? Thanks!

And please mention the URL for this change, for reference purposes. :)

Done :-)

https://bugs.kde.org/show_bug.cgi?id=429622