Ask / Submit

Revealing password fields in [answered]

asked 2016-01-23 18:14:47 +0300

ossi1967 gravatar image

updated 2016-01-24 21:15:14 +0300

@coderus explained below why the new feature "Allow toggling password text visibility in password fields" cannot work in a logical and satisfying way for editing PW already stored before. This technically closes my question as answered. I'm not happy with what I've learned, though, maybe a feature request will follow. :)

There's a new feature in that allows us to see the content of a password field. If it works correctly, there's a way to toggle the view on the end of the input field: It shows "abc" if the pw is hidden (so you press the letters to reveal it) and three dots if it's revealed and you want it to be hidden again. At least, that's the theory.

In the release notes, this is announced as:

  • Allow toggling password text visibility in password fields across the OS

I've noticed two inconsistencies here that probably aren't real bugs (at least not bugs concerning this feature), but just irritating things that mainly affect the "across th OS" part of the above feature description:

  1. In the server details of the mail account, the PW remains hidden. No way to unveil it. I suspect this page just doesn't use the component that was updated with 2.0.1, so it's the account UI that's problematic, not the new feature. Still, it should be checked by Jolla.
  2. In the server details of the XMPP account, when I unveil an existing password, it always shows the word "default". This is irritating and I don't know what the problem is here. Does Sailfish change the stored password once you enter this configuration page again? (So there is a bug, but not in the password field component.) Or is the stored password intact, but the password field doesn't show it properly but always displays the string "default"? (That would be a bug in the new component?) I don't know.

Have you noticed any other places in the UI where "toggling password text visibility in password fields" doesn't work as expected?

edit retag flag offensive reopen delete

The question has been closed for the following reason "the question is answered, an answer was accepted" by ossi1967
close date 2016-01-24 21:15:32.403163



I guess it's a protection against being able to reveal passwords. If your beloved Jolla phone gets in the hand of a not-that-trusty person it would be able to see the passwords for all your accounts.

IMO it should only be possible to make the password visible when you enter it and not when it was entered before.

Yo ( 2016-01-23 20:38:50 +0300 )edit

Yo: This is a valid assumption. In this case, though, the UI shouldn't display the 'abc'-toggle at all rather than providing a fake password when it's pressed.

In general, while I stress that your POV is valid in principle, I think it doesn't make much sense in every day use cases. When I change the password for an existing account on the server side and then take my Jolla to edit it there, why shouldn't I be able to see it as well? Another reasonable use case is to check for wrong passwords if things don't work as expected.

Anyway, the problem isn't how this new feature should be according to you and me. The issue is that right now, the implementation is so inconsistent that we don't know what Jolla wanted to do here and which part of the current implementation is buggy.

ossi1967 ( 2016-01-23 21:15:59 +0300 )edit

1 Answer

Sort by » oldest newest most voted

answered 2016-01-24 18:15:11 +0300

coderus gravatar image

Inside listed fields its technically not possible to read password. It stored encrypted forever, you can only overwrite it with a new one.

edit flag offensive delete publish link more



Thanks, @coderus, great piece of extra information. So the problem here is that the UI suggests that you could see and edit an existing password here, while in fact what you see is only dummy placeholders, right? And up to now, no-one really cared because no-one would actually edit "Mypass123" to "Yourpass456" seeing only the dots in the hidden password field. I'm sure everybody just deleted the field and typed the complete new password.

The way it's presented now has two issues:

  1. In case 1 (mail account), the password field is inconsistent with the rest of the OS. No way to reveal my input, even if I really want to change it. (Revealing it while I type a new one is the purpose of this new festure.)
  2. In case 2 (XMPP), it's even worse: The input field does reveal a string, but a wrong one. This shouldn't ever happen in the UI.

Thanks again for clarifying what happens here. I think Jolla will eventually have to re-think the UI logic here. (Like: When you open the server settings of an existing account, always show the password as empty, but having the possibility to unveil as you type. Or delete the PW field once it receives the focus. Whatever.) It's confusing the way it is now.

ossi1967 ( 2016-01-24 21:12:08 +0300 )edit

Question tools

1 follower


Asked: 2016-01-23 18:14:47 +0300

Seen: 525 times

Last updated: Jan 24 '16