In the Fedora installer, the icon, which represents an eye, to hide and show password, is incorrect.
I have shown a comparison to KeePassXC, which is correct.
The eye should obviously be covered when the password is NOT visible.
Thanks for reading!
Nice catch !
I am not sure I agree. While the password is hidden, there is a button with an eye, and I have always read this as “make visible”. After clicking, it changes to the crossed out eye or “make invisible”. This matches my mental model of buttons that are marked with the action I want to achieve.
Bitwarden uses the same semantic as the Fedora installer:
So does Firefox:
Or GitLab’s password field when logging in:
While I am not saying that KeepassXC does it wrong, it certainly does it differently than many others.
I must say I’d never registered this before - I guess I just perceive the button as a toggle without thinking about whether it represents “state now” or “state you achieve by clicking it”.
I should have known that someone more into UI/UX has already written an article about this. 
Thinking about it, the most important thing (which is a universal as far as I can see) is that “hidden” is the initial state.
It’s only when the field is empty that ambiguity would really arise - if you’ve started typing, you can see whether the characters are hidden or not.
Unless your password is just a bunch of circles … SCNR
To be fair, there are accessibility use cases, but for those, the eye icon isn’t a great solution whichever “polarity” it has.
The Medium author makes a good point that Google’s “Show password” checkbox is a good solution.
I think one of the issues is that the “eye” floating in the input field is quite ambiguous whether it wants to be a button (with the target state and not the current one) or a toggle (which represents the current state). The checkbox doesn’t have that issue, it’s a checkbox. 
Thanks, yeah you gotta have a keen eye to not miss something!
That’s the entire problem, one may believe it is NOT hidden by default, thus clicking the button to toggle it, then entering the password while not really paying attention to the monitor, and whoops your password got caught in public by either a person, camera, or Van Eck Phreaking.
I believe you may have been trained incorrectly, but each to their own!
When I see a button labelled “save”, I expect it to save my document. I don’t think that the document is already saved and clicking the button will “un-save” it.
You can of course consider me trained incorrectly, but just from the few examples I have posted, it’s clear to me that I am not alone in this and that it is not as obvious as you consider it to be.
I cannot recall seeing the eye closed and the paswiord visible in any web app
or desktop app.
As Lar’s said the icon tells you what will happen if the icon is click.
So the eye open is correct from my UX understanding.
Do you know of a UI that uses the reverse?
Do you know of a UI that defaults to in the clear for a password field?
FWIW, the behavior of the show/hide password icon in the installer is consistent with that of the desktop environment (confirming for GNOME). One can check this for instance at the GDM login screen or the lock screen.
Yes, same in the KDE Plasma lockscreen and in the coming Plasma Login Manager. (Current SDDM doesn’t have the “show password” option, your characters are always hidden.)
It’s the same as with Play/Pause in a media player. Do you see the status or do you see the status after clicking?
Well, once you hear music you know.
@tqcharm The gnome tag might actually be valid for this discussion.
Anaconda doesn’t make design choices like this on its own. It is more of the whatever the available toolkit offers, we have to use it.
In this case it seems to be the GTK3 interface, than the toolkit is GTK3. As GTK3 is on its way to deprecation it makes more sense to check how GTK4 and WebUI solve this, and then see if that needs adjustments, ideally file a bugreport.
If it is addressed in GTK4 already in some way, than it is a kind of the “Won’t fix” discussion.
Sure, I see your point. It can be added back if relevant. I considered removing it since Anaconda is obviously not limited to GNOME/GTK based editions/spins only.
As mentioned in my post above, the behavior noticed by the OP is consistent with how GNOME (including GNOME 50) handles the password fields. And @pg-tips confirmed the same behavior on KDE Plasma. So working as expected from my POV, no bug report needed.
Edit: I didn’t have time to check how the new WebUI handles this.
Wow you guys are really against improvements! Well, just wanted to show you a little detail, you gotta look really hard to see it.
Anyways, thanks to any GNU Linux developer reading this, for all you’ve done!
GNU Linux is like the alphabet these days!
