+some privacy folks, and flipping labels.

s/RVST/RVG/ just in case.

Oops, this is a bug, and I can also reproduce on Linux. Thankfully it is not the case on every website (e.g., rsolomakhin.github.io/autofill/ works fine), but still a bug.

Looking into it.

PasswordAutofillAgent::TextFieldDidEndEditing feels the need to fill the current password field in cases when the "don't autofill" flag is on. This causes the observed bug.

I'm looking further into the code to understand why PasswordAutofillAgent::TextFieldDidEndEditing behaves in this way.

The code there is to allow filling after the user typed the username without actually selecting suggestions. It is unclear why this only happens in the case when Chrome decides against autofilling. The behaviour has been there since porting from WebKit in 2010 https://chromium.googlesource.com/chromium/src/+/03f57072cd19125c59fbc1d7c76f2856ca200850.

It is unclear what this behaviour's benefits are. It even seems like contraproductive in cases when the user tries to type in their username without using suggestions to prevent autofilling. Getting rid of this code would make PasswordAutofillAgent simpler again, in addition to fixing this bug. I spoke to dvadym@, and it looks like a good idea to us to remove the code. I will give heads-up about this on today's team meeting as well.

Able to reproduce the issue with https://whytls.com/password.htm on mac win and Linux using chrome version 52.0.2743.116 and canary 54.0.2826.0

This is working fine with rsolomakhin.github.io/autofill/

Uploaded https://codereview.chromium.org/2236413002, waiting for bots to turn green before sending out for review.

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

commit 36c4ef576660b52e1a5750b313ae3031ea1b4e81
Author: vabr <vabr@chromium.org>
Date: Thu Aug 11 15:22:50 2016

Remove PasswordAutofillAgent::TextFieldDidEndEditing

PasswordAutofillAgent::TextFieldDidEndEditing provided special handling for
situations when automatic filling was blocked (Incognito, PSL-matched
credentials, etc.): in those cases, when the user filled the username to match
some of the fillable credentials, that credential was filled even though the
user did not select a fill suggestion.

It is no longer clear what was the motivation for this behaviour. The code has
been like this before it was ported from WebKit in 2010. It seems unnecessary,
a little unexpected, and leads to a bug when a page can trigger autofill of
credentials with empty usernames in cases where they should not be autofilled
(e.g., Incognito).

Therefore, this CL removes PasswordAutofillAgent::TextFieldDidEndEditing and
the associated functionality: credentials are now only filled when the user
selects a suggestion (or when the credentials are fit for automatic filling).

R=dvadym@chromium.org
BUG= 636461 

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

[modify] https://crrev.com/36c4ef576660b52e1a5750b313ae3031ea1b4e81/chrome/renderer/autofill/password_autofill_agent_browsertest.cc
[modify] https://crrev.com/36c4ef576660b52e1a5750b313ae3031ea1b4e81/components/autofill/content/renderer/autofill_agent.cc
[modify] https://crrev.com/36c4ef576660b52e1a5750b313ae3031ea1b4e81/components/autofill/content/renderer/password_autofill_agent.cc
[modify] https://crrev.com/36c4ef576660b52e1a5750b313ae3031ea1b4e81/components/autofill/content/renderer/password_autofill_agent.h

elawrence@, can we lift the view restriction?

Sure, done.