Reset VisualViewport position after same page navigation

third_party/WebKit/Source/core/page/Page.cpp

Index: third_party/WebKit/Source/core/page/Page.cpp
diff --git a/third_party/WebKit/Source/core/page/Page.cpp b/third_party/WebKit/Source/core/page/Page.cpp
index fe3e99ea8e0f9a28f94f496c9aba209c8ad98917..20e1482c73b00932f4e986601868a090bc57f94e 100644
--- a/third_party/WebKit/Source/core/page/Page.cpp
+++ b/third_party/WebKit/Source/core/page/Page.cpp
@@ -436,6 +436,11 @@ void Page::didCommitLoad(LocalFrame* frame)
         useCounter().didCommitLoad();
         deprecation().clearSuppression();
         frameHost().visualViewport().sendUMAMetrics();
+
+        // Need reset visual viewport position here to ensure that the scroll position is correct
+        // when we navigate to same page after scale(zoom-in/zoom-out)
+        // fix for crbug.com/642279

[bokan, 2016/09/15 16:03:47]

This change still doesn't address what I wrote before:

"Comments should answer "why?" not "what?". This comment just says what the line
below does (which we can easily see by looking at the line below). Instead, I'd
want to know *why* we reset the visual viewport here and not in a more logical
place. i.e. we need to reset the visual viewport position here since the setting
it earlier will clobber the current history item and didCommitLoad happens after
a new history item is created in FrameLoader."

It doesn't say *why* this reset is happening in didCommitLoad.

+        frameHost().visualViewport().setScrollPosition(DoublePoint(), ProgrammaticScroll);
         m_hostsUsingFeatures.updateMeasurementsAndClear();
         UserGestureIndicator::clearProcessedUserGestureSinceLoad();
     }