1925480 - Fenix shouldn't use `nsToolkitProfileService` to identify a profile folder

Status: NEW

(Toolkit :: Startup and Profile System, defect)

Description

[Dave Townsend [:mossop]]

Currently when Fenix starts up Gecko we do the following steps:

1. Set the HOME environment variable to point to the app's file storage location.
2. Call into XRE_main.
3. Eventually call SelectProfile in order to find the Gecko profile directory which:
   3.1 Creates the nsToolkitProfileService
   3.2 Which finds or creates a profiles.ini file in the file storage area.
   3.3 Loads and parses profiles.ini to determine the default profile for the current install.
   3.4 Finds or creates the default profile folder to pass back to nsAppRunner.
4. We then attempt to lock the profile folder in case another process is using it.
5. Then we do various file accesses to verify Gecko compatibility with the profile folder and whether we need to flush the startup caches.
6. Before we finally run Gecko.

Steps 3 to 5 here seem unnecessary on Android. There is currently only one profile folder (and even if that changes in the future we're likely to manage profile folders from the Fenix side) so there is no need to use profiles.ini. I believe that only one main Gecko process can be running at a time so there is no need to lock the profile. We can purge the startup cache based solely on application build ID rather than additional checks. And for compatibility I wonder if we assume that downgrades don't happen or if they do we can detect in Fenix and handle from that side directly.

All this adds up to a bunch of unnecessary I/O on Gecko startup which for phone devices is probably well worth getting rid of. The one niggle here is that all current Fenix users will have a randomly named profile folder. Historically this was done on Desktop as a mitigation against security vulnerabilities that might allow access to profile data if the path was known. I suspect that we still want to keep this so we can't just use a fixed profile path (and besides then we'd have to manage moving existing users profile folders which sounds fraught). But I think we can still mostly simplify this if we can cache some things on the Fenix side.

1. Create a new build flag, MOZ_SINGLE_PROFILE which is set on Android and unset on desktop.
2. Before calling into Gecko if we know that this is a new install create a randomly named profile folder and store its path in the XRE_PROFILE_PATH environment variable. If this isn't a new install and we have cached the profile folder name that store that in the environment.
3. If Fenix detects it is a downgrade it can handle assigning a new profile folder and deleting the old. Likewise if purging caches is needed it can pass the -purgecaches command line argument.
4. Launch Gecko. When Gecko attempts to figure out the profile, if MOZ_SINGLE_PROFILE is set and XRE_PROFILE_PATH is set it will just use that, otherwise it will continue to use the profile manager to find the profile from profiles.ini.
5. Gecko skips profile locking and file I/O associated with compatibility checking when MOZ_SINGLE_PROFILE is set.
6. After Gecko starts Fenix retrieves the path of the profile and caches it for the next launch.

Strictly speaking we could simplify step 3 by assuming that there is only one profile folder anyway and we could just scan the directory to find it (either on Fenix or Gecko sides). I worry slightly about the admittedly small chance where a corrupt profiles.ini might cause some users to end up with two profile folders so I think it is safer to just use the existing logic when we don't already know the profile folder in use.

Jeff, I've made some assumptions here about what is possible on the Fenix side prior to launching Gecko, does this seem feasible?

Comment 1

[Jeff Boek [:boek]]

On the surface I would agree with your assumptions. But I'm going to rope in :owlish to chime in here as the GV lead they will definitely be able to answer with more confidence than I can 😅.