This was observed on GNU/Linux with Chromium 52.0.2718.0 (Developer Build) (64-bit) and some older Chrome version (50?), but is likely platform-independent.

Looking at the password manager internals logs (attached), PasswordManager::Autofill executes, but it never reaches the renderer side.

Better format of the log attached.

Deleted: log 2.8 KB

log 2.8 KB View Download

Actually, taking back the claim about the renderer side not receiving anything. We apparently do not have logging inside PasswordAutofillAgent::OnFillPasswordForm. :(

I improved the logging in https://codereview.chromium.org/1918823005 and now it shows that PasswordAutofillAgent fails to find potential forms to fill. This is likely connected to the password field being added dynamically.

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

commit 4b06ffc533f2c176a235caa7ef0e0975b3c6f4c3
Author: vabr <vabr@chromium.org>
Date: Tue Apr 26 17:00:28 2016

Extend logging for password manager internals page

This CL adds logging for the internals page during filling passwords in the
renderer code. Those have been missing and would have been helpful for
investigating the associated bug.

BUG=606736

Review URL: https://codereview.chromium.org/1918823005

Cr-Commit-Position: refs/heads/master@{#389810}

[modify] https://crrev.com/4b06ffc533f2c176a235caa7ef0e0975b3c6f4c3/components/autofill/content/renderer/password_autofill_agent.cc
[modify] https://crrev.com/4b06ffc533f2c176a235caa7ef0e0975b3c6f4c3/components/autofill/core/common/save_password_progress_logger.cc
[modify] https://crrev.com/4b06ffc533f2c176a235caa7ef0e0975b3c6f4c3/components/autofill/core/common/save_password_progress_logger.h

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

commit 48c8ef0f7d7dccfbf818c289c771ca2ddaece9aa
Author: vabr <vabr@chromium.org>
Date: Wed Apr 27 13:38:06 2016

Password internals page logs names of filled elements

This adds a method to the renderer version of the password mangaer internals
logger to log form element names, and applies it to some code in
PasswordAutofillAgent.

The CL also fixes include guards in renderer_save_password_progress_logger.h

R=dvadym@chromium.org
BUG=606736

Review URL: https://codereview.chromium.org/1923283002

Cr-Commit-Position: refs/heads/master@{#390059}

[modify] https://crrev.com/48c8ef0f7d7dccfbf818c289c771ca2ddaece9aa/components/autofill/content/renderer/password_autofill_agent.cc
[modify] https://crrev.com/48c8ef0f7d7dccfbf818c289c771ca2ddaece9aa/components/autofill/content/renderer/renderer_save_password_progress_logger.cc
[modify] https://crrev.com/48c8ef0f7d7dccfbf818c289c771ca2ddaece9aa/components/autofill/content/renderer/renderer_save_password_progress_logger.h
[modify] https://crrev.com/48c8ef0f7d7dccfbf818c289c771ca2ddaece9aa/components/autofill/core/common/save_password_progress_logger.cc

At this point, it is possible to fill password. Username should be filled manually.

Partially fixed.

Just tried - doesn't propose to enter password.

I was testing this with Version 57.0.2987.133 (64-bit). Perhaps it was fixed in ToT...

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

commit 4afdcc3b649fd9e056ccfe078890c39419e62d08
Author: pkalinnikov <pkalinnikov@chromium.org>
Date: Tue May 30 09:51:14 2017

Add username field discovery heuristic.

There are some cases when autofill can't find a username field for
autocompletion. For example, if the field is created dynamically in JavaScript.
This CL introduces a heuristic which is used as a fallback in such cases to
find a username field.

When password form autocompletion is about to happen with unknown username
field, the heuristic searches for the closest visible autocompletable
non-password text element preceding the password element. If one found, it is
believed to be the username field.

BUG= 710374 ,606736, 586465 ,710003

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

[modify] https://crrev.com/4afdcc3b649fd9e056ccfe078890c39419e62d08/chrome/renderer/autofill/password_autofill_agent_browsertest.cc
[modify] https://crrev.com/4afdcc3b649fd9e056ccfe078890c39419e62d08/components/autofill/content/renderer/password_autofill_agent.cc
[modify] https://crrev.com/4afdcc3b649fd9e056ccfe078890c39419e62d08/components/autofill/content/renderer/password_autofill_agent.h

After https://codereview.chromium.org/2889393002 this issue seems to be solved. The username field gets autofilled together with the password field when the user interacts with the latter.

Awesome!

There is one more possible improvement here. Still, when the user interacts with the *username* field, they don't get suggestions drop-down. It would be nice to have this fallback when clicking on a "suspicious" username field (determined by the same heuristic as on clicking the password field).

Another thing is autofilling u/p straight on navigation. But I don't think we should do it for sites like this, because there is a risk to incorrectly detect a username field. It's better to leave this as a fallback, when the user has more context and really intent to autofill the form.

Reopening the bug for the sake of the first improvement.

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

commit 525e06d30faf3fdbfb85e2b0e1e7c0c1bdc031e5
Author: Pavel Kalinnikov <pkalinnikov@chromium.org>
Date: Wed May 31 13:49:43 2017

Add username field discovery heuristic.

There are some cases when autofill can't find a username field for
autocompletion. For example, if the field is created dynamically in JavaScript.
This CL introduces a heuristic which is used as a fallback in such cases to
find a username field.

When password form autocompletion is about to happen with unknown username
field, the heuristic searches for the closest visible autocompletable
non-password text element preceding the password element. If one found, it is
believed to be the username field.

BUG= 710374 ,606736, 586465 ,710003

Review-Url: https://codereview.chromium.org/2889393002
Cr-Original-Commit-Position: refs/heads/master@{#475481}
Review-Url: https://codereview.chromium.org/2918543002 .
Cr-Commit-Position: refs/branch-heads/3112@{#52}
Cr-Branched-From: b6460e24cf59f429d69de255538d0fc7a425ccf9-refs/heads/master@{#474897}

[modify] https://crrev.com/525e06d30faf3fdbfb85e2b0e1e7c0c1bdc031e5/chrome/renderer/autofill/password_autofill_agent_browsertest.cc
[modify] https://crrev.com/525e06d30faf3fdbfb85e2b0e1e7c0c1bdc031e5/components/autofill/content/renderer/password_autofill_agent.cc
[modify] https://crrev.com/525e06d30faf3fdbfb85e2b0e1e7c0c1bdc031e5/components/autofill/content/renderer/password_autofill_agent.h

Isn't fix in stable yet? If so, we should probably close the issue as fixed, shouldn't we?

Actually, just tested this and looks like this isn't working in stable yet. I get auto-completion for the password, but not for the username.

And it looks like this CL is in stable: https://chromiumdash.appspot.com/commit/4afdcc3b649fd9e056ccfe078890c39419e62d08, so it appears like heuristic doesn't work for the site.

The problem here is that there are 3 text fields without id or name attributes (which is used for identifiers), and Password Manager can't distinguish them.

There is a mechanism for dealing with fields without identifiers, but it's supposed that both username and password fields don't have identifiers, but here the password field has valid identifier. 

A minimal example for reproducing this is

<form>
<input type="text">    /// <- no id or name
<input type="password" id="pw">
</form>

vabr going hobby only -> reducing involvement.
Please contact me directly in urgent matters.