Bot link:
https://ci.chromium.org/buildbot/tryserver.chromium.android/android_n5x_swarming_rel/336788

I've looked at testReceivingSizeAfterLoadUpdatesLayout and it appears to be a different issue in WebViewImpl::ContentsPreferredMinimumSize. Before RLS, LayoutView->MinPreferredLogicalWidth would return the minimum intrinsic size of the LayoutView - which would effectively be the document rect. Now that LayoutView has a scroll clip, this clips the size to that clip.

I don't well understand the details of intrinsic sizes. ContentsPreferredMinimumSize.Height() uses documentElement()->ScrollHeight and using ScrollWidth for width fixes the test. Presumably the difference exists for a reason? Naively, ScrollWidth seems like what we want: "what width should we use so we don't have to scroll", but I'm probably missing some details here. Either of you have a better idea?

I think preferred minimum size is supposed to be independent of the container.  So if your document is

  <div style="width:800px">blah</div>

Then your preferred width is 800 even if the layout viewport width is only 400 (causing scrolling) or 1600 (which expands documentElement.scrollWidth).

It gets a little weird with scrollbar inclusion since overflow does depend on container... ¯\_(ツ)_/¯

I had a closer look and the issue is actually related to using ContentsSize
when the document size is what we wanted (rls turns ContentsSize() from
document size to frame size)  . That causes some code to fallback to
preferredMinimumContentWidth when it otherwise wouldn't.

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

commit 2989927f799a4e51f8b9bd08202fbd8e832b1190
Author: David Bokan <bokan@chromium.org>
Date: Tue Jan 23 15:38:37 2018

Fix uses of ContentsSize under RootLayerScrolls

In  https://crbug.com/757634 , LocalFrameView::ContentsSize was modified
to return the frame size when RootLayerScrolls is turned on. This makes
sense since the Frame's "content" is the LayoutView which is sized to
the frame and clips when RLS is turned on.

However, this is wrong if the call site really was looking for the
document/page size and the original patch missed a few call sites like
this:

 * AwRenderViewExt::CheckContentsSize is looking for changes to the
   document size so this breaks the WebView Integration tests in the bug

 * ContainerNode::GetUpperLeftCorner uses this to determine how far to
   scroll to get to the bottom of the document. This should definitely
   be the document size. Added empty-anchor.html test for this case.

 * TextFinder::UpdateFindMatchRects appears to use the changing content
   size as a signal to recompute the match rects. If we use the frame
   rect here this will never be triggered. Added to TestFinderTest to
   cover this bug.

 * WebViewImpl::WidenRectWithinPageBounds is used in a page scale
   animation (i.e. Android double-tap-to-zoom, zoom in on text input
   focus). This is trying to calculate a rect in the page to zoom and
   scroll to so it should be document rect.

Since "ContentsSize" is ambiguous at best (and misleading at worst)
I've changed the name to DocumentSize in WebLocalFrame. The FrameView
version is a member of ScrollableArea so once RLS is turned on it will
be removed when FrameView is removed from the ScrollableArea hierarchy.

Bug:  800549 
Change-Id: I5831bed046931d819c4c86751b245bc514a390f5
Reviewed-on: https://chromium-review.googlesource.com/876724
Reviewed-by: Chris Harrelson <chrishtr@chromium.org>
Reviewed-by: Bo <boliu@chromium.org>
Reviewed-by: Steve Kobes <skobes@chromium.org>
Commit-Queue: David Bokan <bokan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#531244}
[modify] https://crrev.com/2989927f799a4e51f8b9bd08202fbd8e832b1190/android_webview/renderer/aw_render_view_ext.cc
[add] https://crrev.com/2989927f799a4e51f8b9bd08202fbd8e832b1190/third_party/WebKit/LayoutTests/fast/scrolling/empty-anchor.html
[modify] https://crrev.com/2989927f799a4e51f8b9bd08202fbd8e832b1190/third_party/WebKit/Source/core/dom/ContainerNode.cpp
[modify] https://crrev.com/2989927f799a4e51f8b9bd08202fbd8e832b1190/third_party/WebKit/Source/core/editing/finder/TextFinder.cpp
[modify] https://crrev.com/2989927f799a4e51f8b9bd08202fbd8e832b1190/third_party/WebKit/Source/core/editing/finder/TextFinder.h
[modify] https://crrev.com/2989927f799a4e51f8b9bd08202fbd8e832b1190/third_party/WebKit/Source/core/editing/finder/TextFinderTest.cpp
[modify] https://crrev.com/2989927f799a4e51f8b9bd08202fbd8e832b1190/third_party/WebKit/Source/core/exported/WebViewImpl.cpp
[modify] https://crrev.com/2989927f799a4e51f8b9bd08202fbd8e832b1190/third_party/WebKit/Source/core/frame/LocalFrameView.h
[modify] https://crrev.com/2989927f799a4e51f8b9bd08202fbd8e832b1190/third_party/WebKit/Source/core/frame/WebLocalFrameImpl.cpp
[modify] https://crrev.com/2989927f799a4e51f8b9bd08202fbd8e832b1190/third_party/WebKit/Source/core/frame/WebLocalFrameImpl.h
[modify] https://crrev.com/2989927f799a4e51f8b9bd08202fbd8e832b1190/third_party/WebKit/public/web/WebLocalFrame.h