Make ChromeGeolocationPermissionContextFactory a ProfileKeyedServiceFactory

chrome/browser/profiles/profile_impl.cc

Index: chrome/browser/profiles/profile_impl.cc
diff --git a/chrome/browser/profiles/profile_impl.cc b/chrome/browser/profiles/profile_impl.cc
index 7a2a57b93c031f9438de8e89df21b49d6b741320..794d2c170c02668407c83bcbdf0bfbe051d2d9f1 100644
--- a/chrome/browser/profiles/profile_impl.cc
+++ b/chrome/browser/profiles/profile_impl.cc
@@ -857,11 +857,7 @@ HostContentSettingsMap* ProfileImpl::GetHostContentSettingsMap() {
 
 content::GeolocationPermissionContext*
     ProfileImpl::GetGeolocationPermissionContext() {

[rpetterson, 2012/12/18 21:22:17]

Do you have any plans to eventually remove this function as well? (usually done
in a separate CL if there are a lot of instances in the codebase)

[John Knottenbelt, 2012/12/19 16:01:09]

Not sure yet. One problem is that RenderProcessHostImpl::CreateMessageFilters in
the content/ layer refers to BrowserContext::GetGeolocationPermissionContext, to
get the ChromeGeolocationPermissionContext. So we couldn't directly call
ChromeGeolocationPermissionContextFactory::GetForProfile because this would be a
layering violation.

Have you seen any similar issues / solutions with other profile keyed services?

On 2012/12/18 21:22:17, rpetterson wrote:

[rpetterson, 2012/12/19 22:22:44]

There are still a couple services that are in that situation and the "solution"
is to leave the getter as you have hear. The important part is that the Profile
no longer owns the object which you've taken care of with this CL :)

-  if (!geolocation_permission_context_.get()) {
-    geolocation_permission_context_ =
-        ChromeGeolocationPermissionContextFactory::Create(this);
-  }
-  return geolocation_permission_context_.get();
+  return ChromeGeolocationPermissionContextFactory::GetForProfile(this);
 }
 
 content::SpeechRecognitionPreferences*