Add Password Autofill Manager to New Autofill

chrome/browser/autofill/password_autofill_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_AUTOFILL_PASSWORD_AUTOFILL_MANAGER_H_
+#define CHROME_BROWSER_AUTOFILL_PASSWORD_AUTOFILL_MANAGER_H_
+#pragma once
+
+// This file was contains some repeated code from
+// chrome/renderer/autofill/password_autofill_manager because as we move to the
+// new Autofill UI we needs these functions in both the browser and renderer.
+// Once the move is completed the repeated code in the renderer half should be
+// removed.
+// http://crbug.com/51644
+
+#include <map>
+
+#include "webkit/forms/password_form_dom_manager.h"
+
+namespace content {
+class RenderViewHost;
+}  // namespace content
+
+// This class is responsible for filling password forms.
+class PasswordAutofillManager {
+ public:
+  explicit PasswordAutofillManager(content::RenderViewHost* render_view_host);
+  virtual ~PasswordAutofillManager();
+
+  // If this return true, it indicates the event would be consumed by the
+  // password manager in the renderer, so we shouldn't attempt to handle the
+  // key down, but instead pass it to the renderer.
+  bool WouldHandleKeyDown(const webkit::forms::FormField& field);

[Ilya Sherman, 2012/03/15 18:27:41]

I still don't understand why this method will be necessary once the keyboard
handling code lands.  If you still want to keep this in this CL, I'll prefer to
hold off on the final L G T M until the other CL lands.  (Will take a look at
that in a moment, though I'm probably not the best reviewer for it.)

[csharp, 2012/03/16 20:21:12]

I wanted to keep this method to make sure that the normal Autofill manager
didn't steal a key press that password manager would have handled (since the
browser Autofill manager will go before the renderer Password Manager).

The only key press that the password manager cares about though is backspace,
which currently the browser Autofill won't take. I'll take this code out but
I'll add a warning to the renderer keypress handler letting it know that the
browser autofill code could eat inputs it wants in the future.

+
+  // Fills the password associated with user name |value|. Returns true if the
+  // username and password fields were filled, false otherwise.
+  bool DidAcceptAutofillSuggestion(const webkit::forms::FormField& field,
+                                   const string16& value);
+
+  // A no-op.  No filling happens for selection.  But this method returns
+  // true when |node| is fillable by password Autofill.
+  bool DidSelectAutofillSuggestion(const webkit::forms::FormField& field);
+
+  // A no-op.  Password forms are not previewed, so they do not need to be
+  // cleared when the selection changes.  However, this method returns
+  // true when |node| is fillable by password Autofill.
+  bool DidClearAutofillSelection(const webkit::forms::FormField& field);
+
+  // Invoked when a password form is filled.

[Ilya Sherman, 2012/03/15 18:27:41]

nit: Please update this comment.

[csharp, 2012/03/16 20:21:12]

Done.

+  void AddPasswordFormMapping(
+      const webkit::forms::FormField& username_element,
+      const webkit::forms::PasswordFormFillData& password);
+
+  // Invoked when to clear any page specific cached values.

[Ilya Sherman, 2012/03/15 18:27:41]

nit: "when to clear" -> "to clear"?

[csharp, 2012/03/16 20:21:12]

Done.

+  void Reset();
+
+ private:
+  typedef std::map<webkit::forms::FormField,
+                   webkit::forms::PasswordFormFillData>
+      LoginToPasswordInfoMap;

[Ilya Sherman, 2012/03/15 18:27:41]

If I'm understanding correctly, we could remove this map from the browser-side
if we could distinguish a _password autofill_ suggestion from an _autocomplete_
suggestion based on something like the _unique id_, as we do for distinguishing
_autocomplete_ vs. _autofill_ suggestions.  If so, please add a TODO and file a
bug to do that -- it would make this code much simpler.

[csharp, 2012/03/16 20:21:12]

I think you're right. I think there might be 1 tough spot to deal with but I can
remove most of the mapping code (I think). Added a todo and filled a bug.

[Ilya Sherman, 2012/03/20 00:58:55]

I'd recommend not having the mixed strategy of unique_id for some things and the
map for other things.  I'd recommend just using the map for now; and switching
to something like the unique_id strategy when we completely deprecate the WebKit
popup UI.

[Ilya Sherman, 2012/03/22 01:20:06]

Bump.

[csharp, 2012/03/29 16:28:17]

Just using the map now. Had to add the field to one of the password ipc calls,
since it wasn't getting set the normal way so the field value I was comparing to
the map was garbage, which is why I was having trouble.

+
+  bool WillFillUserNameAndPassword(
+      const webkit::forms::FormField& username_element,
+      const webkit::forms::PasswordFormFillData& password);
+
+  // Finds login information for a |node| that was previously filled.
+  bool FindLoginInfo(const webkit::forms::FormField& field,
+                     webkit::forms::FormField* found_input,
+                     webkit::forms::PasswordFormFillData* found_password);
+
+  // The logins we have filled so far with their associated info.
+  LoginToPasswordInfoMap login_to_password_info_;
+
+  content::RenderViewHost* render_view_host_;  // Weak reference.
+
+  DISALLOW_COPY_AND_ASSIGN(PasswordAutofillManager);
+};
+
+#endif  // CHROME_BROWSER_AUTOFILL_PASSWORD_AUTOFILL_MANAGER_H_