Reland "Fix touch keyboard occluding focused element inside OOPIF"
Fix flakiness in test by eliminating part of the test that waits for the
child iframe to scroll to 0,0. Flakiness was reproduced locally by
running 4 instances of the test in parallel 100 times with 1 to 3 hangs
observed around the mentioned wait for each run.
With this fix over 3 runs of the 4 x 100 parallel passes the hang has
not occurred.
This is a reland of 71451623b7e99218bda90366da987240db75ff2f
Original change's description:
> Fix touch keyboard occluding focused element inside OOPIF
>
> In windows when an input element inside an OOPIF is given focus the on
> screen keyboard occludes the focused element, instead of scrolling it
> into view.
>
> In response to the On Screen Keyboard (OSK) becoming visible, the top
> level frame has an inset set on it to shrink the visual viewport by the
> area occupied by the OSK.
>
> The browser process was routing the SynchronizeVisualProperties message
> which informs of the updated visual viewport to the top level frame's
> renderer process since that is where the inset needs to be set.
>
> The main frame would fail to scroll the focused element when it
> discovers that the focused element is in different process (a
> cross-process frame).
>
> This change scrolls the focused element into view by hooking into the
> OnRenderFrameMetadataChangedBeforeActivation callback in the browser
> process and calling ScrollFocusedEditableNodeIntoRect which
> correctly routes the scroll message to the focused frame.
>
> Another effect of the focused framed being in another process is that
> DidChangeVisibleViewport(); which gets called by
> RenderWidget::OnSynchronizeVisualProperties on all the
> RenderWidget::render_frames_ does not get called because OOPIF frames
> are tracked in RenderWidget::render_frame_proxies_.
>
> DidChangeVisibleViewport resets a flag that informs
> ScrollFocusedEditableElementIntoRect to attempt scrolling the focused
> element into view. In order to compensate for this,
> FrameInputHandlerImpl::ScrollFocusedEditableNodeIntoRect calls
> ResetHasScrolledFocusedEditableIntoView.
>
> Bug: 927483
> Change-Id: Ie702aaa3fabc76498a0f685f89208c1fd2707140
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1449100
> Reviewed-by: Ken Buchanan <[email protected]>
> Reviewed-by: Stefan Zager <[email protected]>
> Reviewed-by: David Bokan <[email protected]>
> Reviewed-by: Jonathan Ross <[email protected]>
> Commit-Queue: Sushanth Rajasankar <[email protected]>
> Cr-Commit-Position: refs/heads/master@{#639375}
Bug: 927483
Change-Id: I033003f4fba82c3ff98aa1224f035e23a2de29fc
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1518853
Commit-Queue: Sushanth Rajasankar <[email protected]>
Reviewed-by: Jonathan Ross <[email protected]>
Reviewed-by: Stefan Zager <[email protected]>
Reviewed-by: Charlie Reis <[email protected]>
Cr-Commit-Position: refs/heads/master@{#641623}diff --git a/content/renderer/render_frame_impl.h b/content/renderer/render_frame_impl.h
index 49bd9bd..acd45e2 100644
--- a/content/renderer/render_frame_impl.h
+++ b/content/renderer/render_frame_impl.h
@@ -957,7 +957,7 @@
void SyncSelectionIfRequired();
void ScrollFocusedEditableElementIntoRect(const gfx::Rect& rect);
- void DidChangeVisibleViewport();
+ void ResetHasScrolledFocusedEditableIntoView();
// Called to notify a frame that it called |window.focus()| on a different
// frame.
