Chromecast startup race: don't add filter before HostResolver exists.

chromecast/browser/cast_content_browser_client.cc

Index: chromecast/browser/cast_content_browser_client.cc
diff --git a/chromecast/browser/cast_content_browser_client.cc b/chromecast/browser/cast_content_browser_client.cc
index 3234a597e1b5f7780aa1ac1b484feabeadba41ab..35c6c20f13bc9aaf238ab1758af8031b514013a8 100644
--- a/chromecast/browser/cast_content_browser_client.cc
+++ b/chromecast/browser/cast_content_browser_client.cc
@@ -39,6 +39,7 @@
 #include "content/public/common/url_constants.h"
 #include "content/public/common/web_preferences.h"
 #include "gin/v8_initializer.h"
+#include "media/base/bind_to_current_loop.h"
 #include "net/ssl/ssl_cert_request_info.h"
 #include "ui/gl/gl_switches.h"
 
@@ -74,22 +75,39 @@ content::BrowserMainParts* CastContentBrowserClient::CreateBrowserMainParts(
 
 void CastContentBrowserClient::RenderProcessWillLaunch(
     content::RenderProcessHost* host) {
-  scoped_refptr<content::BrowserMessageFilter> network_hints_message_filter(
-      new network_hints::NetworkHintsMessageFilter(
-          url_request_context_factory_->host_resolver()));
-  host->AddFilter(network_hints_message_filter.get());
 #if !defined(OS_ANDROID)
   scoped_refptr<media::CmaMessageFilterHost> cma_message_filter(
       new media::CmaMessageFilterHost(host->GetID()));
   host->AddFilter(cma_message_filter.get());
 #endif  // !defined(OS_ANDROID)
 
+  content::BrowserThread::PostTaskAndReplyWithResult(
+      content::BrowserThread::IO, FROM_HERE,
+      base::Bind(&URLRequestContextFactory::host_resolver,
+                 base::Unretained(url_request_context_factory_.get())),
+      base::Bind(&CastContentBrowserClient::AddExtraFilter,
+                 base::Unretained(this), host->GetID()));

[byungchul, 2015/04/17 00:22:20]

It changes the order of message filter. Is it okay?

And, can it guarantee host_resolver is available if synchronized with browser IO
thread? It seems like it also depend on when we call url request context getter.

[gunsch, 2015/04/17 01:06:27]

Changing order is okay. Order was not so important, just based on when they were
added.

I took a closer look and you're correct that it depends, since initialization is
lazily done. I now force IO-thread initialization immediately in
CastBrowserMainParts so that this startup path is much more explicit.

+
   auto extra_filters = PlatformGetBrowserMessageFilters();
   for (auto const& filter : extra_filters) {
     host->AddFilter(filter.get());
   }
 }
 
+void CastContentBrowserClient::AddExtraFilter(
+    int render_process_id, net::HostResolver* host_resolver) {
+  DCHECK_CURRENTLY_ON(content::BrowserThread::UI);
+
+  content::RenderProcessHost* host =
+      content::RenderProcessHost::FromID(render_process_id);
+  if (!host)
+    return;
+
+  scoped_refptr<content::BrowserMessageFilter> network_hints_message_filter(
+      new network_hints::NetworkHintsMessageFilter(host_resolver));
+  host->AddFilter(network_hints_message_filter.get());
+}
+
 net::URLRequestContextGetter* CastContentBrowserClient::CreateRequestContext(
     content::BrowserContext* browser_context,
     content::ProtocolHandlerMap* protocol_handlers,