Password fields are tied, dangerous behavior

Locker

1PW 4.4.3

MacOS 10.9.5

I defined a field in a section of a login item, called in PIN and set it up as password type.

username: NAME password: PWD1 ... ... Section label ABC PIN nnnn ... ... ... show web form details: abc_username NAME abc_password PWD1

If I then go and delete the content of password:
username: NAME password: <--- deleted ... ... Section label ABC PIN nnnn ...

and save it, that empty field is replaced by the contend of the PIN field!!!

username: NAME password: nnnn <--- The content of PIN shows up here!!! ... ... Section label ABC PIN nnnn <-- copied incorrectly from here ... ... ... show web form details: abc_username NAME abc_password <--- here it is indeed empty

Although probably the internal content of the (first) password field is probably empty, even the 'Password Strength' evaluates the content that is the same as the content of field PIN.

If I delete the content of PIN, it also go away from the (first) password field, and 'Password Strength' indeed disappear proper behavior for an empty password field).

Megan

Hi @Locker,

Thanks for providing such a detailed outline of your process here! Based on your steps I was able to re-create this behaviour, and you're right, it certainly doesn't seem correct. I've filed a report in our internal issue tracker. We'll do what we can to improve 1Password's behaviour here.

ref: OPM-2406

MrC

FYI - this will also occur if you delete a line from the Web Form Details area. Delete the Password line there, and your Password entry is now gone.

sjk

I'm not sure that's a bug, @MrC.

When web form fields designated as username (with the head icon) and password (with the key icon) are removed from a Login item, or have the designation disabled, the corresponding main username and password fields will also be removed. Example:

In Edit mode:

If there was a custom field with a Password type in that item, its value would be displayed in the main password field (which is the bug @Locker reported).

MrC

I don't think its so clear. I've already made the mistake once. There's no other behavior in 1P4 where you can delete something from row X and some other row Y gets deleted. While you know what it means, and you know that the two rows are linked, there's no reason why anyone else should expect this behavior. If I just want to disable username from autofill, for example, I would just try to delete the username Web form details and expect only the Web forum details aspect to be edited (hence, no more autofill for that field). I think it is entirely counter-intuitive, and destructive to say the least, to have the entry's username removed - I didn't touch the field. If they are linked, there needs to be some UI element that shows the linkage, so a user can see the loss that can occur. And since the only way to resolve the issue is to restore from a backup, its even more problematic.

sjk

I hear ya, @MrC.

The linkage between username and password fields in the built-in top section and their corresponding web form fields isn't obvious. No help that the former aren't dynamically updated while modifying the latter in Edit mode, and vice versa. I already filed an improvement request for that awhile back, which I'll change to a bug and include your comments from here there. Or would you prefer I filed a separate bug report?

ref: OPM-1729

MrC

Thanks. Whatever you think is best.

sjk

Thank you, @MrC. I've added your concerns about this field linkage to the previous improvement request, now turned into a bug report. Even though this type of linked field modification behaves as intended its current lack of feedback adds an unwanted element of unexpected data loss.