FWIW similar issue in the past:  issue 732714 

Nice catch Satoru!
This is a regression, on latest dev (64.0.3282.24) it doesn't happen. See attachment

Deleted: Working on 64 dev.webm 2.6 MB

	Working on 64 dev.webm 2.6 MB View Download

TL;DR: race between two IPCs, I believe.


Took a quick look. Two things are happening here.

(1) Resize the visible region of the view.
(2) Scroll.

The renderer-side implementation of scrolling is RenderFrameImpl::ScrollFocusedEditableElementIntoRect
https://cs.chromium.org/chromium/src/content/renderer/render_frame_impl.cc?type=cs&sq=package:chromium&l=6639
which does not use the passed |rect| parameter.
Instead, it does ScrollFocusedEditableElementIntoView(), scroll the focused element to the visible region.
Which implicitly assuming that the step 1 (resize) is already happening before.



Now, turning our eyes to the browser process side.

The 1st step, RenderWidgetHostViewAura::SetInsets
https://cs.chromium.org/chromium/src/content/browser/renderer_host/render_widget_host_view_aura.cc?type=cs&q=ScrollFocusedEditableNodeIntoRect&l=788
https://cs.chromium.org/chromium/src/content/browser/renderer_host/render_widget_host_impl.cc?type=cs&l=825
is a Send(ViewMsg_Resize) Chrome IPC.

The 2nd step, RenderWidgetHostViewAura::ScrollFocusedEditableNodeIntoRect
https://cs.chromium.org/chromium/src/content/browser/renderer_host/render_widget_host_view_aura.cc?type=cs&q=ScrollFocusedEditableNodeIntoRect&l=2461
https://cs.chromium.org/chromium/src/content/common/input/input_handler.mojom?l=324
now seems to be a Mojo IPC (crbug.com/722928).

I don't think there's no order assurance between these two channels... I added log and saw that when the bug is reproduced, Scroll() was run first and then Resize(), indeed.

+dtapuska, who are working on migration to mojo

Do you have any ideas to fix this issue?

No I have no ideas. All the mojo work is in 64 branch so it can't be that.

The bug reproduces on 64 (screen record attached (using gmail, it also occurs on Files app too)), so I believe that is it.

It only happens probabilistically (~50% of time). I think Omri in #3 was too lucky to hit the bug.

Deleted: VID_20180110_093505.mp4 6.1 MB

	VID_20180110_093505.mp4 6.1 MB View Download

dtapuska@, could you take a look since this seems to be a regression caused by the migration to mojo? Virtual keyboard is pretty much unusable with this issue.

Is it a practical option to move ScrollFocusedEditableElementIntoView() to ViewMsg (Chrome IPC)?

Within the Chrome IPC the order should be assured to be same on the sender and the receiver side,
and IIUC, it'll continue being so even after it migrated to Mojo in the future (as long as all the ViewMsgs are sent through the same Mojo instance.)
Since what ScrollFocusedEditableElementIntoView() does is totally about scrolling the view, I think it conceptually matches to reside in ViewMsg.

Likely it an inputmsg because set focus is an input message and it needs to
be in order with that. Inputmsgs were never guaranteed to be delivered in
order with other chrome ipcs. There is an input event filter that sends all
input msgs to the compositor thread. So this bug probably existed before
but might just be more reproducible now?

I'd prefer if we added an arg to Resize params that indicated scroll focused editiable element should be moved into view. Do you think that would work? And then we can in fact get rid of the additional IPC?

Adding an arg to Resize params should work. RWHVA::SetInsets is used only by virtual keyboard related code, so it makes sense to ask scroll to focused element when SetInsets is called with non-empty bounds. 

I think other platforms (win/andorid at least) may have the same issue if this is ipc related. just fyi to dtapuska@.

Per offline discussion with leads - marking as release blocker.

I've posted a fix here: https://chromium-review.googlesource.com/c/chromium/src/+/861752

Just need to get it reviewed.

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

commit 736974990a7d10c4c0c973ada0802ede116feadf
Author: Dave Tapuska <dtapuska@chromium.org>
Date: Fri Jan 12 22:02:10 2018

Fix node visibility when showing the virtual keyboard.

Showing the virtual keyboard was dependent on the ordering of two
separate IPC messages. ViewMessage_Resize and
InputMessage_ScrollFocusedEditableNodeIntoRect. These messages have never
had guaranteed orderering because Input messages were always filtered out
to the compositor thread. However they usually occurred in order by fluke.
With the move to mojo for input messages this reduced the delivery time
and it appears that input mesages are arriving before the chrome IPC
messages causing the focus to be moved before hand. To fix this ensure
that when we resize the control we allow the focus to be moved. This
avoids the race of two IPC messages. This change is mimimal as it is
intended to be merged into M64; it maybe possible to not to dispatch
the second IPC however for risk it is not done.

BUG= 796808 

Change-Id: I50613bcc1ae85cd3f2c77ce2e1162a1a0306f648
Reviewed-on: https://chromium-review.googlesource.com/861752
Commit-Queue: Dave Tapuska <dtapuska@chromium.org>
Reviewed-by: Ken Buchanan <kenrb@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Cr-Commit-Position: refs/heads/master@{#529080}
[modify] https://crrev.com/736974990a7d10c4c0c973ada0802ede116feadf/content/browser/renderer_host/render_widget_host_impl.cc
[modify] https://crrev.com/736974990a7d10c4c0c973ada0802ede116feadf/content/browser/renderer_host/render_widget_host_impl.h
[modify] https://crrev.com/736974990a7d10c4c0c973ada0802ede116feadf/content/browser/renderer_host/render_widget_host_view_aura.cc
[modify] https://crrev.com/736974990a7d10c4c0c973ada0802ede116feadf/content/common/resize_params.cc
[modify] https://crrev.com/736974990a7d10c4c0c973ada0802ede116feadf/content/common/resize_params.h
[modify] https://crrev.com/736974990a7d10c4c0c973ada0802ede116feadf/content/common/view_messages.h
[modify] https://crrev.com/736974990a7d10c4c0c973ada0802ede116feadf/content/renderer/render_view_impl.cc

Can we get TE verification on this issue so we can merge it?

[Auto-generated comment by a script] We noticed that this issue is targeted for M-64; it appears the fix may have landed after branch point, meaning a merge might be required. Please confirm if a merge is required here - if so add Merge-Request-64 label, otherwise remove Merge-TBD label. Thanks.

This bug requires manual review: We are only 7 days from stable.
Please contact the milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), kbleicher@(ChromeOS), abdulsyed@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Tested this issue on latest M-65 using 65.0.3322.0/10312.0.0 dev channel Candy,Minnie as per the steps mentioned in comment 0. Observed that the issue is working as expected i.e,the Virtual Keyboard shows up and the text field moves up. 
Hence adding TE-Verified labels.Attached the screencast for reference.

Note: I was able to reproduce the issue on reported version 65.0.3299.0/10237.0.0 dev channel Candy.

Thank you!

Deleted: 796808.webm 1.3 MB

	796808.webm 1.3 MB View Download

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

commit b7040e0bd25998bf16cae683de3b575dc18d7c26
Author: Dave Tapuska <dtapuska@chromium.org>
Date: Tue Jan 16 18:17:58 2018

Fix node visibility when showing the virtual keyboard.

Showing the virtual keyboard was dependent on the ordering of two
separate IPC messages. ViewMessage_Resize and
InputMessage_ScrollFocusedEditableNodeIntoRect. These messages have never
had guaranteed orderering because Input messages were always filtered out
to the compositor thread. However they usually occurred in order by fluke.
With the move to mojo for input messages this reduced the delivery time
and it appears that input mesages are arriving before the chrome IPC
messages causing the focus to be moved before hand. To fix this ensure
that when we resize the control we allow the focus to be moved. This
avoids the race of two IPC messages. This change is mimimal as it is
intended to be merged into M64; it maybe possible to not to dispatch
the second IPC however for risk it is not done.

BUG= 796808 
TBR=dtapuska@chromium.org

(cherry picked from commit 736974990a7d10c4c0c973ada0802ede116feadf)

Change-Id: I50613bcc1ae85cd3f2c77ce2e1162a1a0306f648
Reviewed-on: https://chromium-review.googlesource.com/861752
Commit-Queue: Dave Tapuska <dtapuska@chromium.org>
Reviewed-by: Ken Buchanan <kenrb@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#529080}
Reviewed-on: https://chromium-review.googlesource.com/867940
Reviewed-by: Dave Tapuska <dtapuska@chromium.org>
Cr-Commit-Position: refs/branch-heads/3282@{#507}
Cr-Branched-From: 5fdc0fab22ce7efd32532ee989b223fa12f8171e-refs/heads/master@{#520840}
[modify] https://crrev.com/b7040e0bd25998bf16cae683de3b575dc18d7c26/content/browser/renderer_host/render_widget_host_impl.cc
[modify] https://crrev.com/b7040e0bd25998bf16cae683de3b575dc18d7c26/content/browser/renderer_host/render_widget_host_impl.h
[modify] https://crrev.com/b7040e0bd25998bf16cae683de3b575dc18d7c26/content/browser/renderer_host/render_widget_host_view_aura.cc
[modify] https://crrev.com/b7040e0bd25998bf16cae683de3b575dc18d7c26/content/common/resize_params.cc
[modify] https://crrev.com/b7040e0bd25998bf16cae683de3b575dc18d7c26/content/common/resize_params.h
[modify] https://crrev.com/b7040e0bd25998bf16cae683de3b575dc18d7c26/content/common/view_messages.h
[modify] https://crrev.com/b7040e0bd25998bf16cae683de3b575dc18d7c26/content/renderer/render_view_impl.cc