Fix tests to avoid page scale reset when setting page scale.

Source/WebKit/chromium/src/WebViewImpl.cpp

Index: Source/WebKit/chromium/src/WebViewImpl.cpp
diff --git a/Source/WebKit/chromium/src/WebViewImpl.cpp b/Source/WebKit/chromium/src/WebViewImpl.cpp
index b25d28c3ccb25f508abd37c2bd05822b4d763bfd..fb10a8511d8a4c91ef862c5ded3181376a066fbd 100644
--- a/Source/WebKit/chromium/src/WebViewImpl.cpp
+++ b/Source/WebKit/chromium/src/WebViewImpl.cpp
@@ -2871,6 +2871,9 @@ void WebViewImpl::setPageScaleFactor(float scaleFactor, const WebPoint& origin)
     scaleFactor = clampPageScaleFactorToLimits(scaleFactor);
     newScrollOffset = clampOffsetAtScale(newScrollOffset, scaleFactor);
 
+    // Since we are about to explicitly set the page scale factor, this should
+    // cancel out any outstanding reset request.
+    m_pageScaleConstraintsSet.setNeedsReset(false);

[aelias_OOO_until_Jul13, 2013/07/02 22:59:33]

This is a somewhat subtle initialization-timing change to production code and I
think we should avoid this kind of thing to fix tests.  How about instead making
the test code call setInitialPageScaleOverride(-1) when it tries to set the
scale?

[wjmaclean, 2013/07/03 14:12:23]

OK, but are we sure there's no way this "subtle timing" issue can ever bite us
in production web sites? If so, then I'm fine with this approach.

[aelias_OOO_until_Jul13, 2013/07/08 00:53:20]

I don't currently know of a bug here, but it's possible one may be discovered in
the future.  If that happens, it should be tested by a C++ unit test anyway.  I
think the layout tests should all pass regardless of the timing details.

     page()->setPageScaleFactor(scaleFactor, newScrollOffset);
 }