1548855 - Show in-content UI to save a password when a user edits a password field (before submission)

Status: NEW

(Toolkit :: Password Manager, enhancement, P3)

Description

[Matthew N. [:MattN]]

Currently we wait until we see a form "submission"[1] before showing a doorhanger to save/update a login but it will be hard to detect all times that we should offer to save as there are many different ways that applications with JavaScript can do their log in process (e.g. some combinations of window.location.href = "…", document.cookie = "…", XHR/fetch, location.reload(), <form>, etc. [see deps of bug 1119035). Since we will never cover 100% of the cases where we should prompt, we can reduce the impact of missing a capture signal by allowing the user to save before they even "submit" by providing an option in autocomplete or the context menu as soon as a password field is non-empty.

Safari already has this feature for password field edits.

Advantages over manual addition:

• Doesn't require re-typing or copying+pasting the username and password.
• Doesn't require the user to correctly identify the login frame's origin (e.g. if it doesn't match the top-level window's origin).
• Allows capturing other useful data about the form such as the formActionOrigin and other currently unused metadata such as the field IDs/names.

[1] Not necessarily a <form> 'submit' event but possibly just a navigation away or some other signal.

Comment 1

[Matthew N. [:MattN]]

Attachment: Screen Shot of Safari after clicking the key icon in a non-empty password field

Comment 2

[Matthew N. [:MattN]]

Ryan, can you decide between implementing this bug and/or bug 1536728 and provide UX designs for how it should work/look? Thanks

Comment 3

[rgaddis]

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.

Comment 4

[Matthew N. [:MattN]]

We decided not to add in-context UI to manually save for 70.