Add chrome-search: access from Instant overlay

chrome/browser/browser_process_impl.cc

Index: chrome/browser/browser_process_impl.cc
diff --git a/chrome/browser/browser_process_impl.cc b/chrome/browser/browser_process_impl.cc
index fba82ec5dca5bf0cc28f1c23abb1e52259f294bc..ee3f4d8b84af6e170dcf3c983dbe553deb932a11 100644
--- a/chrome/browser/browser_process_impl.cc
+++ b/chrome/browser/browser_process_impl.cc
@@ -183,6 +183,8 @@ BrowserProcessImpl::BrowserProcessImpl(
       extensions::kExtensionScheme);
   ChildProcessSecurityPolicy::GetInstance()->RegisterWebSafeScheme(
       chrome::kExtensionResourceScheme);
+  ChildProcessSecurityPolicy::GetInstance()->RegisterWebSafeScheme(
+      chrome::kChromeSearchScheme);

[Charlie Reis, 2013/03/02 04:41:09]

This means FilterURL won't complain if it sees chrome-search: requests from
normal renderer processes, I believe.  Is there somewhere else that we ensure
that only the Instant process can make those requests?

[dhollowa, 2013/03/04 18:39:35]

The cross-origin checks block this normally on the renderer side, and the
URLDataSource::ShouldServiceRequest will block these on the browser-side
normally.

For the Instant case, I use
WebKit::WebSecurityPolicy::addOriginAccessWhitelistEntry on the renderer side,
and permit specific data-source access via URLDataSource::ShouldAccessRequest on
the browser side.

Since those checks are in place, I needed to disable the
ChildProcessSecurityPolicy stuff here.

 
 #if defined(OS_MACOSX)
   InitIdleMonitor();