Resize only the virtual viewport when the OSK triggers a resize.

chrome/android/java/src/org/chromium/chrome/browser/ChromeActivity.java

 // Copyright 2015 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.
 
 package org.chromium.chrome.browser;
 
 import android.annotation.SuppressLint;
 import android.annotation.TargetApi;
 import android.app.Activity;
 import android.app.SearchManager;
@@ skipping 187 matching lines @@
     // We have to instantiate the TouchExplorationStateChangeListner object in the code.
     @SuppressLint("NewApi")
     private TouchExplorationStateChangeListener mTouchExplorationStateChangeListener;
 
     // Observes when sync becomes ready to create the mContextReporter.
     private ProfileSyncService.SyncStateChangedListener mSyncStateChangedListener;
 
     private ActivityWindowAndroid mWindowAndroid;
     private ChromeFullscreenManager mFullscreenManager;
     private CompositorViewHolder mCompositorViewHolder;
+    private InsetConsumerView mInsetConsumerView;
     private ContextualSearchManager mContextualSearchManager;
     private ReaderModeManager mReaderModeManager;
     private SnackbarManager mSnackbarManager;
     private DataUseSnackbarController mDataUseSnackbarController;
     private AppMenuPropertiesDelegate mAppMenuPropertiesDelegate;
     private AppMenuHandler mAppMenuHandler;
     private ToolbarManager mToolbarManager;
     private BookmarkModelObserver mBookmarkObserver;
 
     // Time in ms that it took took us to inflate the initial layout
@@ skipping 129 matching lines @@
         TraceEvent.end("onCreate->setContentView()");
         mInflateInitialLayoutDurationMs = SystemClock.elapsedRealtime() - begin;
 
         // Set the status bar color to black by default. This is an optimization for
         // Chrome not to draw under status and navigation bars when we use the default
         // black status bar
         ApiCompatibilityUtils.setStatusBarColor(getWindow(), Color.BLACK);
 
         mCompositorViewHolder = (CompositorViewHolder) findViewById(R.id.compositor_view_holder);
         mCompositorViewHolder.setRootView(getWindow().getDecorView().getRootView());
+
+        // Iterate up the view hierarchy to find the eldest parent that consumes
+        // window insets. Stop it from consuming the insets and add a custom
+        // view right after it that consumes the insets and stores it to access
+        // later. ContentViewCore needs the insets to determine the portion of
+        // the screen obscured by non-content displaying things such as the OSK.
+        View parent = mCompositorViewHolder;
+        ViewGroup addAfter = null;
+        while (parent.getParent() instanceof View) {
+            parent = (View) parent.getParent();
+            if (parent.getFitsSystemWindows()) {
+                addAfter = (ViewGroup) parent;
+            }
+        }
+
+        // Transfer child view hierarchy to InsetConsumerView. This is needed to
+        // ensure that the insets are applied properly.
+        if (addAfter != null) {
+            // Setting fitsSystemWindows to false ensures that the view
+            // doesn't consume the insets.
+            addAfter.setFitsSystemWindows(false);

[aelias_OOO_until_Jul13, 2016/03/09 01:34:43]

Hmm, this algorithm is more complicated than I'd like -- I'll accept it if it's
the only method but I'd like to make sure it's the simplest.  Since you're
disabling the inset-consuming behavior in this existing View anyway, wouldn't it
work to simply put your InsetConsumerView above it in the hierarchy and not
bother calling setFitsSystemWindows(false); on any of the children?  If so, you
could just place InsetConsumerView something like one off the root View, instead
of being so dynamic?

[ymalik, 2016/03/09 16:47:14]

Yes with the current view hierarchy it will work if you put the
InsetConsumerView one off the root view. I am just not sure how that plays with
the compat views on older versions of Android (I tested Kitkat and above),
because that fails if the root view is the one that actually consumes the
insets. I am not sure if we gain too much simplicity there because we would
still need to transfer the children view hierarchy. Doing this dynamically makes
us more compatible with the platform changes, WDYT?

[aelias_OOO_until_Jul13, 2016/03/09 22:18:59]

I don't think the worry the root View might capture insets in the future is
especially plausible.  I'm more worried about the possibility that whatever
place you happen to inject yourself in the hierarchy will have expectations
about the child substructure and crash when it doesn't match.  So the priority
should be to make sure the injection point is at a safe place no library has
expectations about.

Even if you're worried about the root, there's no need to select the location
dynamically.  You can just always go one off the root and call
root.setFitsSystemWindows(false), which is just the same as your dynamic
algorithm would do anyway.

+            InsetConsumerView insetConsumerView = new InsetConsumerView(this);
+            insetConsumerView.setFitsSystemWindows(true);
+            while (addAfter.getChildCount() > 0) {
+                View currentChild = addAfter.getChildAt(0);
+                addAfter.removeView(currentChild);
+                insetConsumerView.addView(currentChild);
+            }
+            addAfter.addView(insetConsumerView);
+            mInsetConsumerView = insetConsumerView;
+        }
     }
 
     /**
      * Constructs {@link ToolbarManager} and the handler necessary for controlling the menu on the
      * {@link Toolbar}. Extending classes can override this call to avoid creating the toolbar.
      */
     protected void initializeToolbar() {
         final View controlContainer = findViewById(R.id.control_container);
         assert controlContainer != null;
         ToolbarControlContainer toolbarContainer = (ToolbarControlContainer) controlContainer;
@@ skipping 685 matching lines @@
 
     /**
      * {@link TabModelSelector} no longer implements TabModel.  Use getTabModelSelector() or
      * getCurrentTabModel() depending on your needs.
      * @return The {@link TabModelSelector}, possibly null.
      */
     public TabModelSelector getTabModelSelector() {
         return mTabModelSelector;
     }
 
+    /**
+     * Returns the {@link InsetConsumerView} that has the current system window
+     * insets information.
+     * @return The {@link InsetConsumerView}, possibly null.
+     */
+    public InsetConsumerView getInsetConsumerView() {
+        return mInsetConsumerView;
+    }
+
     @Override
     public TabCreatorManager.TabCreator getTabCreator(boolean incognito) {
         return incognito ? mIncognitoTabCreator : mRegularTabCreator;
     }
 
     /**
      * Sets the {@link ChromeTabCreator}s owned by this {@link ChromeActivity}.
      * @param regularTabCreator A {@link ChromeTabCreator} instance.
      */
     public void setTabCreators(TabCreatorManager.TabCreator regularTabCreator,
@@ skipping 536 matching lines @@
     public static int getThemeId() {
         boolean useLowEndTheme =
                 SysUtils.isLowEndDevice() && Build.VERSION.SDK_INT >= Build.VERSION_CODES.LOLLIPOP;
         return (useLowEndTheme ? R.style.MainTheme_LowEnd : R.style.MainTheme);
     }
 
     private void setLowEndTheme() {
         if (getThemeId() == R.style.MainTheme_LowEnd) setTheme(R.style.MainTheme_LowEnd);
     }
 }