commit 97d5edfdafe0505056f2174f854e1b7176893fdb
author Dominic Battre <battre@chromium.org> Tue Mar 26 13:41:38 2019
committer Commit Bot <commit-bot@chromium.org> Tue Mar 26 13:41:38 2019
tree 57afd6f2b03eb8fb712c3b6a63f71f49868496ea
parent b7cabb1fe69e198f3d1b87f452462c9524711032

Move PasswordManagerDriver interface to ContentPasswordManagerDriver

It's important that the PasswordManagerDriver mojo interface is associated with
the renderer's communication channel. In http://crrev.com/c/1127995 we changed
the code such that ChromePasswordManagerClient became the class that
implemented the PasswordManagerDriver interface instead of
ContentPasswordManagerDriver. This was motivated by the fact that
ChromePasswordManagerClient was associated with a WebContents, not with a
RenderFrameHost, and we could use content::WebContentsFrameBindingSet for the
association.

At the same time, this created a somewhat funky class hierarchy: We had the
interfaces autofill::mojom::PasswordManagerDriver and
password_manager::PasswordManagerDriver (the name collision not ideal by
itself) but the ContentPasswordManagerDriver would only implement one of the
two interfaces and the other one would be implemented by an unrelated class
(ChromePasswordManagerClient). Furthermore, the password manager would break
the analogy of the class hierarchy that exists in the autofill component.

http://crrev.com/c/1148587 introduces a mojo association in
ChromeContentBrowserClient::BindAssociatedInterfaceRequestFromFrame that we can
use to undo the class hierarchy changes from http://crrev.com/c/1127995.
This is what's happening in this CL.

Bug: 862989
Change-Id: I5b8653e14b8a8b98d6588c6e4c873fd0b83ced4e
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1538501
Commit-Queue: Dominic Battré <battre@chromium.org>
Reviewed-by: Vasilii Sukhanov <vasilii@chromium.org>
Reviewed-by: Dominic Battré <battre@chromium.org>
Cr-Commit-Position: refs/heads/master@{#644285}