Fix main thread top controls scrolling to mirror CC.

third_party/WebKit/Source/web/ResizeViewportAnchor.cpp

Index: third_party/WebKit/Source/web/ResizeViewportAnchor.cpp
diff --git a/third_party/WebKit/Source/web/ResizeViewportAnchor.cpp b/third_party/WebKit/Source/web/ResizeViewportAnchor.cpp
index 8c79f083d325094e0a910dd469f64936fe9b733a..56db693241bf274269d27ee3fbefc65ab395efdc 100644
--- a/third_party/WebKit/Source/web/ResizeViewportAnchor.cpp
+++ b/third_party/WebKit/Source/web/ResizeViewportAnchor.cpp
@@ -14,13 +14,52 @@ namespace blink {
 
 ResizeViewportAnchor::ResizeViewportAnchor(FrameView& rootFrameView, VisualViewport& visualViewport)
     : ViewportAnchor(rootFrameView, visualViewport)
-    , m_visualViewportInDocument(rootFrameView.getScrollableArea()->visibleContentRectDouble().location())
+    , m_visualViewportInDocument(rootFrameView.getScrollableArea()->scrollPositionDouble())
 {
 }
 
 ResizeViewportAnchor::~ResizeViewportAnchor()
 {
-    m_rootFrameView->getScrollableArea()->setScrollPosition(m_visualViewportInDocument, ProgrammaticScroll);
+    // TODO(bokan): Don't use RootFrameViewport::setScrollPosition since it
+    // assumes we can just set a sub-pixel precision offset on the FrameView.
+    // While we "can" do this, the offset that will be shipped to CC will be the
+    // truncated number and this class is used to handle TopControl movement
+    // which needs the two threads to match exactly pixel-for-pixel. We can
+    // replace this with RFV::setScrollPosition once Blink is sub-pixel scroll
+    // offset aware. crbug.com/414283.
+
+    ScrollableArea* rootViewport = m_rootFrameView->getScrollableArea();
+    ScrollableArea* layoutViewport =
+        m_rootFrameView->layoutViewportScrollableArea();
+
+    // Clamp the scroll offset of each viewport now so that we force any invalid
+    // offsets to become valid so we can compute the correct deltas.
+    m_visualViewport->clampToBoundaries();
+    layoutViewport->setScrollPosition(
+        layoutViewport->scrollPositionDouble(), ProgrammaticScroll);
+
+    DoubleSize delta = m_visualViewportInDocument
+        - rootViewport->scrollPositionDouble();
+
+    m_visualViewport->move(toFloatSize(delta));
+
+    // Since the main thread FrameView has integer scroll offsets, scroll it to
+    // the next pixel and then we'll scroll the visual viewport again to
+    // compensate for the sub-pixel offset.
+    delta = m_visualViewportInDocument
+        - rootViewport->scrollPositionDouble();
+
+    IntSize layoutDelta = delta.height() < 0

[majidvp, 2016/04/06 18:07:30]

nit: Can we just round here? There does not seem to be any
advantage of going to the next pixel as opposed to the closest pixel. 

[bokan, 2016/04/06 19:23:35]

I don't think we can. We scroll the visual viewport first. Once that's maximally
scrolled, we scroll the remainder in the FrameView and then fixup the subpixel
part in the visual viewport since FrameView doesn't support fractionals. Assume
our delta is positive. If we round down the FrameView offset, the VisualViewport
is maximally scrolled so it won't be able to compensate for the fractional since
it's bounded by the FrameView. We need to "overscroll" the FrameView to ensure
the pixel of which we want a fraction of is within the FrameView. Does that make
sense?

+        ? flooredIntSize(delta)
+        : expandedIntSize(delta);
+
+    layoutViewport->setScrollPosition(
+        layoutViewport->scrollPosition() + layoutDelta,
+        ProgrammaticScroll);
+
+    delta = m_visualViewportInDocument
+        - rootViewport->scrollPositionDouble();
+    m_visualViewport->move(toFloatSize(delta));
 }
 
 } // namespace blink