Re-enable FocusBeforeNavigation test.

content/browser/browser_plugin/browser_plugin_guest.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/browser_plugin/browser_plugin_guest.h"
 
 #include <stddef.h>
 
 #include <algorithm>
 
@@ skipping 641 matching lines @@
     guest_rwhv->TextInputStateChanged(*last_text_input_state_);
 }
 
 void BrowserPluginGuest::DidFinishNavigation(
     NavigationHandle* navigation_handle) {
   if (navigation_handle->HasCommitted())
     RecordAction(base::UserMetricsAction("BrowserPlugin.Guest.DidNavigate"));
 }
 
 void BrowserPluginGuest::RenderViewReady() {
+  if (GuestMode::IsCrossProcessFrameGuest(GetWebContents()))

[alexmos, 2017/03/04 01:12:16]

I'll defer to James or Lucas here, but in the CL description you say this
intends to prevent BrowserPluginGuest from unfocusing the guest in oopif mode,
but this function seems to do some other things, like set the hung renderer
delay and send the BrowserPluginMsg_GuestReady message.  Are those still needed
in oopif mode?

[wjmaclean, 2017/03/14 16:13:37]

I'm not sure I follow: in WebView+OOPIF mode aren't we now early-outing and
avoiding doing all those things?

[alexmos, 2017/03/15 00:16:07]

Right, so my question is, if we are in webview+OOPIF mode, should we only skip
the "Send(new InputMsg_SetFocus(routing_id(), focused_))", which is presumably
the "unfocusing" part, but still do the other bits, like set the hung renderer
delay and the GuestReady message?  Or is none of this function needed in
webview+OOPIF mode? 

[avallee, 2017/03/15 02:55:20]

We definitely need to skip the SetFocus message since webview+OOPIF does not
update BrowserPluginGuest::focused_ correctly and plumbing that through looks
decently complicated for no apparent benefit.

I also think that SendMessageToEmbedder does nothing in oopif and on the other
side only clears the guest_crashed_ parameter.

I can see that the hung_renderer_delay might still make sense.

It's been a while now, but when i spoke with lfg his feeling was that nothing
here mattered and that this would get deleted with BrowserPlugin.

[alexmos, 2017/03/15 04:25:03]

Ack.  The hung_renderer_delay also seems like it's just being set to the default
value that isn't really changed anywhere else.

+    return;
+
   RenderViewHost* rvh = GetWebContents()->GetRenderViewHost();
   // TODO(fsamuel): Investigate whether it's possible to update state earlier
   // here (see http://crbug.com/158151).
   Send(new InputMsg_SetFocus(routing_id(), focused_));
   UpdateVisibility();
 
   // In case we've created a new guest render process after a crash, let the
   // associated BrowserPlugin know. We only need to send this if we're attached,
   // as guest_crashed_ is cleared automatically on attach anyways.
   if (attached()) {
@@ skipping 393 matching lines @@
           range, character_bounds);
 }
 #endif
 
 void BrowserPluginGuest::SetContextMenuPosition(const gfx::Point& position) {
   if (delegate_)
     delegate_->SetContextMenuPosition(position);
 }
 
 }  // namespace content