Refactor Autofill for out of process iframes (OOPIF).

components/autofill/content/browser/DEPS

Index: components/autofill/content/browser/DEPS
diff --git a/components/autofill/content/browser/DEPS b/components/autofill/content/browser/DEPS
index 35b6dfdfa38d09cf862574a71c3137b807c03476..194765c84bcb74dd464637ecb317b53f168661ca 100644
--- a/components/autofill/content/browser/DEPS
+++ b/components/autofill/content/browser/DEPS
@@ -1,4 +1,5 @@
 include_rules = [
+  "+components/password_manager/content/browser",

[vabr (Chromium), 2014/11/10 14:34:39]

I don't think we can do this. That would be a cycle (p.m. already depends on
autofill).

That means that we cannot use #include
"components/password_manager/content/browser/content_password_manager_driver.h"
below in content_autofill_driver.cc. This is effectively a componentising of the
DetectAccountCreationForms method. There are couple of (rather horrible)
possibilities I can see:

1) Keep DetectAccountCreationForms in the client, but add an argument to specify
the frame, to route to the driver.
2) Introduce an interface just for DetectAccountCreationForms in
components/autofill, and implement that by the password manager driver. There is
still the problem of getting the driver, though, so probably this is both too
intrusive, and not helpful.
3) Act before calling DetectAccountCreationForms: currently this is triggered in
the autofill code, and reaches out to password manager. Instead, maybe this
could be triggered in PasswordManager, and call back to the AutofillManager
(that dependency is OK).

[Garrett Casto, 2014/11/12 08:09:55]

To be clear, the problem isn't that some code in Autofill depends on some code
in the Password Manager, it's that autofill_content_browser depends on
password_manager_content_browser and vice versa. Philosophically it seems better
if all the dependencies go one way between the components anyway, but the
problem is more specific than that.
This seems like the right path to me, with ContentPasswordManagerDriver
implementing some generic observer class like AutofillResponseObserver. The
biggest issue is just that the obvious way of registering
ContentPasswordManagerDriver with ContentAutofillDriver doesn't work since they
are both being created on RenderFrameCreated() so there is no guarantee that
ContentAutofillDriver exists first. As long as we use a hook such that we can
guarantee that ContentePasswordManagerDriver is registered by the time that the
autofill response comes back, we should be fine.

   "+components/webdata/common",
   "+content/public/browser",
   "+crypto/random.h",