Fix for fullscreen layout timing on Galaxy devices.

chrome/android/java/src/org/chromium/chrome/browser/fullscreen/FullscreenHtmlApiHandler.java

Index: chrome/android/java/src/org/chromium/chrome/browser/fullscreen/FullscreenHtmlApiHandler.java
diff --git a/chrome/android/java/src/org/chromium/chrome/browser/fullscreen/FullscreenHtmlApiHandler.java b/chrome/android/java/src/org/chromium/chrome/browser/fullscreen/FullscreenHtmlApiHandler.java
index 59542057e6b8174f2d81594fbff8b375156606f3..a0b6f677fe3ff3cb6847924b05bd9497da167151 100644
--- a/chrome/android/java/src/org/chromium/chrome/browser/fullscreen/FullscreenHtmlApiHandler.java
+++ b/chrome/android/java/src/org/chromium/chrome/browser/fullscreen/FullscreenHtmlApiHandler.java
@@ -138,6 +138,9 @@ public class FullscreenHtmlApiHandler {
                             contentView.removeOnLayoutChangeListener(this);
                         }
                     });
+
+                    // Request a layout so the updated system visibility takes affect.
+                    contentView.getRootView().requestLayout();

[Ted C, 2017/01/17 19:30:10]

Hmm...I added the case below because we weren't getting the first layout change
callback.

To be safe, I would leave it below and add it here.

[bokan, 2017/01/17 21:43:11]

You mean leave the removed lines in? Having the requestLayout both here and in
enterFullscreen doesn't work. Perhaps there's a bug in Android? It seems as if
LAYOUT_FULLSCREEN doesn't include the status bar in the layout height (at least
if there's no navigation bar to hide), but LAYOUT_FULLSCREEN -> FULLSCREEN
transition doesn't invalidate the layout. I can try this out in a simple app but
it'll have to wait until I get home, I don't have an android dev environment
setup on my laptop.

Anyway, if I keep requestLayout in enterFullscreen, we never get an
onLayoutChange, neither on the listener added there nor the one added here.

[Ted C, 2017/01/17 22:09:45]

Oh, that is rather unfortunate (and likely what your comment was referring to in
your original patch).  I had to add the request layout below otherwise it would
never get here in my local testing (probably a Nexus 5 of some incantation).

I'm afraid removing that below will break some device and the same here.

Oooh, is this only for clearing the fullscreen layout flag layout change
listener above?  If so, I think we can actually just remove it from the layout
change thing altogether and increase the timeout to something like 200MS instead
of 20MS.  Not exactly clean, but again, should be a clean merge and safer IMO.

[bokan, 2017/01/17 23:35:24]

Presumably because we send the MSG_ID_SET_FULLSCREEN_SYSTEM_UI_FLAGS from the
onLayoutChange, right? Shouldn't we get an onContentViewSystemUiVisibilityChange
when we go into LAYOUT_FULLSCREEN which will send the
MSG_ID_SET_FULLSCREEN_SYSTEM_UI_FLAGS message and lead us here?
No, the listener attached here doesn't seem to matter. In fact, this
requestLayout is a red herring, removing both makes it work on both the S7 and
Nexus 6. I'm seeing the onLayoutChange listener attached in enterFullscreen
called even without requestLayout. Perhaps the call to requestLayout makes us do
a layout before the status bar is hidden on S7 and since there's no navigation
bar, there's no geometry change?

Why did we need to explicitly requestLayout? Shouldn't changing the
systemUiVisibility automatically schedule a layout? 

                     break;
                 }
                 case MSG_ID_CLEAR_LAYOUT_FULLSCREEN_FLAG: {
@@ -298,9 +301,6 @@ public class FullscreenHtmlApiHandler {
         contentView.addOnLayoutChangeListener(mFullscreenOnLayoutChangeListener);
         contentView.setSystemUiVisibility(systemUiVisibility);
 
-        // Request a layout so the updated system visibility takes affect.
-        contentView.getRootView().requestLayout();
-
         mContentViewCoreInFullscreen = contentViewCore;
         mTabInFullscreen = tab;
     }