1893687 - Dynamic profiles.ini changes for multi-process support

Status: ASSIGNED

(Toolkit :: Startup and Profile System, enhancement, P2)

Description

[Jared Hirsch [:jhirsch] (he/him) (Needinfo please)]

(Note: this bug seems large. Maybe we should split it?)

As discussed in [1], to make profiles.ini writable across concurrent instances, since we may be overwriting the default profile Path each time app focus switches to a different concurrently running Firefox instance, we want to update nsToolkitProfileService to only store nsToolkitProfile instances in memory while running, not the full contents of profiles.ini, and to only update the ini structures when flushing to disk.

We'll also want to add new properties to nsToolkitProfile: boolean mIsDirty (changed since last ini load) and boolean mIsNew (instance is new since last load), and use those new properties to update the nsToolkitProfileService ini parsing behavior to follow the algorithm sketched in [1]:

When attempting to update the data on disk or load during startup:

1. Load profiles.ini from disk into memory.
2. For each profile in it find the instance in memory based on matching the root directory:
   a. If we have such an instance and it is dirty then update the ini data.
   b. If we have an instance and it isn’t dirty then update our instance from the ini data.
   c. If we don’t have an instance then create a new nsToolkitProfile from the ini data.
3. For each instance in memory that we didn’t see in the ini data:
   a. If it is new then add it to the ini data.
   b. If it isn’t new then remove it from memory.
4. TODO: something similar for the general settings (note, this could be deferred to a followup bug, see below)
5. Write the ini data back to disk.

Step 4 above is still an ill-defined item, so we might just kick that to a followup bug if it's not clear what to do once we're in the code.

This will primarily affect nsToolkitProfileService::Flush() and other spots where we call mProfileDB.SetString.

Be sure to gate these changes on the build-time flag defined in bug 1893315.

[1] https://docs.google.com/document/d/1PP4NjlOBmwNJP9emu1Bk5LBk_LcD284xMZZ8gG11-S0/edit#heading=h.rd74ekz7fx9v

Comment 1

[Jared Hirsch [:jhirsch] (he/him) (Needinfo please)]

Attachment: Bug 1893687 - Initial WIP sketch of profiles.ini merge behavior r?mossop!,niklas

Incomplete, but I think enough here to get feedback on the basic approach.

Not yet accounting for async MozPromise-returning invocation or file
locking on profiles.ini; planning to deal with those in a part 2.

This compiles, but tests are broken.

Comment 2

[Jared Hirsch [:jhirsch] (he/him) (Needinfo please)]

Splitting out the "make Flush async" and "implement file locking on profiles.ini" tasks into sub-bugs.