### [Short version:] * differentiate between autosaved generated passwords and the rest of the cases that might generate an empty username entry * mitigate the accidental deletion of autosaved secure passwords due to the fact that users might not logout/login in order to update the changed password right away and it's possible that a blank username / password might be accidentally saved over the autosaved secure password - which is actually the new changed password. * improve the user experience while trying and failing the login with the original user/password. ### [Long version:] Taking into account the possible scenarios where the generated password is going to be used (pass_change, account creation) and also considering that Fx not always catches the right combination of u/p and also the fact that the management section allows creating empty usernames, QA would like to suggest that maybe using some obnoxious string like SECURE_AUTOSAVED_PASSWORD as username for the autosave would improve the user experience while using the generate feature. We think that having an explanatory username for the autosave will also aid into improving the situations in which, after password change, the user/password combination is the original one and the changed password is stored into the autosaved one. To exemplify: * Current user interaction: > 1. user credentials are saved: about:logins - 1 entry Myuser/MyPassword > 2. user changes password using pass generation: 2 entries 1. Myuser/MyPassword 2. "No username" / gen3rat3d_passw0rd > 3. the user logs out and accesses again the login form: autofill populates Myuser/MyPassword (since the no username is not considered a valid username) -> login fails * Proposed user interaction: > 1. user credentials are saved: about:logins - 1 entry Myuser/MyPassword > 2. user changes password using pass generation: 2 entries 1. Myuser/MyPassword 2. SECURE_AUTOSAVED_PASSWORD / gen3rat3d_passw0rd > 3. the user logs out and accesses again the login form: no autofill happens and the username will display two options: Myuser and SECURE_AUTOSAVED_PASSWORD, thus making it obvious to the user that in the case of the login failure, the generated password is there and therefore a bit easier to figure the fact that he needs to use the generated password and update the original login. ### [Note:] 1. This report encapsulates a few usability concerns related to password generation, and although, the good practice would dictate this bug would get split into several actionable items, we couldn't find a good way to just do that, at least not before the initial review and feedback. 2. We've decided to originally log this as a defect, rather than an enhancement due to the fact that we consider usability high priority
Bug 1570319 Comment 0 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
### [Short version:] * differentiate between autosaved generated passwords and the rest of the cases that might generate an empty username entry * mitigate the accidental deletion of autosaved secure passwords due to the fact that users might not logout/login in order to update the changed password right away and it's possible that a "No username" / password might be accidentally saved over the autosaved secure password - which is actually the new changed password. * improve the user experience while trying and failing the login with the original user/password. ### [Long version:] Taking into account the possible scenarios where the generated password is going to be used (pass_change, account creation) and also considering that Fx not always catches the right combination of u/p and also the fact that the management section allows creating empty usernames, QA would like to suggest that maybe using some obnoxious string like SECURE_AUTOSAVED_PASSWORD as username for the autosave would improve the user experience while using the generate feature. We think that having an explanatory username for the autosave will also aid into improving the situations in which, after password change, the user/password combination is the original one and the changed password is stored into the autosaved one. To exemplify: * Current user interaction: > 1. user credentials are saved: about:logins - 1 entry Myuser/MyPassword > 2. user changes password using pass generation: 2 entries 1. Myuser/MyPassword 2. "No username" / gen3rat3d_passw0rd > 3. the user logs out and accesses again the login form: autofill populates Myuser/MyPassword (since the no username is not considered a valid username) -> login fails * Proposed user interaction: > 1. user credentials are saved: about:logins - 1 entry Myuser/MyPassword > 2. user changes password using pass generation: 2 entries 1. Myuser/MyPassword 2. SECURE_AUTOSAVED_PASSWORD / gen3rat3d_passw0rd > 3. the user logs out and accesses again the login form: no autofill happens and the username will display two options: Myuser and SECURE_AUTOSAVED_PASSWORD, thus making it obvious to the user that in the case of the login failure, the generated password is there and therefore a bit easier to figure the fact that he needs to use the generated password and update the original login. ### [Note:] 1. This report encapsulates a few usability concerns related to password generation, and although, the good practice would dictate this bug would get split into several actionable items, we couldn't find a good way to just do that, at least not before the initial review and feedback. 2. We've decided to originally log this as a defect, rather than an enhancement due to the fact that we consider usability high priority
### [Short version:] * differentiate between autosaved generated passwords and the rest of the cases that might generate an empty username entry * mitigate the accidental deletion of autosaved secure passwords due to the fact that users might not logout/login in order to update the changed password right away and it's possible that a "No username" / password might be accidentally saved over the autosaved secure password - which is actually the new changed password. * improve the user experience while trying and filling the login with the original user/password. ### [Long version:] Taking into account the possible scenarios where the generated password is going to be used (pass_change, account creation) and also considering that Fx not always catches the right combination of u/p and also the fact that the management section allows creating empty usernames, QA would like to suggest that maybe using some obnoxious string like SECURE_AUTOSAVED_PASSWORD as username for the autosave would improve the user experience while using the generate feature. We think that having an explanatory username for the autosave will also aid into improving the situations in which, after password change, the user/password combination is the original one and the changed password is stored into the autosaved one. To exemplify: * Current user interaction: > 1. user credentials are saved: about:logins - 1 entry Myuser/MyPassword > 2. user changes password using pass generation: 2 entries 1. Myuser/MyPassword 2. "No username" / gen3rat3d_passw0rd > 3. the user logs out and accesses again the login form: autofill populates Myuser/MyPassword (since the no username is not considered a valid username) -> login fails * Proposed user interaction: > 1. user credentials are saved: about:logins - 1 entry Myuser/MyPassword > 2. user changes password using pass generation: 2 entries 1. Myuser/MyPassword 2. SECURE_AUTOSAVED_PASSWORD / gen3rat3d_passw0rd > 3. the user logs out and accesses again the login form: no autofill happens and the username will display two options: Myuser and SECURE_AUTOSAVED_PASSWORD, thus making it obvious to the user that in the case of the login failure, the generated password is there and therefore a bit easier to figure the fact that he needs to use the generated password and update the original login. ### [Note:] 1. This report encapsulates a few usability concerns related to password generation, and although, the good practice would dictate this bug would get split into several actionable items, we couldn't find a good way to just do that, at least not before the initial review and feedback. 2. We've decided to originally log this as a defect, rather than an enhancement due to the fact that we consider usability high priority