Fixed layout tests to be scroll order agnostic

LayoutTests/fast/dom/zoom-scroll-page-test.html

Index: LayoutTests/fast/dom/zoom-scroll-page-test.html
diff --git a/LayoutTests/fast/dom/zoom-scroll-page-test.html b/LayoutTests/fast/dom/zoom-scroll-page-test.html
index 3b784181ca99844ad5edf12b1ce5b0fff9f062c5..3c8e28885d7d08c8ece4856c1076a16e34fc7fda 100644
--- a/LayoutTests/fast/dom/zoom-scroll-page-test.html
+++ b/LayoutTests/fast/dom/zoom-scroll-page-test.html
@@ -23,10 +23,10 @@
             debug('Testing at zoom ' + zoomFactor + ' and scale ' + scaleFactor);
             if (window.testRunner && window.eventSender && window.internals) {
                 var y = 221;
-                internals.setPageScaleFactor(scaleFactor);
                 zoomBy(zoomFactor);
                 window.scrollTo(10, 10);
                 window.scrollBy(0, y);
+                internals.setPageScaleFactor(scaleFactor);

[majidvp, 2015/08/18 20:19:18]

Don't scrollTo, scrollBy, and pageYOffset all operate on visual viewport
coordinate? So I would imagine that the order should not matter here?

[bokan, 2015/08/19 17:10:45]

Yup, you're right. This confused me for a bit so I dug into it. It turns out to
be a floating point precision issue. When we scroll "layout first", the layout
viewport has enough content that it consumes the whole scroll. Scrolling "visual
first" splits the scroll between the viewports. Because of the way we handle
fractional scroll values, this means there's two places with floating point
imprecision so our error is increased (we truncate to ints twice). I think the
right solution here is to bump the "nearness" value in shouldBeCloseTo from
3->4.

                 shouldBeCloseTo('window.pageYOffset', y+10, 3, false);
                 zoomBy(-zoomFactor);
             }