Remove content dependencies from content settings providers.

chrome/browser/profiles/off_the_record_profile_impl.cc

Index: chrome/browser/profiles/off_the_record_profile_impl.cc
diff --git a/chrome/browser/profiles/off_the_record_profile_impl.cc b/chrome/browser/profiles/off_the_record_profile_impl.cc
index ef044dffaf316c53e9cb128fe3da6e5f26402f30..3e557ac42ec0995b0cb3f3fd9fb436bec7d60203 100644
--- a/chrome/browser/profiles/off_the_record_profile_impl.cc
+++ b/chrome/browser/profiles/off_the_record_profile_impl.cc
@@ -354,6 +354,7 @@ HostContentSettingsMap* OffTheRecordProfileImpl::GetHostContentSettingsMap() {
   // ensure the preferences have been migrated.
   profile_->GetHostContentSettingsMap();
   if (!host_content_settings_map_.get()) {
+    DCHECK_CURRENTLY_ON(content::BrowserThread::UI);

[rpetterson, 2014/09/26 03:46:34]

Is there a reason not to have this at the start of the function? Should it ever
not be called on the UI thread?

[Jun Mukai, 2014/09/26 07:45:14]

The motivation of this CL is to strip off the dependency on content/ from these
files.  And the content/ dependency is because of iOS support -- iOS cannot
depend on content/

[blundell, 2014/09/26 07:50:41]

I think the question is why this DCHECK shouldn't be before line 355.

[Jun Mukai, 2014/09/26 18:37:37]

Ah...
HostContentSettings is thread-safe object and can be used by ProfileIOData. It's
simply initialization process -- but indeed this is weird.  If some non-UI
thread calls GetHostContentSettingsMap() first, it would lead to an unexpected
result.

The reason why it is okay on the current code base is because
HostContentSettingsMap is required in DoFinalInit (through the call stack of
GetSpecialStoragePolicy() -> CookieSettings ctor -> GetHostContentSettings()).
But relying on this structure implicitly wouldn't be great.

Let me think about this.

     host_content_settings_map_ = new HostContentSettingsMap(GetPrefs(), true);
 #if defined(ENABLE_EXTENSIONS)
     ExtensionService* extension_service =