Test that no crash happens with the CWS error page.

chrome/browser/extensions/process_management_browsertest.cc

Index: chrome/browser/extensions/process_management_browsertest.cc
diff --git a/chrome/browser/extensions/process_management_browsertest.cc b/chrome/browser/extensions/process_management_browsertest.cc
index 012fb553d0cf27c65aba7a9f90c980fe9cedae4e..87eebb2301fa9f2f75f924ba27d02ec43c4bb095 100644
--- a/chrome/browser/extensions/process_management_browsertest.cc
+++ b/chrome/browser/extensions/process_management_browsertest.cc
@@ -26,6 +26,7 @@
 #include "extensions/browser/extension_host.h"
 #include "extensions/browser/process_manager.h"
 #include "extensions/browser/process_map.h"
+#include "extensions/common/extension_urls.h"
 #include "extensions/common/switches.h"
 #include "net/dns/mock_host_resolver.h"
 #include "net/test/embedded_test_server/embedded_test_server.h"
@@ -390,3 +391,31 @@ IN_PROC_BROWSER_TEST_F(ChromeWebStoreProcessTest,
   // Verify that Chrome Web Store is isolated in a separate renderer process.
   EXPECT_NE(old_process_host, new_process_host);
 }
+
+// This problem is similar to https://crbug.com/622385. It happens when an
+// iframe error page with the Chrome Web Store URL is displayed and the iframe
+// and its parent reside in the same process. In this case, the renderer
+// process is killed with the RFH_CAN_COMMIT_URL_BLOCKED error code. This test
+// asserts that the renderer is still alive after the navigation.

[nasko, 2017/03/09 17:18:11]

nit: "renderer process". One of the main goals I have when reviewing comments is
for them to be very explicit and precise. Just using the word "renderer" makes
is ambiguous - is it the process or the RenderFrame? Let's try to never use just
the word "renderer" by itself, but be more precise.

[arthursonzogni, 2017/03/10 09:25:47]

Done.

+IN_PROC_BROWSER_TEST_F(ChromeWebStoreProcessTest,
+                       ChromeWebStoreBlockedByFrameSrc) {
+  GURL url =
+      embedded_test_server()->GetURL("/extensions/iframe-child-src-none.html");
+  ui_test_utils::NavigateToURL(browser(), url);
+
+  WebContents* web_contents =
+      browser()->tab_strip_model()->GetActiveWebContents();
+
+  // Make the iframe navigate to the Chrome Web Store and wait for the 'load'
+  // event. This is also a check that the renderer is still alive after the
+  // navigation.
+  std::string message;
+  EXPECT_TRUE(ExecuteScriptAndExtractString(
+      web_contents,
+      "var iframe = document.getElementById('test'); iframe.onload = "

[nasko, 2017/03/09 17:18:11]

nit: I'd put the iframe.onload on the new line and combine it with the
"function() {" part. It makes it more clear that we are assigning a function to
the onload event handler.

[arthursonzogni, 2017/03/10 09:25:47]

Done.

+      "function() { domAutomationController.send('iframe loaded'); }; "
+      "iframe.src = '" +
+          std::string(extension_urls::kChromeWebstoreBaseURL) + "';",
+      &message));

[nasko, 2017/03/09 17:18:11]

Doesn't ExecuteScriptAndExtractString basically return after executing the
statement in its argument? How does it wait if the load would take long time?

[arthursonzogni, 2017/03/10 09:25:47]

It is waiting that the domAutomationController send something.
It calls DOMMessageQueue::WaitForMessage(...)

So, it will wait as long as it takes.

+  EXPECT_EQ("iframe loaded", message);
+}