Some potential use cases of this feature are OSK in Android, Windows, and ChromeKeyboardUI.

 Issue 703800  looks resolved, so I'll remove that as blocked on this.  ekaramad@ noted that this bug is likely blocking the find-in-page scrolling in  issue 618474 , though.  Let's see if we can get this fixed in M63 if possible.  Thanks!

This also might be causing  issue 471044 .

Seems likely.  Thanks!

Some findings:
I noticed the API "element.scrollIntoView()" is currently broken for OOPIFs. The problem can be attributed to a common root cause which is not being to scroll a frame in parent process (at least not from the browser side).

I think we might need a (somewhat) general-purpose API on the browser side to scroll a frame (i.e., its corresponding frame element) inside the parent process. Then reusing such API provides the means to fix other resulted problems (scrollIntoView API, current bug, find-in-page  bug 618474 ).

Right now I am trying to answer:
a) How such scrolling can be done?
b) What is the best behavior to make it (possibly) identical to the in-process case? It gets nontrivial if we have nested OOPIFs and perhaps an identical behavior to the in-process case might not be possible.

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

commit f152db88197739be6094b050d1e59ffc724dd828
Author: Ehsan Karamad <ekaramad@chromium.org>
Date: Mon Oct 23 17:41:25 2017

Implement recursive scrolling of rect into view for OOPIFs

Functionalities such as element.scrollIntoView() API rely on recursively
scrolling LayoutBoxes until a given rectangle in view. When the LayoutObject
is that of a LocalFrameView, the scrolling is handed over to the owner
element in the parent frame. This step is currently not implemented for
OOPIFs which consequently breaks different features such as
find-in-page and element.scrollIntoView() API.

This CL adds support for recursive scroll across OOPIFs through adding
a public struct WebRemoteScrollPropteries in blink which will be passed
from a renderer process to the browser to be then forwarded to the
parent frame. The new struct along with the rectangle to be scrolled are
the missing information needed to join the scroll chain between a child
process and its parent.

The CL adds an interactive test to catch element.scrollIntoView()
regressions in OOPIFs.

Bug:  618474 ,  676037 , 734209,  768029 
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_site_isolation
Change-Id: Iff5a5b470721f1a6e3c5db5f8f1c427a52ddb31c
Reviewed-on: https://chromium-review.googlesource.com/679319
Commit-Queue: Ehsan Karamad <ekaramad@chromium.org>
Reviewed-by: Dimitri Glazkov <dglazkov@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Reviewed-by: David Bokan <bokan@chromium.org>
Reviewed-by: Ken Buchanan <kenrb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#510838}
[modify] https://crrev.com/f152db88197739be6094b050d1e59ffc724dd828/content/browser/DEPS
[modify] https://crrev.com/f152db88197739be6094b050d1e59ffc724dd828/content/browser/frame_host/render_frame_host_impl.cc
[modify] https://crrev.com/f152db88197739be6094b050d1e59ffc724dd828/content/browser/frame_host/render_frame_host_impl.h
[modify] https://crrev.com/f152db88197739be6094b050d1e59ffc724dd828/content/browser/frame_host/render_frame_proxy_host.cc
[modify] https://crrev.com/f152db88197739be6094b050d1e59ffc724dd828/content/browser/frame_host/render_frame_proxy_host.h
[modify] https://crrev.com/f152db88197739be6094b050d1e59ffc724dd828/content/browser/site_per_process_browsertest.cc
[modify] https://crrev.com/f152db88197739be6094b050d1e59ffc724dd828/content/common/DEPS
[modify] https://crrev.com/f152db88197739be6094b050d1e59ffc724dd828/content/common/frame_messages.h
[modify] https://crrev.com/f152db88197739be6094b050d1e59ffc724dd828/content/renderer/render_frame_impl.cc
[modify] https://crrev.com/f152db88197739be6094b050d1e59ffc724dd828/content/renderer/render_frame_impl.h
[modify] https://crrev.com/f152db88197739be6094b050d1e59ffc724dd828/content/renderer/render_frame_proxy.cc
[modify] https://crrev.com/f152db88197739be6094b050d1e59ffc724dd828/content/renderer/render_frame_proxy.h
[add] https://crrev.com/f152db88197739be6094b050d1e59ffc724dd828/content/test/data/bounding_rect_for_frame.html
[modify] https://crrev.com/f152db88197739be6094b050d1e59ffc724dd828/third_party/WebKit/Source/core/exported/LocalFrameClientImpl.cpp
[modify] https://crrev.com/f152db88197739be6094b050d1e59ffc724dd828/third_party/WebKit/Source/core/exported/LocalFrameClientImpl.h
[modify] https://crrev.com/f152db88197739be6094b050d1e59ffc724dd828/third_party/WebKit/Source/core/exported/WebRemoteFrameImpl.cpp
[modify] https://crrev.com/f152db88197739be6094b050d1e59ffc724dd828/third_party/WebKit/Source/core/exported/WebRemoteFrameImpl.h
[modify] https://crrev.com/f152db88197739be6094b050d1e59ffc724dd828/third_party/WebKit/Source/core/frame/LocalFrameClient.h
[modify] https://crrev.com/f152db88197739be6094b050d1e59ffc724dd828/third_party/WebKit/Source/core/frame/LocalFrameView.cpp
[modify] https://crrev.com/f152db88197739be6094b050d1e59ffc724dd828/third_party/WebKit/Source/core/frame/LocalFrameView.h
[modify] https://crrev.com/f152db88197739be6094b050d1e59ffc724dd828/third_party/WebKit/Source/core/layout/LayoutBox.cpp
[modify] https://crrev.com/f152db88197739be6094b050d1e59ffc724dd828/third_party/WebKit/Source/core/layout/ScrollAlignment.h
[modify] https://crrev.com/f152db88197739be6094b050d1e59ffc724dd828/third_party/WebKit/Source/platform/BUILD.gn
[add] https://crrev.com/f152db88197739be6094b050d1e59ffc724dd828/third_party/WebKit/Source/platform/exported/WebRemoteScrollProperties.cpp
[modify] https://crrev.com/f152db88197739be6094b050d1e59ffc724dd828/third_party/WebKit/public/BUILD.gn
[add] https://crrev.com/f152db88197739be6094b050d1e59ffc724dd828/third_party/WebKit/public/platform/WebRemoteScrollProperties.h
[modify] https://crrev.com/f152db88197739be6094b050d1e59ffc724dd828/third_party/WebKit/public/web/WebFrameClient.h
[modify] https://crrev.com/f152db88197739be6094b050d1e59ffc724dd828/third_party/WebKit/public/web/WebRemoteFrame.h

ekaramad@: Thanks for landing 510838!  Is that sufficient for closing this bug, or is there more work required?

|element.scrollIntoView()| is fixed and therefore this bug mostly fixed. However, there is still issues to address specifically to implement:
https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/exported/WebViewImpl.cpp?rcl=3dd37486c25aa78b96f844167e72eafd7d3990c5&l=2513

for OOPIF.

So in short I think we should keep this open for now. But I don't think it is blocking  issue 618474 .

In fact, the fix in comment #8 does not resolve the issue. So this bug has to stay open. I will take another look at the method to see what it would take to implemented it OOPIFs.

I have been digging into this issue and trying to find a way to adapt this to OOPIFs. Unfortunately the fix does not seem to be trivial. Specifically for scrolling focused editable element into rect we actually ignore the rect and work with caret and text area positions in the document. Then a scale for zoom and scroll point are calculated (ComputeScaleAndScrollForFocusedElement).

Essentially the approach requires information such as caret bounds which are only available on the browser side (for OOPIFs) and furthermore scrolls the page by setting scroll top which cannot be easily broken into some scrolling  in the OOPIF process and some more in the parent process etc (i.e., the same as scrollIntoView()).

That being said, we could approximate the behavior (minus the zooming part) by trying to scroll a small rect in the editable area into view.

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

As of comment 14 scrolling should work as in 'the elements bounds should scroll into view'. This however does not include the automatic zooming for android. That feature is being tracked in  issue 784982  wwhich tracks all programmatic scrolls for OOPIFs. So I am closing this issue.