Bug 1548855 Comment 3 Edit History

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

Notes from a conversation with MattN on this effort:

It’d be nice to only ask about saving to logins once the task of creating an account has fully been completed (ensures we capture correct data, and doesn’t force the user to context switch in the middle of a task). 

Step 1: Add a disclaimer to the pw generation prompt and plan to automatically save logins that contain suggested passwords

Step 2: We should proactively save the password at time of generation & fill, but re-actively save the username at time of submission (to ensure we have captured the correct username in instances where it has to be updated based on server errors)
	
Outcome #1: If a username is found and can be associated with the suggested password, and it does not conflict with any other logins with a matching username, save the login automatically and display the "login saved" confirmation upon form submission

Outcome #2: If a username is not able to be associated with the suggested password, present a door hanger with an empty username field upon form submission, so a user can update the username (behind the scenes, we'll still save login with no username, even if this doorhanger is dismissed)

Outcome #3: If an associated username matches a previously saved login, we choose to save a new login with an empty username, so as to ensure preservation of the newly generated password… upon form submission, we attempt to present a doorhanger, with the empty username to allow user to update username. If the entered username matches a previously saved login, we change the action of the doorhanger to "Update Login" and replace the old login details with the newly created login (and update metadata accordingly). There is a chance that the new login could be duplicative of a login with an empty username, and in this instance, we may consider the same flow, but display the "Update" doorhanger, knowing that they may override the login if they choose to not add a unique username to the field. 

Considerations: We may need to update the door hanger language to support appropriate requests in the description, as well as corresponding primary and secondary actions for the various outcomes.
Notes from a conversation with MattN on this effort:

Step 1: Add a disclaimer to the pw generation prompt and plan to automatically save logins that contain suggested passwords

Step 2: We should proactively save the password at time of generation & fill, but re-actively save the username at time of submission (to ensure we have captured the correct username in instances where it has to be updated based on server errors)
	
Outcome #1: If a username is found and can be associated with the suggested password, and it does not conflict with any other logins with a matching username, save the login automatically and display the "login saved" confirmation upon form submission

Outcome #2: If a username is not able to be associated with the suggested password, present a door hanger with an empty username field upon form submission, so a user can update the username (behind the scenes, we'll still save login with no username, even if this doorhanger is dismissed)

Outcome #3: If an associated username matches a previously saved login, we choose to save a new login with an empty username, so as to ensure preservation of the newly generated password… upon form submission, we attempt to present a doorhanger, with the empty username to allow user to update username. If the entered username matches a previously saved login, we change the action of the doorhanger to "Update Login" and replace the old login details with the newly created login (and update metadata accordingly). There is a chance that the new login could be duplicative of a login with an empty username, and in this instance, we may consider the same flow, but display the "Update" doorhanger, knowing that they may override the login if they choose to not add a unique username to the field. 

Considerations: We may need to update the door hanger language to support appropriate requests in the description, as well as corresponding primary and secondary actions for the various outcomes.

Back to Bug 1548855 Comment 3