ContextQMD
Back to Chromium

ProfileKeyedServiceFactory Overview

chrome/browser/profiles/profile_keyed_service_factory.md

149.0.7827.25.7 KB
Original Source

ProfileKeyedServiceFactory Overview

This document present the newly added intermediate interface ProfileKeyedServiceFactory that is used to create instances ofKeyedService more efficiently and with more control for each profile types.

[TOC]

Purpose and implementation decisions

go/profile-keyed-services (Google Internal)

Description

ProfileKeyedServiceFactory is an intermediate interface to create KeyedServiceFactory under chrome/ that provides a more explicit way of creating services for non regular profiles.

The main purpose of this class is to provide an easy and efficient way to set the redirection logic for different profile types using a ProfileSelections instance that contains the logic of profile redirection. Those profile choices are overridable by setting the proper combination of ProfileSelection and Profile type in the ProfileSelections instance passed in the constructor.

This interface also helps in changing the default behavior of creating services for non regular profiles. Previously, most services used to create services with no checks on profile types, meaning that most existing services are created for mostly all profile types. Changing the default behavior per profile type allows for a clearer and better targeted usage of KeyedServices.

This work is mirrored on to RefCountedProfileKeyedServiceFactory for keyed services that are ref counted.

Profile types

There are two implementations of Profile:

  • Original Profile (aka ProfileImpl): A profile which information are stored and can be reused (usually a user profile).
  • Off The Record (OTR) Profile (aka OffTheRecordProfileImpl): Owned and tied to an Original Profile, this profile is never saved on disk.

There are different types of Profiles that can be both Original and OTR:

  • Regular Profile: is a normal user profile.
  • Incognito Profile: is the Primary OTR of a Regular Profile.
  • Guest Profile: The OTR profile for a Guest is the profile used for browsing, since no information is saved. The equivalent Original Profile is a dummy profile that exists only to hold on to the OTR Profile, it is never used.
  • System Profile: The OTR profile for a System profile is used to display the Profile Picker, there are no information to save. The equivalent Original Profile is a dummy Profole that exists only to hold on to the OTR Profile, it is never used.
  • Signin Profile: Part of the Ash internal profiles. (More information needed)
  • LockScreen Profile: Part of the Ash internal profiles. (More information needed)
  • LockScreenApp Profile: Part of the Ash internal profiles. (More information needed)
  • Other Types? (More information needed)

Platform specific considerations

  • Ash has additional "irregular" profiles that are not used for actual browsing (e.g. signin profile, lock screen profile).
  • Android and Ash don't have system profiles.
  • Android and Ash don't support multiple regular user profiles.
  • Ash has a "device-level" guest mode where all the profiles are guest. IsGuestSession() returns true for all profiles, and is no longer exclusive with other profile type getter functions.
  • iOS does not use profiles at all. It has another subclass of BrowserContext (called BrowserState) and do not use any other profile types described above.

ProfileSelections

Note that this structure is independent of the ProfileKeyedServiceFactory interface and can be used in any other context that needs to select a profile based on its type.

ProfileSelections is a helper structure that maps a ProfileType to a redirection logic for that profile. A ProfileSelection attribute describes how to pick the appropriate profile based on the input profile type. ProfileSelections manages these choices and returns the proper profile.

This structure has one main public method that returns the selected profile based on the ProfileSelection choice:

c++
Profile* ProfileSelections::ApplyProfileSelection(Profile* profile);

Effectivley this method extracts the type of the input profile, searches for the equivalent ProfileSelection attribute, apply it to the profile, and return the profile that results of the selection.

ProfileSelections supported types:

  • Regular Profile.
  • Guest Profile.
  • System Profile.
  • Ash Internal Profiles.

ProfileSelection attributes description:

  • kNone: Always returns nullptr, no profile is selected.
  • kOriginalOnly: Only return the profile if it is an Original Profile, OTR profiles are filtered out (returning nullptr).
  • kOwnInstance: Always returns itself, both Original and OTR profiles.
  • kRedirectedToOriginal: Always returns the Original profile, if the input is the Original profiles, it returns itself, if the input is an OTR profile, it returns it's equivalent Original profile.
  • kOffTheRecordOnly: Only return the profile if it is an OTR profile, Original profiles are filtered out (returning nullptr).

Creating a ProfileSelections instance

ProfileSelections can only be created through a builder, ProfileSelections::Builder which provides a method to properly set the ProfileSelection choices for each supported profile type.

The default values that are set are:

  • Regular Profile: kOriginalOnly.
  • Guest Profile: kNone
  • System Profile: kNone
  • Ash Internal Profiles: Follows Regular Profile value.

ProfileSelections also has some predefined static builders in its interface that provides common usages with standard behaviors.

Future work

It seems that the Ash internal profiles are very similar to the System Profile, meaning that similar cleanup for the services is potentially possible. More analysis on this will be done and an experiment might be launched to transition this type to be using ProfileSelection::kNone as well.