Support tracking focused element for OOPIFs.

content/renderer/render_frame_impl.cc

 // Copyright 2013 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/renderer/render_frame_impl.h"
 
 #include <map>
 #include <string>
 #include <utility>
 #include <vector>
@@ skipping 1564 matching lines @@
     IPC_MESSAGE_HANDLER(FrameMsg_SerializeAsMHTML, OnSerializeAsMHTML)
     IPC_MESSAGE_HANDLER(FrameMsg_Find, OnFind)
     IPC_MESSAGE_HANDLER(FrameMsg_ClearActiveFindMatch, OnClearActiveFindMatch)
     IPC_MESSAGE_HANDLER(FrameMsg_StopFinding, OnStopFinding)
     IPC_MESSAGE_HANDLER(FrameMsg_EnableViewSourceMode, OnEnableViewSourceMode)
     IPC_MESSAGE_HANDLER(FrameMsg_SuppressFurtherDialogs,
                         OnSuppressFurtherDialogs)
     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)
     IPC_MESSAGE_HANDLER(FrameMsg_GetNearestFindResult,
                         OnGetNearestFindResult)
     IPC_MESSAGE_HANDLER(FrameMsg_FindMatchRects, OnFindMatchRects)
 #endif
 
 #if defined(USE_EXTERNAL_POPUP_MENU)
 #if defined(OS_MACOSX)
@@ skipping 3396 matching lines @@
   Send(new FrameHostMsg_DidChangeLoadProgress(routing_id_, load_progress));
 }
 
 void RenderFrameImpl::HandleWebAccessibilityEvent(
     const blink::WebAXObject& obj, blink::WebAXEvent event) {
   if (render_accessibility_)
     render_accessibility_->HandleWebAccessibilityEvent(obj, event);
 }
 
 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);
 }
 
 void RenderFrameImpl::FocusedNodeChangedForAccessibility(const WebNode& node) {
   if (render_accessibility())
     render_accessibility()->AccessibilityFocusedNodeChanged(node);
 }
 
 // PlzNavigate
@@ skipping 549 matching lines @@
   }
   file_chooser_completions_.pop_front();
 
   // If there are more pending file chooser requests, schedule one now.
   if (!file_chooser_completions_.empty()) {
     Send(new FrameHostMsg_RunFileChooser(
         routing_id_, file_chooser_completions_.front()->params));
   }
 }
 
+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,
                                                   float y) {
   WebRect selection_rect;
   int ordinal =
       frame_->selectNearestFindMatch(WebFloatPoint(x, y), &selection_rect);
   if (ordinal == -1) {
     // Something went wrong, so send a no-op reply (force the frame to report
     // the current match count) in case the host is waiting for a response due
@@ skipping 1096 matching lines @@
   // event target. Potentially a Pepper plugin will receive the event.
   // In order to tell whether a plugin gets the last mouse event and which it
   // is, we set |pepper_last_mouse_event_target_| to null here. If a plugin gets
   // the event, it will notify us via DidReceiveMouseEvent() and set itself as
   // |pepper_last_mouse_event_target_|.
   pepper_last_mouse_event_target_ = nullptr;
 #endif
 }
 
 }  // namespace content