The viewport zoom seems incorrect.

The root causes of this bug is floating point error that causes us to misinterpret why the WKWebView's scrollView's contentSize is narrower than its frame. We then try to reset zoomScale, which has the side-effect of temporarily changing the scroll offset, which causes this particular page to grow, which changes contentSize, and this continues in an endless cycle, making the page unusable.

Proposed solution:
-The way [CRWWebController webViewScrollViewDidResetContentSize] resets zoomScale is meant to be a workaround for a bug where WebKit doesn't property resize content on device orientation change. But that's getting incorrectly triggered in this case. We shouldn't reset zoomScale when the width of the contentSize is within a pixel of the width of the frame.

More details:
-This page doesn't use a meta viewport tag, so it gets scaled down to the width of the screen. The unscaled page has width 1261, and the screen's logical width is 768, which means we get a zoomScale of 0.6090404. 
-So the UIScrollView starts out unscaled with a contentSize whose width is 1261 and with a frame of width 768.
-WebKit calls [UIScrollView setZoomScale] to set a scale of 0.609040441 (that is, 768/1261) on the scroll view.
-Inside UIScrollView, this leads to a call to [UIScrollView _adjustContentSizeForView:atScale], which calls an apparently private scrollView:contentSizeForZoomScale:withProposedSize: method on the UIScrollViewDelegate, which is the WKWebView.
-The proposed size passed to this method has width 0.6090404*768. But 0.609040441 is a floored representation of 768/1261, so we get proposed width 767.9999. This gets floored to the nearest device pixel. On a device width device pixel ratio 2 (like an iPad Air), we get width 767.5. So the UIScrollView's contentSize has width 767.5.
-Now, in Chromium, [CRWWebController webViewScrollViewDidResetContentSize] gets called, notices that the contentSize's width (767.5) is less than the frame width (768), interprets this as the renderer incorrectly sizing the content area, and sets zoom scale to 1 to force a re-rendering.
-Zooming the page has the effect of change the scroll offset (unless it was 0 to start with).
-This particular page is an infinite scroller, so once it detects enough of a change in scroll offset, it loads more content.
-So the page grows. And then we get another call to [CRWWebController webViewScrollViewDidResetContentSize] with the same floating point issue for the width, and we reset the zoomScale again, and the scroll offset jumps around and the page loads more content.
-This bug will reproduce on any infinite scrolling page that happens to have width 1261 on a device that's 768 pixels wide. I'd expect it to also reproduce on other page/device combinations that lead to a zoomScale that can't be exactly represented as a float.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/de7a28aa6d2424863bf4feb7f54206ba61fbbf84

commit de7a28aa6d2424863bf4feb7f54206ba61fbbf84
Author: Ali Juma <ajuma@chromium.org>
Date: Tue Nov 27 14:55:30 2018

Make CRWWebController::webViewScrollViewDidResetContentSize workaround more targetted

webViewScrollViewDidResetContentSize interprets the scroll view's content size's
width being narrower than the frame's width as a sign that WebKit hasn't
properly resized the content, so resets zoom scale to force WebKit to
re-render. However, the zoom scale that makes the content fit exactly within
the width of the frame may not be exactly representable as a float. In this
case, the content size's width can be up to a pixel narrower than the frame
width. There's no benefit to forcing a re-render in this case, and furthermore,
resetting the zoom scale causes the page to scroll, which may trigger the page's
content to spuriously change. In the worst case, this can lead to a never-ending
cycle of resetting the zoom scale, the page scrolling, the page changing,
resetting the zoom scale again, and so on.

This CL makes webViewScrollViewDidResetContentSize ignore cases where the
contentSize's width is up to a pixel narrower than the frame.

Bug:  822697 
Change-Id: I93e3e7efb33a6ea3b931c0d7f2b404bf93e80e12
Reviewed-on: https://chromium-review.googlesource.com/c/1348955
Reviewed-by: Eugene But <eugenebut@chromium.org>
Reviewed-by: Kurt Horimoto <kkhorimoto@chromium.org>
Commit-Queue: Ali Juma <ajuma@chromium.org>
Cr-Commit-Position: refs/heads/master@{#611104}
[modify] https://crrev.com/de7a28aa6d2424863bf4feb7f54206ba61fbbf84/ios/web/web_state/ui/crw_web_controller.mm

This issue has been verified and found fixed.


Version: Chrome Canary 73.0.3629.0 
iOS Version: 11.4.1
Device: iPad Air