Bugzilla

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 showing a dismissed doorhanger as soon as a password (or username?) field is edited.

Chrome Beta 73 already seems to have this feature for password field edits. You can test with attachment 8880688 [details]. As soon as you edit the password field, the key icon appears (the panel doesn't open automatically at that point).

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.

Potential issues:
* Don't make it too easy for others to see the plaintext password in the doorhanger. We already avoid the toggle when a Master Password is set for the security conscious. Should the icon persist for the same duration even without a capture signal (i.e. across origin navigations).
* Having the icon appear in its usual icon on the left would cause a shift of the identity block and URL, potentially a bit distracting. Chrome doesn't have this problem since it's on the right side of the URL bar.

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

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 showing a dismissed doorhanger as soon as a password (or username?) field is edited.

Chrome Beta 73 already seems to have this feature for password field edits. You can test with attachment 8880688 [details]. As soon as you edit the password field, the key icon appears (the panel doesn't open automatically at that point).

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.

Potential issues:
* Don't make it too easy for others to see the plaintext password in the doorhanger. We already avoid the toggle when a Master Password is set for the security conscious. Should the icon persist for the same duration even without a capture signal (i.e. across origin navigations).
* Having the icon appear in its usual icon on the left would cause a shift of the identity block and URL, potentially a bit distracting. Chrome doesn't have this problem since it's on the right side of the URL bar.
* We probably should not show the doorhanger toggle for edits to autofilled passwords since that makes them too easily revealed to users. We should check how Chrome handles this. We could either not show the doorhanger when it was autofilled previously (we already have that some of that state) or we should hide the checkbox in that case.

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