The on screen keyboard on Windows 8+ should not obscure the input field.

content/browser/renderer_host/render_widget_host_view_base.cc

Index: content/browser/renderer_host/render_widget_host_view_base.cc
diff --git a/content/browser/renderer_host/render_widget_host_view_base.cc b/content/browser/renderer_host/render_widget_host_view_base.cc
index dd88faea8fae27b0cfc71207869e299227a5a363..d2dacc88472df107cd7893be341e1f028931d9cb 100644
--- a/content/browser/renderer_host/render_widget_host_view_base.cc
+++ b/content/browser/renderer_host/render_widget_host_view_base.cc
@@ -250,6 +250,11 @@ void RenderWidgetHostViewBase::EndFrameSubscription() {
   NOTREACHED();
 }
 
+void RenderWidgetHostViewBase::FocusedNodeTouched(
+    const gfx::Point& location_dips, bool editable) {
+  DVLOG(1) << "FocusedNodeTouched: " << editable;

[ncarter (slow), 2016/05/19 18:03:24]

I wonder if this will be reachable with oopifs?

You can try the following test: run content_shell (or chrome) with the
--site-per-process flag, and visit
http://csreis.github.io/tests/cross-site-iframe-simple.html. The input elements
there are in a different process from the main page. You may have to add a
FocusedNodeTouched to RenderWidgetHostViewChildFrame, to forward it upwards --
kenrb or lfg can help you figure out the right way to structure that.

Oopifs will start shipping for extensions in the next milestone, so it's
important to get this right. 

[ananta, 2016/05/19 19:33:38]

Will look into this

[ananta, 2016/05/19 22:00:56]

I logged a bug https://bugs.chromium.org/p/chromium/issues/detail?id=613326 and
referenced
this in a TODO in RenderViewHostImpl::OnFocusedNodeTouched. It may make sense to
move the
handling of these messages to RenderWidgetHostImpl and call the view from there.
We would still
need a place to add in the implementation on Windows to display and dismiss the
on screen keyboard.

+}
+
 uint32_t RenderWidgetHostViewBase::RendererFrameNumber() {
   return renderer_frame_number_;
 }