I met with David today and seemingly the proper fix would be trying to reuse ScrollRectIntoVisible() logic with added state for the zoom part so that the root layer can eventually zoom into the rect.

This I guess would take sometime to fix but for now I have a smaller fix which will fire up the recursive scrolling. With this I am expecting the behaviro on Desktop should be correct. But on Android it might not be as good given that we are not zooming.

To elaborate on my thoughts: we have many disparate "scroll into view" type functions that basically want the same thing but with slight tweaks -- should it recurse into parent frames? should we zoom? which edge to align it to?.

Rather than OOPIFying all these different paths, we should implement one path with an API that's customizable enough for the full variety of callers.

In this case, Ehsan's already OOPIFied LayoutBox::ScrollIntoView. It's less work and better code to just extend that method to take these kinds of options and use it in ScrollFocusedEditableNodeIntoRect's implementation.

Sounds like a good plan.  Would this be something we could target for M64, or will it require more work than that?  (We're aiming to get high priority input bugs resolved by then if possible.)

Friendly ping.  We'd like to target M64 if possible, which branches Thurs, Nov 30.

For now there is a CL under review:
https://chromium-review.googlesource.com/c/chromium/src/+/772430

which would enable auto scrolling the editable node into view for all platforms. However, it will not zoom automatically which is perhaps important on Android. The has to be fixed in a follow up CL. 

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

commit bd2cea9938b9e7fcde79721c4717e923fd9e7816
Author: EhsanK <ekaramad@chromium.org>
Date: Thu Nov 23 18:49:08 2017

Make ScrollFocusedEditableNodeIntoRect work with OOPIFs

This CL introduces a temporary fix for ScrollFocusedEditableNodeIntoRect. This
command which is issued by the browser for various input and IME related tasks
(on touch platforms only) is expected to scale and scroll the current editable
element into view. The legacy implementation lives in RenderViewImpl and
WebViewImpl. This, however, is no longer relevant.

The change involves two major parts:
  1) Bookkeeping of whether scrolling for a focused node was complete (OOPIFs).
  2) Actually scrolling the focused editable node into view.

The first part was potentially broken for OOPIFs because
RenderViewImpl::ScrollFocusedEditableNodeIntoRect would not complete all its
tasks if WebView::ScrollFocusedEditableNodeIntoRect would return false; and it
would return false for OOPIFs due to MainFrameImpl() == nullptr.

The second part of the change is the major problem here since editable elements
inside OOPIFs were not actually being scrolled at all. The core cause is that
this API require finding a proper zoom and scroll point for each element and
then set the scroll top accordingly. This is not directly applicable to OOPIFs
(at least not trivially) given that OOPIFs do not know their root-layer
coordinates in the renderer and furthermore, they cannot directly scroll
themselves in the parent process.

To temporarily resolve the second problem, this CL uses the best approximation
at hand for the desired behavior, that is, scrolling the focused editable node
into view through recursive scrolling of a rectangle to visible. The behavior,
at least when PageScaleFactor() == 1, is reasonably close to that of in-process
frames.

The CL also adds a browser test to make sure the implemented feature works as
expected.

Bug:  676037 ,  784982 
Change-Id: Id27db87237c52084d19c69010caba03183e37d5f
Reviewed-on: https://chromium-review.googlesource.com/772430
Reviewed-by: Rick Byers <rbyers@chromium.org>
Reviewed-by: David Bokan <bokan@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Commit-Queue: Ehsan Karamad <ekaramad@chromium.org>
Cr-Commit-Position: refs/heads/master@{#518995}
[modify] https://crrev.com/bd2cea9938b9e7fcde79721c4717e923fd9e7816/content/browser/site_per_process_browsertest.cc
[modify] https://crrev.com/bd2cea9938b9e7fcde79721c4717e923fd9e7816/content/renderer/input/frame_input_handler_impl.cc
[modify] https://crrev.com/bd2cea9938b9e7fcde79721c4717e923fd9e7816/content/renderer/render_frame_impl.cc
[modify] https://crrev.com/bd2cea9938b9e7fcde79721c4717e923fd9e7816/content/renderer/render_frame_impl.h
[modify] https://crrev.com/bd2cea9938b9e7fcde79721c4717e923fd9e7816/content/renderer/render_view_impl.cc
[modify] https://crrev.com/bd2cea9938b9e7fcde79721c4717e923fd9e7816/content/renderer/render_view_impl.h
[modify] https://crrev.com/bd2cea9938b9e7fcde79721c4717e923fd9e7816/content/renderer/render_widget.cc
[rename] https://crrev.com/bd2cea9938b9e7fcde79721c4717e923fd9e7816/content/test/data/iframe_out_of_view.html
[modify] https://crrev.com/bd2cea9938b9e7fcde79721c4717e923fd9e7816/content/test/data/page_with_input_field.html
[modify] https://crrev.com/bd2cea9938b9e7fcde79721c4717e923fd9e7816/third_party/WebKit/Source/core/exported/WebFrameTest.cpp
[modify] https://crrev.com/bd2cea9938b9e7fcde79721c4717e923fd9e7816/third_party/WebKit/Source/core/exported/WebViewImpl.cpp
[modify] https://crrev.com/bd2cea9938b9e7fcde79721c4717e923fd9e7816/third_party/WebKit/Source/core/exported/WebViewImpl.h
[modify] https://crrev.com/bd2cea9938b9e7fcde79721c4717e923fd9e7816/third_party/WebKit/Source/core/frame/VisualViewportTest.cpp
[modify] https://crrev.com/bd2cea9938b9e7fcde79721c4717e923fd9e7816/third_party/WebKit/public/web/WebView.h

Just a quick update on the final status of the issue after comment#7:

Currently, on all platforms, ScrollFocusedEditableElementIntoView() should scroll the element as expected. However, it does not zoom into the rect if the rectangle is inside an OOPIF.

I think to zoom into the rect (reasonably similar to the non-OOPIF behavior) should not be too complicated. But making the scrolling and zooming behavior identical between OOPIFs and non-OOPIFs might be much harder.

Is supporting zoom a priority for M64?

If we can make zoom reasonably functional in M64 (if not identical to the non-OOPIF case), that would be great.  We can try for parity in a later milestone.  Can we aim for that?

I think it should be doable and we should have enough time for that.

BTW as I understand the missing "zoom logic" for OOPIF's ScrollFocusedEditablElementIntoView() only affects Android devices:
https://cs.chromium.org/chromium/src/content/renderer/render_view_impl.cc?rcl=44a83d1de950065d946c6f37249e89a3abae41cc&l=894

Comment 11: If zoom only matters on Android and if that's the only thing remaining, then I suppose this isn't high priority for M64.  We're mainly focusing on desktop cases at the moment.

Can you help confirm what's working now and what isn't?  This bug is listed as blocking  issue 676037 , and comment 1 there says:
"Some potential use cases of this feature are OSK in Android, Windows, and ChromeKeyboardUI."

I wonder if it's easier to file a new bug for what's remaining between these two bugs, and close these out?  That seems like it would make sense if things work on desktop and only Android work is remaining.

csreis@: AFAIK the scale part is used for zooming into the text box. For that the calculated |new_scale| needs to be different from PageScaleFactor(). This seems only possible on Android. Also, I could not trigger any sort of scaling for this method (non-OOPIF case) on Windows.

So in summary, we do not need the scaling part for desktops.

I will remove the dependency on 676037 and close that bug once I can confirm the scrolling is happening as expected on all platforms. I am trying ChromeOS now. I will post updates to 676037.

This bug should stay open until we figure out a same codepath for OOPIF and non-OOPIF scrolling.

Just to confirm, the scaling part is only used on Android. I suspect making it work for OOPIF shouldn't be hard but splitting that out separately sgtm.

Currently the one obstacle I see is that PageScaleFactor() returns 1.0 for OOPIFs which could be due to this line:
https://cs.chromium.org/chromium/src/content/renderer/render_widget.cc?rcl=8bcab9a2ed2e8974912c0d88a1edbdc8b91c7af2&l=974

and the fact that ApplyViewportDeltas is not implemented for OOPIFs. I still think supporting zoom requires some nontrivial hacks: both to somehow get the scale calculation logic (for zoom) right, and also the API for LayoutBox::ScrollRectToVisibleRecursive (essentially we might need to pass a boolean and a float for scaling along all recursions to be used only by the MainFrame's WebViewImpl for final zoom).

Nonetheless I am working on a patch to fix it but not quite sure what the best design would look like.

The only frame that needs to/can zoom is the main frame. The solution as I see it would be for ScrollRectToVisibleRecursive realise it's in the main frame and it needs to zoom - then just make the call from there to perform the zoom.

Agreed. But still we need to ship "scale" form renderer to main frame. Scale comes form caret bounds and element bounds which are not available in the parent process.

So to pass the scale upwards to parent it sounds reasonable to get the current remote scrolling IPC piggyback the value. WebRemoteScrollProperties is unwrapped into args needed for LayoutBox::ScrollRectToVisibleRecursive. But adding another couple of args for supporting zoom to that method does look hacky (since the logic in recursive scroll never uses it).

I am working on patch. Perhaps we could discuss the design issues there (once completed).

happy to discuss in the patch.

Though, it's not scale that you'd be passing up, it's the "target" rect in the child's coordinate space, right?

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

commit 0e5d469e5aaf3ed3b57a80b1b46ba3148f40db0b
Author: Ehsan Karamad <ekaramad@chromium.org>
Date: Tue Jan 16 21:32:48 2018

[refactor] - Change Recursive Scrolling Methods Signature to Take a WebScrollIntoViewParams instead

The methods related to recursive scroll, namely:
  1- LayoutBox::ScrollIntoVisibleRecursive
  2- LayoutObject::ScrollIntoVisible
  3- ScrollableArea::ScrollIntoView

have so many arguments. Ir makes sense to wrap them all inside a wrapper
struct.

We currently use WebRemoteScrollProperties to pass along the recursive
scroll params to the browser and parent process. The same struct could
be reused to simplify the method signature for the methods involved.
However, since they would all serve the purpose of recursive scrolling,
a rename to WebScrollIntoViewParams makes sense as well.

Bug:  784982 
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2
Change-Id: I9cb957db45bd0db1f980629955ab9db8d6abbc48
Reviewed-on: https://chromium-review.googlesource.com/849088
Reviewed-by: Ken Buchanan <kenrb@chromium.org>
Reviewed-by: Kent Tamura <tkent@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Reviewed-by: David Bokan <bokan@chromium.org>
Commit-Queue: Ehsan Karamad <ekaramad@chromium.org>
Cr-Commit-Position: refs/heads/master@{#529503}
[modify] https://crrev.com/0e5d469e5aaf3ed3b57a80b1b46ba3148f40db0b/content/browser/DEPS
[modify] https://crrev.com/0e5d469e5aaf3ed3b57a80b1b46ba3148f40db0b/content/browser/frame_host/render_frame_host_impl.cc
[modify] https://crrev.com/0e5d469e5aaf3ed3b57a80b1b46ba3148f40db0b/content/browser/frame_host/render_frame_host_impl.h
[modify] https://crrev.com/0e5d469e5aaf3ed3b57a80b1b46ba3148f40db0b/content/browser/frame_host/render_frame_proxy_host.cc
[modify] https://crrev.com/0e5d469e5aaf3ed3b57a80b1b46ba3148f40db0b/content/browser/frame_host/render_frame_proxy_host.h
[modify] https://crrev.com/0e5d469e5aaf3ed3b57a80b1b46ba3148f40db0b/content/common/DEPS
[modify] https://crrev.com/0e5d469e5aaf3ed3b57a80b1b46ba3148f40db0b/content/common/frame_messages.h
[modify] https://crrev.com/0e5d469e5aaf3ed3b57a80b1b46ba3148f40db0b/content/renderer/render_frame_impl.cc
[modify] https://crrev.com/0e5d469e5aaf3ed3b57a80b1b46ba3148f40db0b/content/renderer/render_frame_impl.h
[modify] https://crrev.com/0e5d469e5aaf3ed3b57a80b1b46ba3148f40db0b/content/renderer/render_frame_proxy.cc
[modify] https://crrev.com/0e5d469e5aaf3ed3b57a80b1b46ba3148f40db0b/content/renderer/render_frame_proxy.h
[modify] https://crrev.com/0e5d469e5aaf3ed3b57a80b1b46ba3148f40db0b/third_party/WebKit/Source/core/dom/Element.cpp
[modify] https://crrev.com/0e5d469e5aaf3ed3b57a80b1b46ba3148f40db0b/third_party/WebKit/Source/core/editing/Editor.cpp
[modify] https://crrev.com/0e5d469e5aaf3ed3b57a80b1b46ba3148f40db0b/third_party/WebKit/Source/core/editing/Editor.h
[modify] https://crrev.com/0e5d469e5aaf3ed3b57a80b1b46ba3148f40db0b/third_party/WebKit/Source/core/editing/FrameSelection.cpp
[modify] https://crrev.com/0e5d469e5aaf3ed3b57a80b1b46ba3148f40db0b/third_party/WebKit/Source/core/editing/FrameSelection.h
[modify] https://crrev.com/0e5d469e5aaf3ed3b57a80b1b46ba3148f40db0b/third_party/WebKit/Source/core/editing/finder/TextFinder.cpp
[modify] https://crrev.com/0e5d469e5aaf3ed3b57a80b1b46ba3148f40db0b/third_party/WebKit/Source/core/exported/LocalFrameClientImpl.cpp
[modify] https://crrev.com/0e5d469e5aaf3ed3b57a80b1b46ba3148f40db0b/third_party/WebKit/Source/core/exported/LocalFrameClientImpl.h
[modify] https://crrev.com/0e5d469e5aaf3ed3b57a80b1b46ba3148f40db0b/third_party/WebKit/Source/core/exported/WebRemoteFrameImpl.cpp
[modify] https://crrev.com/0e5d469e5aaf3ed3b57a80b1b46ba3148f40db0b/third_party/WebKit/Source/core/exported/WebRemoteFrameImpl.h
[modify] https://crrev.com/0e5d469e5aaf3ed3b57a80b1b46ba3148f40db0b/third_party/WebKit/Source/core/exported/WebViewImpl.cpp
[modify] https://crrev.com/0e5d469e5aaf3ed3b57a80b1b46ba3148f40db0b/third_party/WebKit/Source/core/frame/LocalFrameClient.h
[modify] https://crrev.com/0e5d469e5aaf3ed3b57a80b1b46ba3148f40db0b/third_party/WebKit/Source/core/frame/LocalFrameView.cpp
[modify] https://crrev.com/0e5d469e5aaf3ed3b57a80b1b46ba3148f40db0b/third_party/WebKit/Source/core/frame/LocalFrameView.h
[modify] https://crrev.com/0e5d469e5aaf3ed3b57a80b1b46ba3148f40db0b/third_party/WebKit/Source/core/frame/RootFrameViewport.cpp
[modify] https://crrev.com/0e5d469e5aaf3ed3b57a80b1b46ba3148f40db0b/third_party/WebKit/Source/core/frame/RootFrameViewport.h
[modify] https://crrev.com/0e5d469e5aaf3ed3b57a80b1b46ba3148f40db0b/third_party/WebKit/Source/core/frame/RootFrameViewportTest.cpp
[modify] https://crrev.com/0e5d469e5aaf3ed3b57a80b1b46ba3148f40db0b/third_party/WebKit/Source/core/html/forms/HTMLInputElement.cpp
[modify] https://crrev.com/0e5d469e5aaf3ed3b57a80b1b46ba3148f40db0b/third_party/WebKit/Source/core/layout/BUILD.gn
[modify] https://crrev.com/0e5d469e5aaf3ed3b57a80b1b46ba3148f40db0b/third_party/WebKit/Source/core/layout/LayoutBox.cpp
[modify] https://crrev.com/0e5d469e5aaf3ed3b57a80b1b46ba3148f40db0b/third_party/WebKit/Source/core/layout/LayoutBox.h
[modify] https://crrev.com/0e5d469e5aaf3ed3b57a80b1b46ba3148f40db0b/third_party/WebKit/Source/core/layout/LayoutListBox.cpp
[modify] https://crrev.com/0e5d469e5aaf3ed3b57a80b1b46ba3148f40db0b/third_party/WebKit/Source/core/layout/LayoutObject.cpp
[modify] https://crrev.com/0e5d469e5aaf3ed3b57a80b1b46ba3148f40db0b/third_party/WebKit/Source/core/layout/LayoutObject.h
[modify] https://crrev.com/0e5d469e5aaf3ed3b57a80b1b46ba3148f40db0b/third_party/WebKit/Source/core/paint/PaintLayerScrollableArea.cpp
[modify] https://crrev.com/0e5d469e5aaf3ed3b57a80b1b46ba3148f40db0b/third_party/WebKit/Source/core/paint/PaintLayerScrollableArea.h
[modify] https://crrev.com/0e5d469e5aaf3ed3b57a80b1b46ba3148f40db0b/third_party/WebKit/Source/modules/accessibility/AXObject.cpp
[modify] https://crrev.com/0e5d469e5aaf3ed3b57a80b1b46ba3148f40db0b/third_party/WebKit/Source/modules/canvas/canvas2d/CanvasRenderingContext2D.cpp
[modify] https://crrev.com/0e5d469e5aaf3ed3b57a80b1b46ba3148f40db0b/third_party/WebKit/Source/platform/BUILD.gn
[delete] https://crrev.com/40126a62123c1e8704b2f92a6ef54eb3e6ce52db/third_party/WebKit/Source/platform/exported/WebRemoteScrollProperties.cpp
[rename] https://crrev.com/0e5d469e5aaf3ed3b57a80b1b46ba3148f40db0b/third_party/WebKit/Source/platform/scroll/ScrollAlignment.cpp
[rename] https://crrev.com/0e5d469e5aaf3ed3b57a80b1b46ba3148f40db0b/third_party/WebKit/Source/platform/scroll/ScrollAlignment.h
[modify] https://crrev.com/0e5d469e5aaf3ed3b57a80b1b46ba3148f40db0b/third_party/WebKit/Source/platform/scroll/ScrollableArea.cpp
[modify] https://crrev.com/0e5d469e5aaf3ed3b57a80b1b46ba3148f40db0b/third_party/WebKit/Source/platform/scroll/ScrollableArea.h
[add] https://crrev.com/0e5d469e5aaf3ed3b57a80b1b46ba3148f40db0b/third_party/WebKit/Source/platform/scroll/WebScrollIntoViewParams.cpp
[modify] https://crrev.com/0e5d469e5aaf3ed3b57a80b1b46ba3148f40db0b/third_party/WebKit/public/BUILD.gn
[delete] https://crrev.com/40126a62123c1e8704b2f92a6ef54eb3e6ce52db/third_party/WebKit/public/platform/WebRemoteScrollProperties.h
[add] https://crrev.com/0e5d469e5aaf3ed3b57a80b1b46ba3148f40db0b/third_party/WebKit/public/platform/WebScrollIntoViewParams.h
[modify] https://crrev.com/0e5d469e5aaf3ed3b57a80b1b46ba3148f40db0b/third_party/WebKit/public/web/WebFrameClient.h
[modify] https://crrev.com/0e5d469e5aaf3ed3b57a80b1b46ba3148f40db0b/third_party/WebKit/public/web/WebRemoteFrame.h

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

commit f2b6bb9a1b71a140652edc2b734009065e0d255f
Author: Ehsan Karamad <ekaramad@chromium.org>
Date: Fri Apr 06 17:13:14 2018

Zoom to Focused Editable Element when Element is in OOPIF

This CL adds support for zooming into the focused editable node when the
node is inside an OOPIF. The CL resolves the issue by:
  * Refactoring and renaming ComputeScaleAndScrollForFocusedNode to
  ComputeScaleAndScrollForEditableElementRects where instead of the
  element, the bounds for the element and caret are passed as arguments.
  * Calculating the rectangle to scroll considering the current element
  bounds, caret bounds, and frame rects. The calculation tries to
  include the union of element bounds and caret bounds if possible or
  otherwise, a smaller rectangle which includes the caret bound.
  * Calculating and sending the relative position of caret and element
  inside the rectangle to scroll.
  * Using the rect to scroll and the relative caret and element bounds
  with the new ComputeScaleAndScrollForEditableElement to find the
  final zoom and scroll as similarly to the in-process case as possible.

Link to design doc: https://goo.gl/2jHJUv

Bug:  784982 
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2
Change-Id: I63127abfeb31b543cc7e990bf01da77489357076
Reviewed-on: https://chromium-review.googlesource.com/830980
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Reviewed-by: Ehsan Karamad <ekaramad@chromium.org>
Reviewed-by: Ian Vollick <vollick@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Reviewed-by: David Bokan <bokan@chromium.org>
Commit-Queue: Ehsan Karamad <ekaramad@chromium.org>
Cr-Commit-Position: refs/heads/master@{#548827}
[modify] https://crrev.com/f2b6bb9a1b71a140652edc2b734009065e0d255f/content/browser/site_per_process_browsertest.cc
[modify] https://crrev.com/f2b6bb9a1b71a140652edc2b734009065e0d255f/content/common/frame_messages.h
[modify] https://crrev.com/f2b6bb9a1b71a140652edc2b734009065e0d255f/content/renderer/render_frame_impl.cc
[modify] https://crrev.com/f2b6bb9a1b71a140652edc2b734009065e0d255f/content/renderer/render_view_impl.cc
[modify] https://crrev.com/f2b6bb9a1b71a140652edc2b734009065e0d255f/content/test/data/iframe_out_of_view.html
[modify] https://crrev.com/f2b6bb9a1b71a140652edc2b734009065e0d255f/third_party/WebKit/Source/core/exported/WebFrameTest.cpp
[modify] https://crrev.com/f2b6bb9a1b71a140652edc2b734009065e0d255f/third_party/WebKit/Source/core/exported/WebRemoteFrameImpl.cpp
[modify] https://crrev.com/f2b6bb9a1b71a140652edc2b734009065e0d255f/third_party/WebKit/Source/core/exported/WebViewImpl.cpp
[modify] https://crrev.com/f2b6bb9a1b71a140652edc2b734009065e0d255f/third_party/WebKit/Source/core/exported/WebViewImpl.h
[modify] https://crrev.com/f2b6bb9a1b71a140652edc2b734009065e0d255f/third_party/WebKit/Source/core/frame/WebFrameWidgetImpl.cpp
[modify] https://crrev.com/f2b6bb9a1b71a140652edc2b734009065e0d255f/third_party/WebKit/Source/core/frame/WebFrameWidgetImpl.h
[modify] https://crrev.com/f2b6bb9a1b71a140652edc2b734009065e0d255f/third_party/WebKit/Source/core/frame/WebViewFrameWidget.cpp
[modify] https://crrev.com/f2b6bb9a1b71a140652edc2b734009065e0d255f/third_party/WebKit/Source/core/frame/WebViewFrameWidget.h
[modify] https://crrev.com/f2b6bb9a1b71a140652edc2b734009065e0d255f/third_party/WebKit/Source/platform/scroll/WebScrollIntoViewParams.cpp
[modify] https://crrev.com/f2b6bb9a1b71a140652edc2b734009065e0d255f/third_party/WebKit/public/platform/WebScrollIntoViewParams.h
[modify] https://crrev.com/f2b6bb9a1b71a140652edc2b734009065e0d255f/third_party/WebKit/public/web/WebFrameWidget.h
[modify] https://crrev.com/f2b6bb9a1b71a140652edc2b734009065e0d255f/third_party/WebKit/public/web/WebView.h

I think as far as programmatic scrolling is concerned we should be able to close this bug. There are still remaining "zoom" related features which we might want to support for OOPIFs (mentioned in bug 734209) such as ZoomToFindInPageRect. I don't believe they should overlap with ScrollIntoView. I will close this bug after verifying on Canary tomorrow.

I am going to close this bug as the issue is fixed on Android. I don't think there is any outstanding "programmatic scrolling" bugs for OOPIF.

I also attached a video for verification of fix (Pixel XL, Chrome Canary 67.0.3393.1). 

Deleted: 20180410_131527.mp4 5.8 MB

	20180410_131527.mp4 5.8 MB View Download