Version: Any recent version, tested with 54
OS: Anything but iOS (did not check there, but the code is different)

What steps will reproduce the problem?
(1) Stage the attached readonly.html on a webserver, navigate to it.
(2) Fill the first form with a non-empty username, submit, save the password.
(3) Navigate back to readonly.html, click on the second password field, accept the offer to fill it with the saved password.

What is the expected output?
The password value is filled.

What do you see instead?
Nothing is filled.

Notes:

* The issue is with the second form having a readonly username. That results in PasswordAutofillAgent::FillSuggestion failing the check IsElementAutocompletable(username_element).

* The above is a toy example, a real-world example is, e.g., accounts.google.com:
  (1') Use a profile where the user is not signed in to Chrome.
  (2') Log in on accounts.google.com with a gmail.com address, but leave out the @gmail.com part. Save the password.
  (3') Sign out and go back to accounts.google.com.
  After step (3') there will be a readonly field with the canonical form of the Google username, including the @gmail.com part. But the password field will not be autofilled (because the saved username does not match the canonical one), and the manual filling won't work either (because the username is readonly).

* The intention of the "use password for" pop-up in the password field is to override bad guessing on Chrome's side. On the example of accounts.google.com, one can see that Chrome will autofill if the stored username is matching its canonical form, i.e., if it is the same as the readonly value. But even then it won't fill on demand, which is clearly inconsistent.

We should drop the requirement for the username to be autocompletable in the case when the user triggered manual filling from the password field.
 

Deleted: readonly.html 718 bytes

readonly.html 718 bytes View Download