WebContents created via ctrl-click should be in a new process (target=_blank).

third_party/WebKit/Source/core/loader/FrameLoader.cpp

Index: third_party/WebKit/Source/core/loader/FrameLoader.cpp
diff --git a/third_party/WebKit/Source/core/loader/FrameLoader.cpp b/third_party/WebKit/Source/core/loader/FrameLoader.cpp
index 981e6b72ac80845f83a00a4170eb1eb8e5b00d7e..77e1ebd03bcfe61ebde085ab9ec16adcb7ae5b47 100644
--- a/third_party/WebKit/Source/core/loader/FrameLoader.cpp
+++ b/third_party/WebKit/Source/core/loader/FrameLoader.cpp
@@ -912,12 +912,13 @@ void FrameLoader::Load(const FrameLoadRequest& passed_request,
     if (policy == kNavigationPolicyDownload) {
       Client()->LoadURLExternally(request.GetResourceRequest(),
                                   kNavigationPolicyDownload, String(), false);
-    } else {
+      return;  // Navigation/download will be handled by the client.
+    } else if (ShouldNavigateTargetFrame(policy)) {

[Łukasz Anforowicz, 2017/04/14 19:29:10]

This is the main fix - we should avoid going via CreateWindowForRequest if the
|policy| says that we shouldn't navigate the target frame (e.g. because we are
opening the link in a new tab).  The ShouldNavigateTargetFrame was introduced
previously to fix similar bugs (e.g. see https://crrev.com/2410303006 - avoiding
going through RenderFrameProxy when targeting a *new* frame).

       request.GetResourceRequest().SetFrameType(
           WebURLRequest::kFrameTypeAuxiliary);
       CreateWindowForRequest(request, *frame_, policy);
+      return;  // Navigation will be handled by the new frame/window.
     }
-    return;
   }
 
   if (!frame_->IsNavigationAllowed())