Chrome Version       : 57.0.2987.133
OS Version: 
URLs (if applicable) :
Other browsers tested:
  Add OK or FAIL after other browsers where you have tested this issue:
     Safari 5:
  Firefox 4.x:
     IE 7/8/9:


What steps will reproduce the problem?

1. Try to log into Schwab for the 87,429,095,333,897,885th time.
2. Schwab will tell you your account is locked and offer to reset your password.
3. Take them up on that offer, and wait a year for the reset email.
4. Open their email and click the link to the actual password reset form.
5. Chrome will suggest a new password, randomly generated. (Awesome!)
6. Once you submit the form, Chrome will offer to update your password for you.
6.a. WHILE Chrome is asking, you are redirected to the login page.
6.b. WHILE Chrome is asking, Chrome inserts your old password into the login form.
7. Accept the password change.
7.a. Chrome will add a new account with no username and this new password to your saved logins.
8. Refresh the page so Chrome repopulates the form with fresh data.
9. Press "log in" again, only to discover that the password is somehow still wrong.
10. Rinse, repeat.


What is the expected result?

It would be nice if Chrome's password manager could help me log into adversarially-secured websites, such as Schwab.com.


What happens instead of that?

All of my conscious effort ends up diverted to not flipping the table I'm sitting at, but Chrome needs more participation than that in order to successfully log in to this particular website (and others like it). In particular, this happens because Chrome enters a vicious cycle of creating and updating a dummy account with no username, while the data being entered in the form remains stale.


Please provide any additional information below. Attach a screenshot if
possible.

UserAgentString: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.133 Safari/537.36


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


So, the root of this problem is that Chrome doesn't seem to recognize a "change password" form, and instead treats it like logging into a new account with no username.
As a consequence, Chrome will auto-fill data that it has just rendered obsolete, while it moves to add the correct data to an incorrect location (or update more recent data in that incorrect location). This makes the age of the password being entered in the website at least one cycle old.


Here are some cool things Chrome could do:

1. Not save a password with no username when other usernames are known, or do as Firefox does, and always show the username and password (as editable fields) in the "Save this password?" prompt.

2. Offer the option of deleting passwords without making it a multi-phase ritual involving passwords.google.com. If it takes five seconds to ruin my life, it should take five seconds to fix my life. Maybe shift-delete, like in the omnibox.

3. Detect when stale data has been entered in a form, or just don't insert a password you're thinking about updating. This actually sounds a bit difficult and nuanced, in spite of how common-sense it appears in this particular use-case.



Another note: On banking websites, Chrome will occasionally mistake a PIN field for a password field and offer to ruin your life with it. I have no suggestions, there. Firefox does the same thing.

Another, other note: I think I found myself in this position by being forced to change my password in one browser, while it remained stale in the other (two Google accounts). Maybe synchronizing passwords between accounts could mitigate this problem, too. I use Firefox at home, though, so this could have been completely outside of Chrome's power to prevent.