Implement profile-per-install

RESOLVED FIXED in Firefox 67

Status

()

RESOLVED FIXED
8 months ago
6 days ago

People

(Reporter: mossop, Assigned: mossop)

Tracking

(Depends on: 6 bugs, Blocks: 2 bugs, {feature})

unspecified
mozilla67
feature
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox67 fixed)

Details

Attachments

(3 attachments, 2 obsolete attachments)

(Assignee)

Description

8 months ago
This is an alternate plan to bug 1373244 wherein we use a dedicated profile for each install of Firefox on the system as identified by a hash of the installation directory. In order to identify which install to give the current default profile to we look in compatibility.ini to see which install last launched the profile. Other installs receive a clean new profile.

Most users with just one install of Firefox on their system will see no effect from this change.

To support downgrade scenarios we create an old-style default profile in profiles.ini for older versions of Firefox to use.
(Assignee)

Comment 1

8 months ago
Created attachment 8990696 [details]
Bug 1474285: Make nsINIParser mutable.

In order to implement profile-per-install we need a new mutable datastore
alongside profiles.ini. Using an INI file makes sense however the C++ INI
parser is not mutable. This adds mutability and a method for writing the INI
data to disk.

In the future this can replace nsIINIParser.

MozReview-Commit-ID: L4VoIPe1OGS
(Assignee)

Comment 2

8 months ago
Created attachment 8990697 [details]
Bug 1474285: Expose a unique hash for the application install directory.

Profile-per-install uses a hash of the install directory to identify different
installs of Firefox. This exposes the existing cityhash generated hash from
nsXREDirProvider and makes it available on all platforms.
(Assignee)

Comment 3

8 months ago
Created attachment 8990698 [details]
Bug 1474285: Implement dedicated profiles per install. r=froydnj

Uses a different profile depending on the install directory of the application.
installs.ini is used to map a profile directory to the install directory hash.
If no profile is marked as default for the current install the old-style profile
default is used assuming it was last run with the current application.
Always creates an old-style default profile if one does not exist to allow
previous versions of the application to use a different profile.
(Assignee)

Updated

8 months ago
See Also: → bug 1373244
(Assignee)

Updated

8 months ago
Blocks: 1098986
(Assignee)

Updated

6 months ago
Depends on: 1484844
(Assignee)

Updated

6 months ago
Depends on: 1484846
Attachment #8990697 - Attachment is obsolete: true
Attachment #8990696 - Attachment is obsolete: true
(Assignee)

Updated

5 months ago
Depends on: 1491126

Updated

5 months ago
Depends on: 1491305
Depends on: 1491311
(Assignee)

Updated

5 months ago
Depends on: 1491404

Comment 7

5 months ago
Hey, wanted to get some info on this proposed change. 

This would be an additional, kind of meta-profile that maps 1 to 1 with installations of Firefox, in addition to the existing profiles we have now, right? 

This wouldn't change how current profiles operate, correct? 

Would this exist on a per-computer-per-installation-per-OS-userprofile level? Or would it be able to exist per-computer-per-installation?
Flags: needinfo?(dtownsend)
(Assignee)

Comment 8

5 months ago
(In reply to Su-Young Hong from comment #7)
> Hey, wanted to get some info on this proposed change. 
> 
> This would be an additional, kind of meta-profile that maps 1 to 1 with
> installations of Firefox, in addition to the existing profiles we have now,
> right? 

Not sure I really understand this.

> This wouldn't change how current profiles operate, correct? 

Yes, it changes how the default profile is chosen.

> Would this exist on a per-computer-per-installation-per-OS-userprofile
> level? Or would it be able to exist per-computer-per-installation?

Per-computer-per-install.

More details will be coming in a newgroup post soon.
Flags: needinfo?(dtownsend)
Depends on: 1492767
Depends on: 1492832
(Assignee)

Updated

5 months ago
Depends on: 1493310
(Assignee)

Updated

5 months ago
Depends on: 1493315
Depends on: 1493386

Comment 9

5 months ago
Hi Dave, 

Thanks so much for meeting last week and explaining the profile creation changes to me. 

Like we discussed, the following telemetry would be very helpful for us to deal with this change. 

* is_stubprofile: 
	- indicates if a profile was created as a stub profile (as opposed to the primary profile)
* profile_creation_date:
	- keep this probe the way it is (so no changes to it's current behavior)
* first_run_date: 
	- field which indicates the timestamp of when the first run of the profile is. 

:chutten, :janerik, do you agree with the above? are there any other measurements we should take in light of the changes to profile creation behavior?
Flags: needinfo?(jrediger)
Flags: needinfo?(chutten)
I think that'll cover it.

To me the method of collection is the biggest question mark. We have a `profile` section in the Telemetry Environment[1] for the profile creation date, but a scalar[2] for any date of profile directory age scans.

For stub profile and first run date I would think we'll need to add them to the profile section of the Environment, which means managing and persisting them outside of the usual profile mechanism and code for storing and loading that information. It also means coming up with plans for corner cases (for instance, what happens when the profile is reset? And do we want some sort of integrity mechanism in case the user tries to duplicate the persisted profile information?). It also means updating the schema[3], and getting it included in relevant derived datasets (main_summary as the minimum, but I expect you, Su, have a longer list than that). And documentation and testing and Data Collection Review, of course.

If we're going to this effort it might be worth documenting some shortcomings of our current profile data collections and seeing if there are holes we can address "along the way" as it were.

[1]: https://firefox-source-docs.mozilla.org/toolkit/components/telemetry/telemetry/data/environment.html#profile
[2]: https://searchfox.org/mozilla-central/source/toolkit/modules/ProfileAge.jsm#122
[3]: https://github.com/mozilla-services/mozilla-pipeline-schemas/blob/dev/templates/include/telemetry/environment.1.schema.json
Flags: needinfo?(chutten)
:chutten pretty much covered it all.
Flags: needinfo?(jrediger)
(Assignee)

Comment 12

5 months ago
(In reply to Su-Young Hong from comment #9)
> Hi Dave, 
> 
> Thanks so much for meeting last week and explaining the profile creation
> changes to me. 
> 
> Like we discussed, the following telemetry would be very helpful for us to
> deal with this change. 
> 
> * is_stubprofile: 
> 	- indicates if a profile was created as a stub profile (as opposed to the
> primary profile)

Filed bug 1495794

> * profile_creation_date:
> 	- keep this probe the way it is (so no changes to it's current behavior)
> * first_run_date: 
> 	- field which indicates the timestamp of when the first run of the profile is.
> is. 

Filed bug 1495792
See Also: → bug 1495794
See Also: → bug 1495792
Depends on: 1499388
Depends on: 1499395
(Assignee)

Updated

4 months ago
Depends on: 1499749
Depends on: 1499760
Attachment #8990698 - Attachment description: Bug 1474285: Implement profiles-per-install. → Bug 1474285: Implement profiles-per-install. r=froydnj

Comment 13

4 months ago
The terms in the issue description are not clear to me.  What exactly is an installation or installation directory?  I normally download a tarball of a new version of firefox and unpack it into /usr/local/firefox-NN and I might then update the 'firefox' command to point to it.  Do these count as distinct installations?
(Assignee)

Comment 14

4 months ago
(In reply to als from comment #13)
> The terms in the issue description are not clear to me.  What exactly is an
> installation or installation directory?  I normally download a tarball of a
> new version of firefox and unpack it into /usr/local/firefox-NN and I might
> then update the 'firefox' command to point to it.  Do these count as
> distinct installations?

Yes, because they are in different directories.

Comment 15

4 months ago
Then everytime I upgrade I will have all settings erased. That doesn't sound like a good design.

Comment 16

4 months ago
Will I be able to force a particular profile no matter what the installation directory?  

You'll need to make this clear to Linux distributions so that desktop short cuts have a fixed profile built into them, just in case the installation directory changes.
(Assignee)

Comment 17

4 months ago
(In reply to als from comment #16)
> Will I be able to force a particular profile no matter what the installation
> directory?

Firefox will continue to respect -P and --profile command line arguments?
(Assignee)

Comment 18

4 months ago
(In reply to Dave Townsend [:mossop] (he/him) from comment #17)
> (In reply to als from comment #16)
> > Will I be able to force a particular profile no matter what the installation
> > directory?
> 
> Firefox will continue to respect -P and --profile command line arguments?

Should have been no question mark there.
This looks like it could break package managers where the canonical path to the package's files includes a version number or other package instance identifier (similar to comment #13, but automated).  NixOS is a well-known example of this, but it also appears to be the case for our Snap package, which we directly support and promote (see https://snapcraft.io and bug 1297513).

I've verified that compatibility.ini in the profile of a Snap-managed Firefox contains paths with the Snap package revision number; if I understand this patch correctly, that means we'd create a new profile for every upgrade.
(Assignee)

Updated

3 months ago
Blocks: 1367391
Depends on: 1518451
Depends on: 1518467
(Assignee)

Updated

a month ago
Depends on: 1518587
Depends on: 1518766
Depends on: 1518799
Attachment #8990698 - Attachment description: Bug 1474285: Implement profiles-per-install. r=froydnj → Bug 1474285: Implement dedicated profiles per install. r=froydnj
Keywords: feature
(Assignee)

Comment 20

a month ago

Created attachment 9037710 [details]
Bug 1474285: Make sure to clear the default profile correctly when removing a profile. r=froydnj

(Assignee)

Updated

28 days ago
Depends on: 1522694
Depends on: 1522836
(Assignee)

Comment 21

27 days ago

Created attachment 9039265 [details]
Bug 1474285: Only snatch the old default profile if it has not been explicitly selected by another install.

When setting the default profile for an install mark it as locked so another
install will not steal it. The exception is a non-OS default install selecting
the old default profile on startup where we want to allow an OS default install
to steal it if run.

Comment 22

22 days ago
Pushed by dtownsend@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/e69cac07b209
Implement dedicated profiles per install. r=froydnj, r=Gijs

Comment 23

22 days ago
Pushed by dtownsend@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/58babf220962
Implement dedicated profiles per install. r=froydnj, r=Gijs

Comment 24

21 days ago
bugherder
Status: NEW → RESOLVED
Last Resolved: 21 days ago
status-firefox67: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla67
(Assignee)

Updated

21 days ago
Blocks: 1518632
(Assignee)

Updated

21 days ago
Blocks: 1523024
(Assignee)

Updated

21 days ago
Blocks: 1522751
(Assignee)

Updated

21 days ago
Blocks: 1518634
Depends on: 1525262
Depends on: 1525297

At some point there were discussions about having some runtime environment variable or similar to allow developers to opt out of profile per install. Did that get implemented? I can't find it.

Depends on: 1525889
(Assignee)

Comment 26

14 days ago

(In reply to Magnus Melin [:mkmelin] from comment #25)

At some point there were discussions about having some runtime environment variable or similar to allow developers to opt out of profile per install. Did that get implemented? I can't find it.

I don't recall this. There is a way to build with it disabled.

Depends on: 1526248
Depends on: 1526367
Depends on: 1526373

Found it now, it's implemented: You just start with -allow-downgrade

Updated

8 days ago
Depends on: 1527604
Depends on: 1527704

Updated

7 days ago
Depends on: 1527851
Depends on: 1528252
Depends on: 1528309
You need to log in before you can comment on or make changes to this bug.