InstantExtended: Send search URLs to renderers.

                                                                                
Previously, navigations initiated by an instant renderer were bounced to
the browser to be rebucketed into an instant or non-instant renderer.
But navigations from non-instant renderers to instant URLs (i.e.
privileged search page URLs) were not rebucketed, because the renderer
had no knowledge of which URLs were instant URLs, and it would be too
expensive to bounce ALL URLs. As a result, non-instant pages like
google.com/setprefs could not redirect to instant pages like
google.com/search.
                                                                        
This change has InstantService tell renderers about URLs associated with
the default search engine, and uses this knowledge to bounce
renderer-initiated navigations to likely instant URLs from non-instant
processes back into the browser for rebucketing. So now link clicks from
non-instant pages to instant pages will put the destination pages into
an instant process. Unfortunately, though, redirects are still broken.
For example,
                                                                                
0. User clicks "Set preferences" button on an instant page.
1. Instant renderer bounces google.com/setprefs to the browser.
2. Browser says google.com/setprefs is not an instant URL,
   and assigns it to a non-instant renderer.
3. After rebucketing to the non-instant renderer, google.com/setprefs
   is marked as a browser initiated request(!)
4. /setprefs redirects to /search, which _is_ an instant URL, but
   because /setprefs is marked as browser initiated the non-instant
   renderer does not get a chance to bounce it back to the browser.
                                                                                
I tried working around this by giving redirects a chance to bounce back
to the browser in step #4, but this broke the signin process model in a
scary way that I don't fully understand. It seems like the right fix
here is going to need to EITHER follow the redirect chain in step #2
when determining if an URL is an instant URL, OR somehow flag the
bounced redirect request for further inspection in step #3.

This change also includes a small side benefit. Since renderers now know
about instant URLs, we can suppress a flash of a baked-in error page in
the event of an error while loading the InstantExtended new tab page.

TEST=manual,unit,browsertest
BUG=271088,223754

Review URL: https://codereview.chromium.org/23455047

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@226103 0039d316-1c4b-4281-b951-d872f2087c98

1 files changed, 4 insertions, 0 deletions

diff --git a/content/public/renderer/content_renderer_client.cc b/content/public/renderer/content_renderer_client.cc
index 3b23238..6c93cbf 100644
--- a/content/public/renderer/content_renderer_client.cc
+++ b/content/public/renderer/content_renderer_client.cc
@@ -37,6 +37,10 @@ bool ContentRendererClient::HasErrorPage(int http_status_code,
   return false;
 }
 
+bool ContentRendererClient::ShouldSuppressErrorPage(const GURL& url) {
+  return false;
+}
+
 void ContentRendererClient::DeferMediaLoad(RenderView* render_view,
                                            const base::Closure& closure) {
   closure.Run();