[New Tab Page] Change the mechanism to intercept online NTP errors

chrome/browser/chrome_content_browser_client.cc

Index: chrome/browser/chrome_content_browser_client.cc
diff --git a/chrome/browser/chrome_content_browser_client.cc b/chrome/browser/chrome_content_browser_client.cc
index a45399ec4245e8c283c4919377bf3bece0f974c0..ff47252111a3f420c1bf122b197ed12f7a8c5985 100644
--- a/chrome/browser/chrome_content_browser_client.cc
+++ b/chrome/browser/chrome_content_browser_client.cc
@@ -76,6 +76,8 @@
 #include "chrome/browser/ui/blocked_content/blocked_window_params.h"
 #include "chrome/browser/ui/blocked_content/popup_blocker_tab_helper.h"
 #include "chrome/browser/ui/chrome_select_file_policy.h"
+#include "chrome/browser/ui/search/new_tab_page_interceptor_service.h"
+#include "chrome/browser/ui/search/new_tab_page_interceptor_service_factory.h"
 #include "chrome/browser/ui/sync/sync_promo_ui.h"
 #include "chrome/browser/ui/tab_contents/chrome_web_contents_view_delegate.h"
 #include "chrome/browser/ui/webui/chrome_web_ui_controller_factory.h"
@@ -974,6 +976,10 @@ ChromeContentBrowserClient::CreateRequestContext(
     content::ProtocolHandlerMap* protocol_handlers,
     content::URLRequestInterceptorScopedVector request_interceptors) {
   Profile* profile = Profile::FromBrowserContext(browser_context);
+  NewTabPageInterceptorService* service =
+      NewTabPageInterceptorServiceFactory::GetForProfile(profile);
+  if (service)
+    request_interceptors.push_back(service->CreateInterceptor().release());

[mmenke, 2015/01/22 20:53:50]

Is there a reason to prefer this here over
ProfileImplIOData::Handle::CreateMainRequestContextGetter?

If there's a reason, I'm fine with it here, but most of the URLRequestContext
setup happens in Profile.*IOData, so it's easier to keep track of all the stuff
that is attached to the poor beleaguered request context if we try and keep most
of it there...Of course, my suggestion only overs main profiles, but since we
don't want it for incognito, anyways, not sure that's an issue.

[Mathieu, 2015/01/22 21:44:22]

I'll let kmadhusu comment on whether she considered it.

So there seems to be a good candidate place here:
https://code.google.com/p/chromium/codesearch#chromium/src/chrome/browser/pro...

This is pretty deep down, but if you think it's a better place let me know. 

[mmenke, 2015/01/22 21:52:29]

That's actually called on the IO thread, so wouldn't work.  I believe
ProfileIOData::InitializeOnUIThread is actually the latest place you could put
it (Not sure you can access the interceptor list there, but you can stick it in
params, and then hook it up later down the line on the IO thread).

There is already at least one other interceptor created there.

[kmadhusu, 2015/01/23 00:59:32]

I didn't try to create an interceptor in
ProfileImplIOData::Handle::CreateMainRequestContextGetter. There should not be
any problem to move this code there because line 983 eventually calls that
function.

But I did try to create an interceptor instance in
ProfileImplIOData::InitializeInternal() and it failed because of thread
violation. Feel free to move this code to any better place as long as that code
runs on an UI thread.

   return profile->CreateRequestContext(protocol_handlers,
                                        request_interceptors.Pass());
 }