MainFrame scrollbars should work with RFV instead of FV

third_party/WebKit/LayoutTests/platform/linux/svg/custom/masking-clipping-hidpi-expected.txt

Index: third_party/WebKit/LayoutTests/platform/linux/svg/custom/masking-clipping-hidpi-expected.txt
diff --git a/third_party/WebKit/LayoutTests/platform/linux/svg/custom/masking-clipping-hidpi-expected.txt b/third_party/WebKit/LayoutTests/platform/linux/svg/custom/masking-clipping-hidpi-expected.txt
index 6b1689c149c9404d9b0542372ebd241a7022a0f1..aefe23dcb380211364f364ca8b95e56909404305 100644
--- a/third_party/WebKit/LayoutTests/platform/linux/svg/custom/masking-clipping-hidpi-expected.txt
+++ b/third_party/WebKit/LayoutTests/platform/linux/svg/custom/masking-clipping-hidpi-expected.txt
@@ -1,10 +1,10 @@
 layer at (0,0) size 1600x1200
   LayoutView at (0,0) size 1600x1200
-layer at (0,0) size 1600x1200
-  LayoutSVGRoot {svg} at (0,0) size 567x724
+layer at (0,0) size 1600x600

[ymalik, 2016/11/04 18:54:18]

This test like the other window resize tests also fails because of timing.

Before this CL, scrollbar existence was being computed incorrectly  because of
which we were setting the paint invalidation bit differently from what happens
in this CL. I verified that the sizes and of the layers in this test are the
same as they were before the CL and the size difference is just because this is
an intermediate step.

[bokan, 2016/11/04 19:23:59]

Why was scrollbar existence computed incorrectly? The test sets a
"BackingScaleFactor" not PageScaleFactor so the VisualViewport should be equal
to the FrameView size, for which your CL shouldn't have any effect, right?

Does the test not dump this text when notifyDone() is called? If not, are there
any functions in testRunner/internals we can use to delay the dump until we're
in a steady state? skobes@, any idea?

[ymalik, 2016/11/04 19:39:51]

I believe that the difference is caused by computeScrollbarExistance using the
visual viewport size (RFV uses visualViewport::visibleContentRect) which is set
right when BackingScaleFactor is changed. 

[bokan, 2016/11/04 20:00:37]

In that case, the scrollbar existence was computed correctly before, no? Also,
why does scrollbar existence affect the layer size here by so much?

[skobes, 2016/11/04 21:33:20]

The test runner calls updateAllLifecyclePhases before dumping the layout tree,
so everything ought to be up to date (if not, it's a bug).

[ymalik, 2016/11/08 00:11:13]

So I did a bit more investigation. My original comment about timing in this test
doesn't make sense.

Before this patch (where the scroller was FV and not RFV), here is roughly the
sequence of events that took place when this test set the backing scale factor
to 2:
1) The visual viewport dimensions are changed (800x600 -> 1600x1200) but the
FV::frameRect dimensions are still (800x600) 
2) We start doing layout and the LayoutSVGRoot object size (which is where the
PaintLayer size comes from) is changed, but only in one dimension (800x600 ->
1600x600)
3) We get into FV::computeScrollbarExistence and determine that we need
scrollbars (800x600 < 1600x1200), and layout the scrollbars (updating the sizes
for the LayoutObjects to exclude the scrollbars).This sets the correct
dimensions on LayoutSVGRoot(1600x600 -> 1600x1200)
4) We get into FV::computeScrollbarExistence again when the actual FV::frameRect
changes after layout and determine that we don't actually need the scrollbars.

With this patch, step 3) doesn't lay out the scrollbars because we use
VV:visibleContentRect which is updated in the very beginning and we never end up
correcting the size of the LayoutSVGRoot.

I don't understand why step 2 doesn't compute the correct height, but it seems
like a bug. This CL just causes this test to highlight it.

We have two ways forward, 1) Just update the layout test and see if we get any
complaints. I suspect we wont. and 2) Just don't make this change if the frame
document is SVG and investigate it more.

I don't want to special case so I am in favor of 1), especially because this
looks broken anyway.

+  LayoutSVGRoot {svg} at (0,0) size 567x600
     LayoutSVGHiddenContainer {defs} at (0,0) size 0x0
       LayoutSVGResourceMasker {mask} [id="textMask"] [maskUnits=objectBoundingBox] [maskContentUnits=userSpaceOnUse]
-        LayoutSVGRect {rect} at (0,0) size 1600x1200 [fill={[type=SOLID] [color=#FFFFFF]}] [x=0.00] [y=0.00] [width=800.00] [height=600.00]
+        LayoutSVGRect {rect} at (0,0) size 1600x600 [fill={[type=SOLID] [color=#FFFFFF]}] [x=0.00] [y=0.00] [width=800.00] [height=300.00]
         LayoutSVGText {text} at (0,-2) size 160x18 contains 1 chunk(s)
           LayoutSVGInlineText {#text} at (0,0) size 160x18
             chunk 1 text run 1 at (0.00,12.00) startOffset 0 endOffset 26 width 160.00: "This text should be sharp."
@@ -27,4 +27,4 @@ layer at (0,0) size 1600x1200
     LayoutSVGHiddenContainer {defs} at (0,0) size 0x0
       LayoutSVGResourcePattern {pattern} [id="Pattern"] [patternUnits=objectBoundingBox] [patternContentUnits=userSpaceOnUse]
         LayoutSVGEllipse {circle} at (10,10) size 80x80 [fill={[type=LINEAR-GRADIENT] [id="blackGradient"]}] [cx=25.00] [cy=25.00] [r=20.00]
-    LayoutSVGRect {rect} at (0,324) size 400x400 [fill={[type=PATTERN] [id="Pattern"]}] [x=0.00] [y=162.00] [width=200.00] [height=200.00]
+    LayoutSVGRect {rect} at (0,324) size 400x276 [fill={[type=PATTERN] [id="Pattern"]}] [x=0.00] [y=162.00] [width=200.00] [height=200.00]