Fix layout tests that would fail if ScrollAnchoring was promoted to experimental

third_party/WebKit/LayoutTests/fast/css/sticky/sticky-container-moved.html

Index: third_party/WebKit/LayoutTests/fast/css/sticky/sticky-container-moved.html
diff --git a/third_party/WebKit/LayoutTests/fast/css/sticky/sticky-container-moved.html b/third_party/WebKit/LayoutTests/fast/css/sticky/sticky-container-moved.html
index b2bfc9623ad3233d4d2a49fae5d5391dce6a2c3f..9f3960f97a69b26dfafbc0ec5cf77cb8e9b5488d 100644
--- a/third_party/WebKit/LayoutTests/fast/css/sticky/sticky-container-moved.html
+++ b/third_party/WebKit/LayoutTests/fast/css/sticky/sticky-container-moved.html
@@ -2,7 +2,7 @@
 <script>
 if (window.internals) {
     internals.settings.setCSSStickyPositionEnabled(true);
-}           
+}
 </script>
 
 <style>
@@ -10,6 +10,7 @@ body {
     margin: 0;
     height: 2000px;
     overflow: hidden; /* hide scrollbars */
+    overflow-anchor: none;

[ymalik, 2016/07/22 16:53:24]

@skobes, I couldn't come up with a way to modify this test to work with scroll
anchoring. I think the right fix here is to disable scroll anchoring. This test
is testing that a stickly positioned element actually sticks when the position
of its containing block changes. If opting out of scroll anchoring enables us to
test this, its probably fine? If a webpage ever does this in practice, scroll
anchoring so that the user doesn't notice a visible change is probably the right
thing to do? WDYT?

[skobes, 2016/07/25 20:46:38]

How about calling scrollTo after changing height, instead of before?

[ymalik, 2016/07/26 21:03:50]

I think the purpose of the test is to verify that a change in the containing
block causes the sticky positioned element to stick. If we scroll after, we
can't tell whether the stick positioned element stuck because of the scroll or
because of the change in the containing block.

[skobes, 2016/07/26 21:19:14]

Good point.  Using the opt out here is fine.

 }
 
 #spacer {