Allow asynchronous tab creation when opener_suppressed is true.

content/browser/web_contents/web_contents_impl.cc

Index: content/browser/web_contents/web_contents_impl.cc
diff --git a/content/browser/web_contents/web_contents_impl.cc b/content/browser/web_contents/web_contents_impl.cc
index cb891ec95c3cb8e8685faf0e5193d3ba5178e1f1..a1c3c53364c912c798931a00a6b34a7130cff366 100644
--- a/content/browser/web_contents/web_contents_impl.cc
+++ b/content/browser/web_contents/web_contents_impl.cc
@@ -1756,7 +1756,15 @@ void WebContentsImpl::CreateNewWindow(
                                 ui::PAGE_TRANSITION_LINK,
                                 true /* is_renderer_initiated */);
       open_params.user_gesture = params.user_gesture;
-      new_contents->OpenURL(open_params);
+
+      if (delegate_ && !is_guest &&
+          !delegate_->ShouldResumeRequestsForCreatedWindow()) {
+        // We are in asynchronous add new contents path, delay opening url
+        new_contents->delayed_open_url_params_.reset(
+            new OpenURLParams(open_params));
+      } else {
+        new_contents->OpenURL(open_params);
+      }
     }
   }
 }
@@ -2669,6 +2677,12 @@ void WebContentsImpl::ExitFullscreen() {
 }
 
 void WebContentsImpl::ResumeLoadingCreatedWebContents() {
+  if (delayed_open_url_params_.get()) {
+    OpenURL(*delayed_open_url_params_.get());
+    delayed_open_url_params_.reset(nullptr);
+    return;

[nasko, 2015/07/10 07:42:20]

Why is there a return here? Skipping the initialization of RVH and RFH doesn't
seem like a good idea. It will very likely break window.open() cases if this
delayed path is hit.

[Maria, 2015/07/10 16:26:25]

This function is not called in the initialization path for new window load with
opener_suppressed usually. Usually we synchronously start OpenURL on web
contents in that path. However, on Android we have to finish setting up our
tab/web contents delegate asynchronously before we start the page load. 

We already have code that calls into ResumeLoadingCreatedWebContents() from Java
when such setup is completed (for window.open() cases). I added this here
because we would use the same signal to complete the load in opener_suppressed
case, but returning early because I believe we wouldn't have usually initialized
RVH/RFH through here.

+  }
+
   // Resume blocked requests for both the RenderViewHost and RenderFrameHost.
   // TODO(brettw): It seems bogus to reach into here and initialize the host.
   GetRenderViewHost()->Init();