Support tracking focused element for OOPIFs.

content/browser/renderer_host/render_widget_host_view_aura.cc

Index: content/browser/renderer_host/render_widget_host_view_aura.cc
diff --git a/content/browser/renderer_host/render_widget_host_view_aura.cc b/content/browser/renderer_host/render_widget_host_view_aura.cc
index e09bf33cdb434d959f8980dd36dd4a34b176020f..3d993b09db68c414d9269741ca2acc7808fbf22a 100644
--- a/content/browser/renderer_host/render_widget_host_view_aura.cc
+++ b/content/browser/renderer_host/render_widget_host_view_aura.cc
@@ -182,6 +182,8 @@ class WinScreenKeyboardObserver : public ui::OnScreenKeyboardObserver {
       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);
@@ -780,7 +782,7 @@ void RenderWidgetHostViewAura::FocusedNodeTouched(
   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_ =