Implement WebContentsViewChildFrame::TakeFocus.

third_party/WebKit/Source/core/page/FocusController.cpp

Index: third_party/WebKit/Source/core/page/FocusController.cpp
diff --git a/third_party/WebKit/Source/core/page/FocusController.cpp b/third_party/WebKit/Source/core/page/FocusController.cpp
index e9723e85639f74c9dd7331209e829670966c32b4..d11fd62a3e32e75452a98c6ef50b93edbb9df069 100644
--- a/third_party/WebKit/Source/core/page/FocusController.cpp
+++ b/third_party/WebKit/Source/core/page/FocusController.cpp
@@ -874,7 +874,7 @@ void FocusController::setFocused(bool focused) {
   if (!m_isFocused && focusedOrMainFrame()->isLocalFrame())
     toLocalFrame(focusedOrMainFrame())->eventHandler().stopAutoscroll();
 
-  if (!m_focusedFrame)
+  if (!m_focusedFrame && m_isFocused)

[alexmos, 2016/11/22 02:45:27]

Why is this needed?  How is it related to the rest of this CL?  If it's needed,
can you add a comment?

[avallee, 2016/11/25 19:39:54]

When you call Blur on a page with no focused frame, this ends up focusing a
frame and sending back an IPC that steals focus.

[alexmos, 2016/11/28 23:52:24]

In what scenario would that happen during tab traversal?  I thought we got rid
of unsetting the focused frame in https://codereview.chromium.org/2451143003/,
so then is this only happening when blurring a WebContents on which you've never
clicked (which thus has no focused frame to start with)?

[avallee, 2016/12/09 21:16:51]

When we reach the end of the guest focusable elements we ask our embedder to
TakeFocus after clearing the focused element and  focused frame:
https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/page/Focu...

As part of taking focus from the guest we blur the widget in which case we
arrive here  with no focused frame and isFocused false.

[alexmos, 2016/12/12 22:41:15]

Acknowledged.  I didn't realize that the TakeFocus path clears the focused
frame.

     setFocusedFrame(m_page->mainFrame());
 
   // setFocusedFrame above might reject to update m_focusedFrame, or