Support tracking focused element for OOPIFs.

content/browser/renderer_host/render_widget_host_view_aura.cc

 // Copyright (c) 2012 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #include "content/browser/renderer_host/render_widget_host_view_aura.h"
 
 #include <set>
 #include <utility>
 
 #include "base/auto_reset.h"
@@ skipping 164 matching lines @@
       // with the current approach. Moving the window above the OSK is one way.
       // That for a later patchset.
       if (viewport_bottom > bounds_in_screen.height())
         return;
 
       host_->GetView()->SetInsets(gfx::Insets(0, 0, viewport_bottom, 0));
 
       gfx::Point origin(location_in_screen_);
       screen_position_client->ConvertPointFromScreen(window_, &origin);
 
+      // TODO(ekaramad): We should support the case where the focused node is
+      // inside an OOPIF (https://crbug.com/676037).

[ncarter (slow), 2016/12/21 18:46:09]

As we discussed over chat, we may actually never need to ask anything but the
outermost view to scroll (we don't need to scroll within iframes, because we
don't expect the iframe bounds within the document to change), so for this
codepath at least it is probably not necessary to bubble a scroll event up. This
is borne out of the fact that for non-oopif nested iframes, the code in
WebViewImpl doesn't seem to currently do a recursive scroll-into-view loop. (if
we ever do need to implement that, find-in-page and focus traversal already need
to do it, so maybe there is code we can reuse.)

What it sounds like we *do* need to do, is notify the element itself to finish
the focus change, which may mean sending a separate message to focused widget
(something that currently happens as a side effect of
ScrollFocusedEditableNodeIntoRect?)

[EhsanK, 2016/12/21 18:49:58]

Yes agreed. I believe we might need to fix the scroll focused editable element
for other purposes (or not, I am not too sure) such as IME. But as far as OSK
goes, we only need to focus <iframe>.

       // We want to scroll the node into a rectangle which originates from
       // the touch point and a small offset (10) in either direction.
       gfx::Rect node_rect(origin.x(), origin.y(), 10, 10);
       host_->ScrollFocusedEditableNodeIntoRect(node_rect);

[ncarter (slow), 2016/12/21 18:46:09]

This change makes sense.

[EhsanK, 2016/12/21 18:49:58]

Acknowledged.

     }
   }
 
   void OnKeyboardHidden(const gfx::Rect& keyboard_rect_pixels) override {
     // Restore the viewport.
     host_->GetView()->SetInsets(gfx::Insets());
   }
 
  private:
   RenderWidgetHostImpl* host_;
@@ skipping 574 matching lines @@
     const gfx::Point& location_dips_screen,
     bool editable) {
 #if defined(OS_WIN)
   RenderViewHost* rvh = RenderViewHost::From(host_);
   if (rvh && rvh->GetDelegate())
     rvh->GetDelegate()->SetIsVirtualKeyboardRequested(editable);
 
   ui::OnScreenKeyboardDisplayManager* osk_display_manager =
       ui::OnScreenKeyboardDisplayManager::GetInstance();
   DCHECK(osk_display_manager);
-  if (editable && host_ && host_->GetView()) {
+  if (editable && host_ && host_->GetView() && host_->delegate()) {
     keyboard_observer_.reset(new WinScreenKeyboardObserver(
         host_, location_dips_screen, device_scale_factor_, window_));
     virtual_keyboard_requested_ =
         osk_display_manager->DisplayVirtualKeyboard(keyboard_observer_.get());
   } else {
     virtual_keyboard_requested_ = false;
     osk_display_manager->DismissVirtualKeyboard();
   }
 #endif
 }
@@ skipping 1586 matching lines @@
 
 void RenderWidgetHostViewAura::SetPopupChild(
     RenderWidgetHostViewAura* popup_child_host_view) {
   popup_child_host_view_ = popup_child_host_view;
   event_handler_->SetPopupChild(
       popup_child_host_view,
       popup_child_host_view ? popup_child_host_view->event_handler() : nullptr);
 }
 
 }  // namespace content