Bug 1585398 Comment 4 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

(In reply to Sam Foster [:sfoster] (he/him) from comment #3)
 
> But autocomplete is the primary mechanism for selecting and filling fields with saved logins. 

From the technical point makes sense, I am just pointing that it might be weird for users to reach the point where they get to use a current password(merged) to change the current password(populated before the merge), before actually changing the current password(site) :). - take in account that users need to figure the "No username" entry, which then poofs away when merged.

> > Also, real edgy case, but it might be possible with this bug and bug 1584185 to reach a point mid password change where your current password, new password and re-entry password to be different from the expected values.
> 
> If you have STR for that, lets open a new bug.

A new bug would just be a dupe after bug 1584185, since it's the same root cause, with just a slight variation introduced by the fact that you can have a new generated password when updating and this particular variation will be already mostly handled in fx71 by fixing bug 1576490.

Just to make clear my standing point, having multiple generated passwords is something I think we must have 71+, but Fx70 scope doesn't cover bug 1551723 and bug 1569568, which would make this bug a regression in terms of Fx70 and probably part of the feature in Fx71. Functionally, if this bug is fixed for Fx70 (we do not remove generated-password cache entry for origin when merging), it might result into a stale "No username" entry in case the user chooses to generate again in the same session/principal + the risk that the user uses the secure password for multiple logins, which would not be "secure". 

In regards to Fx70, time is ticking away, so I think we need a decision here. 
I marked this issue as critical from the point of view that this bug might introduce further confusion in Fx70 to an user who already has to cruise through understanding the empty auto-saved password and hitting possible edge cases, in which expected result is not always intuitive and my standing quality point of view is that we need the work flow to be predictable and intuitive in general, but more so in regards to a password manager auto-generation, all in order to gain and retain an user's trust .
(In reply to Sam Foster [:sfoster] (he/him) from comment #3)
 
> But autocomplete is the primary mechanism for selecting and filling fields with saved logins. 

From the technical point makes sense, I am just pointing that it might be weird for users to reach the point where they get to use a current password(merged) to change the current password(populated before the merge), before actually changing the current password(site) :). - take in account that users need to figure the "No username" entry, which then poofs away when merged.

> > Also, real edgy case, but it might be possible with this bug and bug 1584185 to reach a point mid password change where your current password, new password and re-entry password to be different from the expected values.
> 
> If you have STR for that, lets open a new bug.

A new bug would just be a dupe after bug 1584185, since it's the same root cause, with just a slight variation introduced by the fact that you can have a new generated password when updating and this particular variation will be already mostly handled in fx71 by fixing bug 1576490.

Just to make clear my standing point, having multiple generated passwords is something I think we must have 71+, but Fx70 scope doesn't cover bug 1551723 and bug 1569568, which would make this bug a regression in terms of Fx70 and probably part of the feature in Fx71. Functionally, if this bug is fixed for Fx70 (we do not remove generated-password cache entry for origin when merging), it might result into a stale "No username" entry in case the user chooses to generate again in the same session/principal + the risk that the user uses the secure password for multiple logins, which would not be "secure". 

I marked this issue as critical from the point of view that this bug might introduce further confusion in Fx70 to an user who already has to cruise through understanding the empty auto-saved password and hitting possible edge cases, in which expected result is not always intuitive and my standing quality point of view is that we need the work flow to be predictable and intuitive in general, but more so in regards to a password manager auto-generation, all in order to gain and retain an user's trust .

In regards to Fx70, time is ticking away, so I think we need a decision here.

Back to Bug 1585398 Comment 4