Support tracking focused element for OOPIFs.

content/renderer/render_frame_impl.cc

Index: content/renderer/render_frame_impl.cc
diff --git a/content/renderer/render_frame_impl.cc b/content/renderer/render_frame_impl.cc
index 0179a9c1a5568f865c138447966a8f0d0b83418a..1ef3571982c54d54e1f05580bae94150fa0bc238 100644
--- a/content/renderer/render_frame_impl.cc
+++ b/content/renderer/render_frame_impl.cc
@@ -1582,6 +1582,7 @@ bool RenderFrameImpl::OnMessageReceived(const IPC::Message& msg) {
     IPC_MESSAGE_HANDLER(FrameMsg_SetHasReceivedUserGesture,
                         OnSetHasReceivedUserGesture)
     IPC_MESSAGE_HANDLER(FrameMsg_RunFileChooserResponse, OnFileChooserResponse)
+    IPC_MESSAGE_HANDLER(FrameMsg_ClearFocusedElement, OnClearFocusedElement)
 #if defined(OS_ANDROID)
     IPC_MESSAGE_HANDLER(FrameMsg_ActivateNearestFindResult,
                         OnActivateNearestFindResult)
@@ -4998,6 +4999,18 @@ void RenderFrameImpl::HandleWebAccessibilityEvent(
 }
 
 void RenderFrameImpl::FocusedNodeChanged(const WebNode& node) {
+  gfx::Rect node_bounds;
+  bool is_editable = false;
+  if (!node.isNull() && node.isElementNode()) {
+    WebElement element = const_cast<WebNode&>(node).to<WebElement>();
+    blink::WebRect rect = element.boundsInViewport();
+    GetRenderWidget()->convertViewportToWindow(&rect);
+    node_bounds = gfx::Rect(rect);
+    is_editable = element.isEditable();
+  }
+  Send(new FrameHostMsg_FocusedNodeChanged(GetRoutingID(), is_editable,
+                                           node_bounds));
+
   for (auto& observer : observers_)
     observer.FocusedNodeChanged(node);
 }
@@ -5567,6 +5580,15 @@ void RenderFrameImpl::OnFileChooserResponse(
   }
 }
 
+void RenderFrameImpl::OnClearFocusedElement() {
+  // TODO(ekaramad): The focused element might have changed to an element in
+  // another frame from the same renderer process. Should we avoid clearing the
+  // element if it is not in this frame? If not maybe handle this in
+  // RenderViewImpl?

[ncarter (slow), 2016/12/16 19:17:21]

What is the concern here? Do you think we might have correctness bugs when doing
in-process, cross-frame focus traversal?

In general I would expect it should suffice to maintain a deterministic ordering
between the focus and focus-clear operations, and then we can reasonably
implement this in terms of one RFH.

Adding special-cases for same-process behavior increases the possibility of
behavioral drift between the oopif and non-oopif cases, so I prefer purely
frame-based operations, where feasible.

[EhsanK, 2016/12/20 16:39:11]

My concern was that we end up calling webview->clearFocusedElement() which is
doing it for the page. This includes finding the focused frame and then clearing
the element on its document.

But if we are already at the right RFH (since we sent it to the focused frame
from browser), then why do that? We should maybe separate the logic for clearing
the document and doing the layout into a method in WebLocalFrame and use it
here.

For clearing the element on page, we can modify the webview method to get the
focused frame and call clear on that. WDYT?

The only issue would be that the focused frame on the renderer might change
while the IPC is enroute to renderer. But I don't think that is an issue here.

+  if (auto* webview = render_view_->GetWebView())
+    webview->clearFocusedElement();
+}
+
 #if defined(OS_ANDROID)
 void RenderFrameImpl::OnActivateNearestFindResult(int request_id,
                                                   float x,