Fix main thread top controls scrolling to mirror CC.

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

Index: third_party/WebKit/Source/core/frame/VisualViewport.cpp
diff --git a/third_party/WebKit/Source/core/frame/VisualViewport.cpp b/third_party/WebKit/Source/core/frame/VisualViewport.cpp
index 9ca8b0c5e8bce9d61b99c3eac47a54ddb4c05d35..6fd3bd16a767c965307481348e17e6c684cb415e 100644
--- a/third_party/WebKit/Source/core/frame/VisualViewport.cpp
+++ b/third_party/WebKit/Source/core/frame/VisualViewport.cpp
@@ -486,7 +486,7 @@ DoublePoint VisualViewport::maximumScrollPositionDouble() const
     frameViewSize = FloatSize(flooredIntSize(frameViewSize));
 
     FloatSize viewportSize(m_size);
-    viewportSize.expand(0, m_topControlsAdjustment);
+    viewportSize.expand(0, ceilf(m_topControlsAdjustment));

[majidvp, 2016/04/01 17:09:36]

Can you point out where in CC we are ceiling the top controls adjustment?

It is a bit odd that we ceil the top controls adjustment when computing 
viewportSize and floor it when computing frameViewSize. Ideally we 
only clamp it at the end of the computation. For example with a 
scale of 1 the current behaviour can adjust the max scroll offset
by one pixel though it was not necessary. 

Should we instead floor maxPosition instead?

[bokan, 2016/04/05 17:11:40]

https://code.google.com/p/chromium/codesearch#chromium/src/cc/trees/property_...

We ceil the bounds after adding the bounds_delta (bounds_delta is basically the
CC equivalent of topControlsAdjustment) when computing the clip size. I agree
it's odd that we're doing this but I'd rather match CC's quirks here as the CC
path is much better tested. We can adjust both sides in a follow up, though I'm
also weary of changing this code that isn't showing any obvious bugs.

 
     FloatSize maxPosition = frameViewSize - viewportSize;
     maxPosition.scale(1 / m_scale);