Save password functionality added to the save password bubble

chrome/browser/password_manager/password_form_manager.h

 // Copyright (c) 2012 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.
 
 #ifndef CHROME_BROWSER_PASSWORD_MANAGER_PASSWORD_FORM_MANAGER_H_
 #define CHROME_BROWSER_PASSWORD_MANAGER_PASSWORD_FORM_MANAGER_H_
 
 #include <string>
 #include <vector>
 
@@ skipping 53 matching lines @@
   // conceivable that a user (or ui test) could attempt to submit a login
   // prompt before the callback has occured, which would InvokeLater a call to
   // PasswordManager::ProvisionallySave, which would interact with this object
   // before the db has had time to answer with matching password entries.
   // This is intended to be a one-time check; if the return value is false the
   // expectation is caller will give up. This clearly won't work if you put it
   // in a loop and wait for matching to complete; you're (supposed to be) on
   // the same thread!
   bool HasCompletedMatching();
 
+  // Save password according to current password_form. If the user has chosen

[Garrett Casto, 2013/08/27 00:52:24]

I'm not sure that I understand the need for these changes. Shouldn't this use
the same code the InfoBar is currently using (Save() to save and
PermanentlyDelete() to blacklist)? Is there a reason why the functionality
should be different?

[npentrel, 2013/08/27 16:35:11]

Yes, the functionality needs to be slightly different as we now allow for the
user to click on the icon again and change the choice the user previously made.
Hence the user can save a password, then click on the icon again and blacklist
it.

But you are right, there is no need for DeleteSavedPassword.

On 2013/08/27 00:52:24, Garrett Casto wrote:

[Garrett Casto, 2013/08/28 00:08:33]

In that case, shouldn't we just wait until navigation has occurred (and the icon
has disappeared) before committing their decision to the database? Actually
trying to save both if the user clicks back and forth seems more complicated
than it has to be. For instance, if the user clicked blacklist and then save you
would need to remove the blacklist credential during saving, which we currently
don't do. 

[npentrel, 2013/08/28 08:48:44]

We have the following two cases:

1. User saves password -> user blacklists password
In this case we don't have to change anything.

2. User blacklists password -> user saves password
In this case all we need to do is (re)set
pending_credentials_.blacklisted_by_user to false. This will take the saved
password off the blacklisted password list.

Hence, I believe that this change is easier and smaller than implementing a way
to listen for the icon to disappear on the next navigation. If we did this, I am
also not sure whether closing the tab would be understood as a navigation in
order for the password to be saved in the case that someone logs in, saves the
password, and closes the tab before the icon disappears. 

We should also consider that the icon is displayed on some pages until the user
logs out, in the case that the browser crashed during that time period, the
password would also not be saved. We can circumvent this by saving
it/blacklisting it on click.


On 2013/08/28 00:08:33, Garrett Casto wrote:

+  // to blacklist the password previously this will undo this action and save
+  // the password.
+  void SavePassword();
+
+  // Delete saved password according to current password_form.
+  void DeleteSavedPassword();
+
   // Determines if the user opted to 'never remember' passwords for this form.
   bool IsBlacklisted();
 
   // Used by PasswordManager to determine whether or not to display
   // a SavePasswordBar when given the green light to save the PasswordForm
   // managed by this.
   bool IsNewLogin();
 
   // Returns true if the current pending credentials were found using
   // origin matching of the public suffix, instead of the signon realm of the
@@ skipping 204 matching lines @@
   // These three fields record the "ActionsTaken" by the browser and
   // the user with this form, and the result. They are combined and
   // recorded in UMA when the manager is destroyed.
   ManagerAction manager_action_;
   UserAction user_action_;
   SubmitResult submit_result_;
 
   DISALLOW_COPY_AND_ASSIGN(PasswordFormManager);
 };
 #endif  // CHROME_BROWSER_PASSWORD_MANAGER_PASSWORD_FORM_MANAGER_H_