GitLab

Before this CL, several places (esp. in browser/) would override the
instance of the keyboard delegate in ui/. This caused an inconsistent,
hard to track state of the KeyboardVisibilityDelegate.

With this CL, the ui/ takes control of setting the delegate and specific
browser-side implementations are called by using the appropriate factory
methods. For that, the KeyboardVisibilityDelegate (brief: KVD) uses
sublasses with very clearly split responsibilities:

KeyboardVisibilityDelegate (ui/; public interface for all clients)
<-- ActivityKVD (ui/; propagates visibility changes to listeners)
  <-- SingleWindowKVD (browser/; prevents multi-window use)
    <-- ChromeKVD (browser/ separates extensions/native)
      <-- FakeKeyboard (javatests/; mocks native keyboard)

The CL actually has no functional changes, it performs these moves:
 - WindowAndroid Listeners moved into KeyboardVisibilityDelegate
 - AcivityWindowAndroid callbacks moved into ActivityKVD
 - ProcessInitializationHandler delegate became SingleWindowKVD
 - ManualFillingTestHelper's FakeKeyboard became a new, public class

Functional changes follow with https://crrev.com/c/1286426 and mainly
affect the ChromeKVD.

Purpose of isAndroidSoftKeyboardShowing(...) and
hideAndroidSoftKeyboardKeyboard(...):
 - Template methods to simplify mocking the calls to InputMethodManager
 - Ensures access to keyboard without extensions in subclasses (e.g. Chrome KVD)
 - prevents use of @CallSuper

Change-Id: I06cf50f48625d2d883efc8cd66a3d062204e51b2
Reviewed-on: https://chromium-review.googlesource.com/c/1286649
Commit-Queue: Friedrich Horschig [EDT] <fhorschig@chromium.org>
Reviewed-by: Ted Choc <tedchoc@chromium.org>
Cr-Commit-Position: refs/heads/master@{#602293}