Toni, can you please assign it to the right team?

For reference here is expected result with the same web app inside an iOS native app webview and the iPad virtual keyboard behaviour: https://goo.gl/photos/3Vu9wA3Jn49MoVN9A

Given that Xiyuan is OOO until Aug 8th, is there anyone else that can look into this?

Given this is a P3, no one would be looking into this till Aug 8th anyway.

Any news on this bug? It is still an issue but we have made a work around for now.

This occurs because the insets are being set on the browser guest, rather than the main frame, but RenderWidgetHostViewChildFrame doesn't implement SetInsets. I've got a fix in the works.

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

commit aa2b51bb70b765dc029013ed5f3448f45f484a49
Author: David Bokan <bokan@chromium.org>
Date: Fri Mar 30 00:10:34 2018

Make WebView guest account for insets

Insets are used to resize the visual viewport of a renderer when the
virtual keyboard appears, without resizing the widget geometry. For
a <webview>, this plumbing was missing. This led to the virtual
keyboard not allowing overscroll or scrolling focused input fields into
view when the content is in a <webview>.

Bug:  740223 
Change-Id: I62837fb09ae7b3590c198643259daf407028d8b6
Reviewed-on: https://chromium-review.googlesource.com/985020
Commit-Queue: David Bokan <bokan@chromium.org>
Reviewed-by: Ken Buchanan <kenrb@chromium.org>
Reviewed-by: James MacLean <wjmaclean@chromium.org>
Cr-Commit-Position: refs/heads/master@{#547035}
[modify] https://crrev.com/aa2b51bb70b765dc029013ed5f3448f45f484a49/chrome/browser/apps/guest_view/web_view_browsertest.cc
[modify] https://crrev.com/aa2b51bb70b765dc029013ed5f3448f45f484a49/content/browser/renderer_host/render_widget_host_view_child_frame.cc
[modify] https://crrev.com/aa2b51bb70b765dc029013ed5f3448f45f484a49/content/browser/renderer_host/render_widget_host_view_child_frame.h

This should be fixed in the next Canary (67.0.3386.0 and newer). Please give it a try and let me know if something's still broken.

Thanks David! We'll try out the next Canary and let you know if there is any concerns.

https://media.giphy.com/media/GCLlQnV7wzKLu/giphy.gif
https://media.giphy.com/media/iPTTjEt19igne/giphy.gif

Is it possible, that this bug is still present in win 10 tablet mode?

I always have to undock the onscreen keyboard, if there is an input element at the bottom of a page. 

David, this change has some tricky interactions with a fix I am working on for issue 865774 where the virtual keyboard interacts badly with a webview in the CrOS FilesApp drive share file dialog.

I can see how this change made sense for a fullscreen webview.  In my case, I have a webview which is in a dialog shown in the middle of the screen.  When a user clicks on a text input in the webview, the virtual keyboard is shown.  Currently the keyboard clips the bottom of the dialog/webview and we call RenderWidgetHostViewChildFrame::SetInset.

When I detect the VisualViewport resize event, I then recenter the dialog vertically, and the webview is still clipped at the bottom.  It looks to be a bit tricky to fix the code to handle this case.  My code would work much better if we reverted this change to not ever set insets for a webview.

An alternative to this change for the fullscreen webview in the kiosk app from #c1 is to have the parent page of the webview listen to the Visual Viewport resize event and resize the webview.

 window.visualViewport.addEventListener('resize', () => {
   document.querySelector('#browser0 webview').style.height = window.visualViewport.height + 'px';
 });

I see you are OOO right now.  Maybe we can catch up next week.

Hm, I was under the impression insets only get set when the app is fullscreen so I guess that's wrong.

> An alternative to this change for the fullscreen webview in the kiosk app from #c1 is to have the parent page of the webview listen to the Visual Viewport resize event and resize the webview.

The issue with this is that it would change the semantics of how the keyboard overlays an app. It would be unfortunate to have this differ based on whether an app is hosted in a browser or in a webview.

In issue 865774, it looks like the dialog is a child of the main window? It seems like we should only be setting insets on the main window?

Darren from the virtual keyboard team is looking at issue 865774.  He found a bug that the inset was being calculated incorrectly which has partially fixed my issue.  I think he is also looking into other things.

Your suggestion to only set the insets on the main window sounds right to me, but I'm not sure.  Aren't all webviews children of a main window?  In the case described in #c1, the webview is a child of the main window, but I think settings insets for the webview is the right thing to do (but again I'm not sure).

Even as the code is right now though, I don't think our scrolling behavior is ideal (see attached video).  When the virtual keyboard appears, it is possible for me to scroll down when I don't think it should allow that.  And then when scrolling back up, something is going wrong.

Deleted: Aug 1, 2018 8_00 AM.webm 4.0 MB

	Aug 1, 2018 8_00 AM.webm 4.0 MB View Download

> Aren't all webviews children of a main window?  In the case described in #c1, the webview is a child of the main window, but I think settings insets for the webview is the right thing to do (but again I'm not sure).

I'm not familiar enough with ChromeOS UI and <webview> to know anything here well but in the #c1 case, you mentioned the dialog is a webview. In that case, I would expect we not set insets on it (since presumably it's a child of the main "files app" window)? i.e. the files app itself should be inset but the dialog shouldn't.

> Even as the code is right now though, I don't think our scrolling behavior is ideal (see attached video).  When the virtual keyboard appears, it is possible for me to scroll down when I don't think it should allow that.  And then when scrolling back up, something is going wrong.

Eek. That's definitely a bug. Could you file a new bug against me with repro instructions?

Created issue 870201.  Repro instructions are exactly same as this bug.