Re-enable ScrollbarAnimationController::DidRequestShowFromMainThread.

third_party/WebKit/Source/core/frame/FrameView.cpp

Index: third_party/WebKit/Source/core/frame/FrameView.cpp
diff --git a/third_party/WebKit/Source/core/frame/FrameView.cpp b/third_party/WebKit/Source/core/frame/FrameView.cpp
index d17602cb1561833fc7adc76b38648b3f4074b35e..02375ead5fc1cce685b2b67cd1d2671d260e908b 100644
--- a/third_party/WebKit/Source/core/frame/FrameView.cpp
+++ b/third_party/WebKit/Source/core/frame/FrameView.cpp
@@ -1668,7 +1668,12 @@ void FrameView::ViewportSizeChanged(bool width_changed, bool height_changed) {
     }
   }
 
+// TODO(skobes): For reasons not fully understood, showing scrollbars from
+// main on viewport size changes regresses memory and perf tests on Android

[aelias_OOO_until_Jul13, 2017/04/25 21:05:08]

Hmm, since you traced it to viewport sized changes, it's probably due to top
controls hiding in some way.  +cc bokan@, any idea what the problem might be?

+// (crbug.com/706927, crbug.com/712453).
+#if !OS(ANDROID)

[aelias_OOO_until_Jul13, 2017/04/25 21:05:08]

I really don't like OS(ANDROID), among other things because it winds up forcing
Android-specific unit tests or unit tests that only go red on Android.  If we're
going to go with platform-specific behavior, I prefer it to be behind a
WebSetting that's only true on Android.  A natural one for this purpose would be
GetPage()->GetSettings().GetMainFrameResizesAreOrientationChanges()

   ShowOverlayScrollbars();
+#endif
 
   if (root_layer_scrolling_enabled) {
     // The background must be repainted when the FrameView is resized, even if