Suggest to fill password change forms

components/autofill/content/renderer/password_autofill_agent.cc

 // Copyright 2013 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #include "components/autofill/content/renderer/password_autofill_agent.h"
 
 #include "base/bind.h"
 #include "base/command_line.h"
 #include "base/memory/scoped_ptr.h"
 #include "base/message_loop/message_loop.h"
@@ skipping 840 matching lines @@
   if (!IsElementAutocompletable(element) ||
       !IsElementAutocompletable(password_info->password_field))
     return true;
 
   bool username_is_available =
       !username_element->isNull() && IsElementEditable(*username_element);
   // If the element is a password field, a popup should only be shown if there
   // is no username or the corresponding username element is not editable since
   // it is only in that case that the username element does not have a
   // suggestions popup.
-  if (element.isPasswordField() && username_is_available)
+  if (element.isPasswordField() &&
+      !password_info->fill_data.is_password_change_form &&

[Garrett Casto, 2015/06/09 23:56:22]

The more that I think about this, the more that I'm not sure that this is the
right thing to do. This will make it such that for most signup forms we will now
trigger the password manager on both the username and password fields, where
before hand we would show UI on neither.

I do want filling to work on Facebook, but I'm not sure if this is the right
approach. Maybe instead we only show UI on password fields if the username field
hasn't been focused. What do you think?

[dvadym, 2015/06/10 14:22:03]

Yeah, I'm also not sure that this is the best approach. We will show suggestions
more often that it's required. 
Your solution definitely helps to fix it and also it fixes facebook and it's
easy to implement. The only thing I see that in your solution the user will have
the problem when we incorrectly detect username field and the user click on it,
so he will no be able to fill password. But it seems to be minor problem, what
do you think?

[Garrett Casto, 2015/06/11 00:07:36]

That is true. It is already a problem we could have for login forms, and one
that we are trying to solve in general anyway. I would also think that it's not
a big problem for change password forms since when they have a text field that
could be the username it's pretty rare that it's something unrelated. Have you
noticed instances where this would be problematic?

[dvadym, 2015/06/11 12:00:53]

No, I didn't notice any sites where it can be a problem on change forms. I've
implemented your proposition, i.e. not to show suggestions on password field if
the username field was in focus. Please review these changes

+      username_is_available)
     return true;
 
   // Chrome should never show more than one account for a password element since
   // this implies that the username element cannot be modified. Thus even if
   // |show_all| is true, check if the element in question is a password element
   // for the call to ShowSuggestionPopup.
   return ShowSuggestionPopup(
       password_info->fill_data,
       username_element->isNull() ? element : *username_element,
       show_all && !element.isPasswordField(), element.isPasswordField());
@@ skipping 600 matching lines @@
 void PasswordAutofillAgent::LegacyPasswordAutofillAgent::DidStopLoading() {
   agent_->DidStopLoading();
 }
 
 void PasswordAutofillAgent::LegacyPasswordAutofillAgent::
     DidStartProvisionalLoad(blink::WebLocalFrame* navigated_frame) {
   agent_->LegacyDidStartProvisionalLoad(navigated_frame);
 }
 
 }  // namespace autofill