New WebContents created via ctrl-click should be in a new process.

chrome/browser/extensions/api/tabs/tabs_api.cc

Index: chrome/browser/extensions/api/tabs/tabs_api.cc
diff --git a/chrome/browser/extensions/api/tabs/tabs_api.cc b/chrome/browser/extensions/api/tabs/tabs_api.cc
index e4ec50d3ce1cbe127880073ff250eaddf86ab6fd..30ae516d6381709c9ed6c62edd6cd72fddb4abc3 100644
--- a/chrome/browser/extensions/api/tabs/tabs_api.cc
+++ b/chrome/browser/extensions/api/tabs/tabs_api.cc
@@ -621,8 +621,13 @@ ExtensionFunction::ResponseAction WindowsCreateFunction::Run() {
     chrome::NavigateParams navigate_params(new_window, url,
                                            ui::PAGE_TRANSITION_LINK);
     navigate_params.disposition = WindowOpenDisposition::NEW_FOREGROUND_TAB;
+
+    // Make sure that (if possible) the new contents are created in the same
+    // renderer process as the caller of the chrome.windows.create API.
+    navigate_params.use_new_renderer_for_new_contents = false;

[Devlin, 2017/04/20 16:22:30]

This is probably checked later, but maybe we should set this to be true iff
|url| is within the extension?  (At the very least, we should document why this
is safe, since at first glance it looks scary.)

[Łukasz Anforowicz, 2017/04/20 19:03:57]

1. Note that the current CL doesn't change the behavior here (although the
change above makes it more explicit what is going on).

2. I've reworded the comment above to make it clearer what is going on.

3. I've also changed |use_new_renderer_for_new_contents| into
|force_new_renderer_for_new_contents| - hopefully this better conveys that we
might still use a new renderer (for cross-site contents) even if
|force_new_renderer_for_new_contents| is false.

     navigate_params.source_site_instance =
         render_frame_host()->GetSiteInstance();
+
     chrome::Navigate(&navigate_params);
   }