Use AutofillDriver* in ContentAutofillDriverFactory when possible

Use AutofillDriver* in ContentAutofillDriverFactory when possible

ContentAutofillDriverFactory creates ContentAutofillDriver instances in
production code. However, it interacts with them in a limited way. Apart from
creating and destroying those instances, there are currently two actions
performed by the factory: calling DidNavigateFrame, and BindRequest.

DidNavigateFrame passes an unnecessary amount of //content-dependent detail to
just notify the driver when the frame navigated to a different page. The latter
is a //content-independent notion. This CL pushes the //content-related
aruguments out of this method, renames it accordingly, and promotes it to the
parent interface, AutofillDriver.

BindRequest is specific to ContentAutofillDriver, as opposed to AutofillDriver,
because the iOS implementation of AutofillDriver does not use interprocess
communication at all. The BindRequest is only performed in a static binding
method used by ChromeContentBrowserClient.

The fact that ContentAutofillDriverFactory expects to be handling a
ContentAutofillDriver makes unittesting hard. In fact, there is no unittest for
the factory at the moment. The inability to mock the AutofillDriver API results
in a cascade of production-code dependencies when trying to construct a factory
instance and test it. Given that DidNavigateFrame is renamed and pushed to
AutofillDriver, and that BindRequest is not used in instance methods of the
factory, this CL reduces the expectation of the factory to only work with
AutofillDriver. This paves the way for creating a unittest.

Another necessary step to allow creating a unittest for the factory was allowing
the factory to create mocks of AutofillDriver instead of the production version.
This CL achieves this by passing a factory function to the
ContentAutofillDriverFactory on construction. In production code this function
creates ContentAutofillDriver instances, but the test can inject a different
function, creating mocks.

Finally, the CL also adds a unittest for the factory, testing the logic for
calling NavigatedToDifferentPage which moved from the driver to the factory.

BUG=669045

[vabr (Chromium), 2016-12-23 18:56:31]

The CQ bit was checked by vabr@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-12-23 18:56:39]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-12-23 19:08:39]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-12-23 19:08:39]

Dry run: Try jobs failed on following builders:
  chromeos_amd64-generic_chromium_compile_only_ng on
master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromeos_amd64-...)

[vabr (Chromium), 2016-12-23 19:26:27]

Description was changed from

==========
Use AutofillDriver* in ContentAutofillDriverFactory when possible

ContentAutofillDriverFactory creates ContentAutofillDriver instances in
production code. However, it interacts with them in a limited way. Apart from
creating and destroying those instances, there are currently two actions
performed by the factory: calling DidNavigateFrame, and BindRequest.

DidNavigateFrame passes an unnecessary amount of //content-dependent detail to
just notify the driver when the frame navigated to a different page. The latter
is a //content-independent notion. This CL pushes the //content-related
aruguments out of this method, renames it accordingly, and promotes it to the
parent interface, AutofillDriver.

BindRequest is specific to ContentAutofillDriver, as opposed to AutofillDriver,
because the iOS implementation of AutofillDriver does not use interprocess
communication at all. The BindRequest is only performed in a static binding
method used by ChromeContentBrowserClient.

The fact that ContentAutofillDriverFactory expects to be handling a
ContentAutofillDriver makes unittesting hard. In fact, there is no unittest for
the factory at the moment. The inability to mock the AutofillDriver API results
in a cascade of production-code dependencies when trying to construct a factory
instance and test it. Given that DidNavigateFrame is renamed and pushed to
AutofillDriver, and that BindRequest is not used in instance methods of the
factory, this CL reduces the expectation of the factory to only work with
AutofillDriver. This paves the way for creating a unittest in a coming CL.

BUG=669045
==========

to

==========
Use AutofillDriver* in ContentAutofillDriverFactory when possible

ContentAutofillDriverFactory creates ContentAutofillDriver instances in
production code. However, it interacts with them in a limited way. Apart from
creating and destroying those instances, there are currently two actions
performed by the factory: calling DidNavigateFrame, and BindRequest.

DidNavigateFrame passes an unnecessary amount of //content-dependent detail to
just notify the driver when the frame navigated to a different page. The latter
is a //content-independent notion. This CL pushes the //content-related
aruguments out of this method, renames it accordingly, and promotes it to the
parent interface, AutofillDriver.

BindRequest is specific to ContentAutofillDriver, as opposed to AutofillDriver,
because the iOS implementation of AutofillDriver does not use interprocess
communication at all. The BindRequest is only performed in a static binding
method used by ChromeContentBrowserClient.

The fact that ContentAutofillDriverFactory expects to be handling a
ContentAutofillDriver makes unittesting hard. In fact, there is no unittest for
the factory at the moment. The inability to mock the AutofillDriver API results
in a cascade of production-code dependencies when trying to construct a factory
instance and test it. Given that DidNavigateFrame is renamed and pushed to
AutofillDriver, and that BindRequest is not used in instance methods of the
factory, this CL reduces the expectation of the factory to only work with
AutofillDriver. This paves the way for creating a unittest in a coming CL.

The CL also adds a unittest for the factory, testing the logic for calling
NavigatedToDifferentPage which moved from the driver to the factory.

BUG=669045
==========

[vabr (Chromium), 2016-12-23 19:44:54]

The CQ bit was checked by vabr@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-12-23 19:45:03]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[vabr (Chromium), 2016-12-23 19:48:00]

Description was changed from

==========
Use AutofillDriver* in ContentAutofillDriverFactory when possible

ContentAutofillDriverFactory creates ContentAutofillDriver instances in
production code. However, it interacts with them in a limited way. Apart from
creating and destroying those instances, there are currently two actions
performed by the factory: calling DidNavigateFrame, and BindRequest.

DidNavigateFrame passes an unnecessary amount of //content-dependent detail to
just notify the driver when the frame navigated to a different page. The latter
is a //content-independent notion. This CL pushes the //content-related
aruguments out of this method, renames it accordingly, and promotes it to the
parent interface, AutofillDriver.

BindRequest is specific to ContentAutofillDriver, as opposed to AutofillDriver,
because the iOS implementation of AutofillDriver does not use interprocess
communication at all. The BindRequest is only performed in a static binding
method used by ChromeContentBrowserClient.

The fact that ContentAutofillDriverFactory expects to be handling a
ContentAutofillDriver makes unittesting hard. In fact, there is no unittest for
the factory at the moment. The inability to mock the AutofillDriver API results
in a cascade of production-code dependencies when trying to construct a factory
instance and test it. Given that DidNavigateFrame is renamed and pushed to
AutofillDriver, and that BindRequest is not used in instance methods of the
factory, this CL reduces the expectation of the factory to only work with
AutofillDriver. This paves the way for creating a unittest in a coming CL.

The CL also adds a unittest for the factory, testing the logic for calling
NavigatedToDifferentPage which moved from the driver to the factory.

BUG=669045
==========

to

==========
Use AutofillDriver* in ContentAutofillDriverFactory when possible

ContentAutofillDriverFactory creates ContentAutofillDriver instances in
production code. However, it interacts with them in a limited way. Apart from
creating and destroying those instances, there are currently two actions
performed by the factory: calling DidNavigateFrame, and BindRequest.

DidNavigateFrame passes an unnecessary amount of //content-dependent detail to
just notify the driver when the frame navigated to a different page. The latter
is a //content-independent notion. This CL pushes the //content-related
aruguments out of this method, renames it accordingly, and promotes it to the
parent interface, AutofillDriver.

BindRequest is specific to ContentAutofillDriver, as opposed to AutofillDriver,
because the iOS implementation of AutofillDriver does not use interprocess
communication at all. The BindRequest is only performed in a static binding
method used by ChromeContentBrowserClient.

The fact that ContentAutofillDriverFactory expects to be handling a
ContentAutofillDriver makes unittesting hard. In fact, there is no unittest for
the factory at the moment. The inability to mock the AutofillDriver API results
in a cascade of production-code dependencies when trying to construct a factory
instance and test it. Given that DidNavigateFrame is renamed and pushed to
AutofillDriver, and that BindRequest is not used in instance methods of the
factory, this CL reduces the expectation of the factory to only work with
AutofillDriver. This paves the way for creating a unittest.

Another necessary step to allow creating a unittest for the factory was allowing
the factory to create mocks of AutofillDriver instead of the production version.
This CL achieves this by passing a factory function to the
ContentAutofillDriverFactory on construction. In production code this function
creates ContentAutofillDriver instances, but the test can inject a different
function, creating mocks.

Finally, the CL also adds a unittest for the factory, testing the logic for
calling NavigatedToDifferentPage which moved from the driver to the factory.

BUG=669045
==========

[commit-bot: I haz the power, 2016-12-23 20:13:09]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-12-23 20:13:10]

Dry run: Try jobs failed on following builders:
  linux_chromium_chromeos_ozone_rel_ng on master.tryserver.chromium.linux
(JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  mac_chromium_compile_dbg_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_comp...)

[vabr (Chromium), 2016-12-23 20:29:53]

The CQ bit was checked by vabr@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-12-23 20:29:59]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-12-23 20:49:20]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-12-23 20:49:21]

Dry run: Try jobs failed on following builders:
  linux_chromium_chromeos_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[vabr (Chromium), 2016-12-23 21:20:22]

The CQ bit was checked by vabr@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-12-23 21:20:30]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-12-23 21:41:47]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-12-23 21:41:51]

Dry run: Try jobs failed on following builders:
  android_n5x_swarming_rel on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_n5x_...)

[vabr (Chromium), 2016-12-23 21:44:25]

The CQ bit was checked by vabr@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-12-23 21:44:37]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-12-23 22:57:06]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-12-23 22:57:07]

Dry run: This issue passed the CQ dry run.

[vabr (Chromium), 2017-02-23 06:27:06]

This has been superseded by https://codereview.chromium.org/2715483002/, hence
closing without landing.