aseda.aboagye@Could you please provide test credentials to sign into automatic.com and check the issue?

Thanks in advance.

Thanks for the report! I can reproduce the issue with Chrome 53.0.2767.0 (Developer Build) (64-bit) on GNU/Linux.

Looking at the chrome://password-manager-internals logs (full logs below), the bug seems to be that Chrome fails to see the password form when it calls FindFormElements in PasswordAutofillAgent::GetFillableElementFromFormData. I am sending this issue to the team's TODO queue.

Also thanks for sharing the test credentials as requested in #2. However, they are not needed for reproduction in this case, developers can use the chrome://flags/#enable-password-force-saving flag to enable manual saving and test with that. I will update our testing team on these alternatives so that we don't ask reporting users to provide the test accounts in the future. I will also delete your comment #2 to limit the public exposure of your testing credentials and make this bug publicly accessible again.


Message: PasswordAutofillAgent::SendPasswordForms 
only_visible: false
Security origin: https://dashboard.automatic.com/ 
Number of all forms: 1
Form is a password form: {
Action : https://dashboard.automatic.com/ ,
New password element : ,
Origin : https://dashboard.automatic.com/ ,
PSL match : false,
Password element : anonymous_password ,
Password generated : false,
SSL valid : false,
Scheme : HTML ,
Signon realm : https://dashboard.automatic.com/ ,
Times used : 0,
Username element : anonymous_username 
}
Message: PasswordManager::CreatePendingLoginManagers 
SSL errors present: false
IsPasswordManagementEnabledForCurrentPage: true
Number of pending login managers (before): 0
Adding manager for form with this signature: {
: 1067852723 ,
Signature of form, followed by field signatures : 6112762768010774695 
}
Message: PasswordFormManager::FetchMatchingLoginsFromPasswordStore 
PasswordFormManager::state_: 0
Number of pending login managers (after): 1
Message: PasswordFormManager::OnGetPasswordStoreResults 
Number of results from the password store: 1
Message: PasswordFormManager::OnRequestDone 
SSL errors present: false
IsPasswordManagementEnabledForCurrentPage: true
Message: PasswordManager::Autofill 
wait_for_username: false
The new state of the UI: 3
Message: PasswordAutofillAgent::OnFillPasswordForm 
ambiguous_or_empty_names: true
Number of potential forms to fill: 0
form_data's wait_for_username: false

Making public again, because the sensitive data has been deleted as described in #4.

Thanks so much. Yeah, I realized I also reproduced it on Chrome on Chrome OS.

PasswordAutofillAgent refuses to autofill. The elements in the form have neither "id" nor "name".

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/78408cfeaad0b8657041a0e6b75df24e93229924

commit 78408cfeaad0b8657041a0e6b75df24e93229924
Author: dvadym <dvadym@chromium.org>
Date: Thu Dec 15 17:45:21 2016

Password Manager: skip non-text fields from consideration for filling.

BUG= 619345 

Review-Url: https://codereview.chromium.org/2583493003
Cr-Commit-Position: refs/heads/master@{#438868}

[modify] https://crrev.com/78408cfeaad0b8657041a0e6b75df24e93229924/chrome/test/data/password/ambiguous_password_form.html
[modify] https://crrev.com/78408cfeaad0b8657041a0e6b75df24e93229924/components/autofill/content/renderer/password_autofill_agent.cc