Don't change layout size due to top control show/hide

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 f92b88a3ca8dfae40d31b5dd465cec633685a0f8..0c32e77b1f8845136ba5c6a0a703ba77efa84c7e 100644
--- a/third_party/WebKit/Source/core/frame/FrameView.cpp
+++ b/third_party/WebKit/Source/core/frame/FrameView.cpp
@@ -40,7 +40,9 @@
 #include "core/fetch/ResourceFetcher.h"
 #include "core/frame/FrameHost.h"
 #include "core/frame/LocalFrame.h"
+#include "core/frame/PageScaleConstraintsSet.h"
 #include "core/frame/Settings.h"
+#include "core/frame/TopControls.h"
 #include "core/html/HTMLFrameElement.h"
 #include "core/html/HTMLPlugInElement.h"
 #include "core/html/HTMLTextFormControlElement.h"
@@ -1112,6 +1114,28 @@ IntRect FrameView::computeVisibleArea()
     return us;
 }
 
+FloatSize FrameView::viewportSizeForViewportUnits() const
+{
+    FloatSize size(layoutSize(IncludeScrollbars));
+
+    // We use the layoutSize rather than frameRect to calculate viewport units
+    // so that we get correct results on mobile where the page is laid out into
+    // a rect that may be larger than the viewport (e.g. the 980px fallback
+    // width for desktop pages). Since the layout height is statically set to
+    // be the viewport with top controls showing, we add the top controls
+    // height, compensating for page scale as well, since we want to use the
+    // viewport with top controls hidden for vh (to match Safari).
+    TopControls& topControls = m_frame->host()->topControls();
+    if (m_frame->isMainFrame()) {
+        float pageScale = m_frame->host()->pageScaleConstraintsSet().finalConstraints().minimumScale;

[aelias_OOO_until_Jul13, 2016/01/16 04:17:38]

This is because of how minimum-scale is also used in mainFrameSize, I assume?

The impact of scale on this stuff is a bit subtle, could you write a unit test
checking geometry sizes in the presence of an unusual min-scale?

[bokan, 2016/01/19 00:05:31]

We say 100vh is the viewport size when top controls are hidden. When the page is
pinch-zoomable we have to also choose the scale at which we want 100vh to fill
the viewport (and use that to scale the top controls addition). I've actually
made a change here and use the scale at which viewport width == layout width. In
the common case, this will be the minimum scale. The difference is that I think
this behaves more sanely if the user specifies an explicit minimum-scale or has
a spurious "extra-wide" element on the page that implicitly increases the
minimum scale.
Done, added two for scaled page and for a minimum-scale that's smaller than the
layout width scale.

[aelias_OOO_until_Jul13, 2016/01/19 20:26:32]

Sounds good, I was going to suggest the same thing.

+        size.expand(0, topControls.height() / pageScale);
+    }
+
+    float scale = frame().pageZoomFactor();
+    size.scale(1 / scale);
+    return size;
+}
+
 DocumentLifecycle& FrameView::lifecycle() const
 {
     return m_frame->document()->lifecycle();