Implement profile-per-install

RESOLVED FIXED in Firefox 67

Status

()

enhancement
RESOLVED FIXED
11 months ago
2 days ago

People

(Reporter: mossop, Assigned: mossop)

Tracking

(Depends on 1 bug, Regressed 5 bugs, {feature})

unspecified
mozilla67
Points:
---

Firefox Tracking Flags

(relnote-firefox 67+, firefox67 fixed)

Details

Attachments

(3 attachments, 2 obsolete attachments)

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

11 months ago
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

11 months ago
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

11 months ago
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

11 months ago
See Also: → 1373244
Assignee

Updated

11 months ago
Blocks: 1098986
Assignee

Updated

10 months ago
Depends on: 1484844
Assignee

Updated

10 months ago
Depends on: 1484846

Updated

10 months ago
Attachment #8990697 - Attachment is obsolete: true

Updated

10 months ago
Attachment #8990696 - Attachment is obsolete: true
Assignee

Updated

9 months ago
Depends on: 1491126
Depends on: 1491311
Assignee

Updated

9 months ago
Depends on: 1491404

Comment 7

9 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

9 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

9 months ago
Depends on: 1493310
Assignee

Updated

9 months ago
Depends on: 1493315
Depends on: 1493386

Comment 9

9 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)
(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: → 1495794
See Also: → 1495792
Depends on: 1499388
Depends on: 1499395
Assignee

Updated

8 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

8 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?
(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

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

Comment 16

8 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.
(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?
(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

7 months ago
Blocks: 1367391
Depends on: 1518467
Assignee

Updated

5 months ago
Depends on: 1518587

Updated

5 months ago
Depends on: 1518799
Attachment #8990698 - Attachment description: Bug 1474285: Implement profiles-per-install. r=froydnj → Bug 1474285: Implement dedicated profiles per install. r=froydnj
Assignee

Updated

5 months ago
Depends on: 1522694
Depends on: 1522836

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

5 months 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

5 months 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

5 months ago
bugherder
Status: NEW → RESOLVED
Closed: 5 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla67
Assignee

Updated

5 months ago
Blocks: 1518632
Assignee

Updated

5 months ago
Blocks: 1523024
Assignee

Updated

5 months ago
Blocks: 1522751
Assignee

Updated

5 months ago
Blocks: 1518634

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

(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: 1526373

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

Updated

4 months ago
Depends on: 1527604
Depends on: 1527704

Updated

4 months ago
Depends on: 1527851
Depends on: 1530615
Assignee

Updated

4 months ago
No longer depends on: 1530615
Depends on: 1531719
Depends on: 1531799
Assignee

Updated

3 months ago
Blocks: 1533077

I am sorry if this is not the correct place to make a comment regarding this new feature, but I recently made a new Nightly install. I got the message regarding the new profile.

I understood that syncing this profile with Firefox Account I would get back my previous Nightly windows and tabs.

This didn't happen.

I'd like to if I was mistaken and this is the expected behavior, or if it's a bug I should file. Thanks!

(In reply to Gabriela [:gaby2300] from comment #28)

I am sorry if this is not the correct place to make a comment regarding this new feature, but I recently made a new Nightly install. I got the message regarding the new profile.

I understood that syncing this profile with Firefox Account I would get back my previous Nightly windows and tabs.

This didn't happen.

I'd like to if I was mistaken and this is the expected behavior, or if it's a bug I should file. Thanks!

It should allow you to access the tabs on your other install through the synced tabs feature. If that isn't working please file a bug at https://bugzilla.mozilla.org/enter_bug.cgi?product=Firefox&component=Sync

(In reply to Dave Townsend [:mossop] (he/him) from comment #29)

It should allow you to access the tabs on your other install through the synced tabs feature. If that isn't working please file a bug at https://bugzilla.mozilla.org/enter_bug.cgi?product=Firefox&component=Sync

I surely used Sync so I think tabs should been synced too. I think I will file the bug. The worst that could happen is that it's invalid or wont fix. I would appreciate your thoughts!

No longer depends on: 1527704
Regressions: 1527704

Comment 32

2 months ago

this is not resolved for me.

I just installed nightly on windows and at the end of installer process if the checkbox to run is enabled (default), when I press finish it tells me firefox is already running.

nightly should automatically create the nightly profile even if regular firefox is running during nightly install.

Comment 33

2 months ago

(In reply to mailinglists35 from comment #32)

nightly should automatically create the nightly profile even if regular firefox is running during nightly install.

correction: it seems to create the profile, but the installer checkbox issue is present. so in the installer i must uncheck the box to launch nightly, then only then I can finish the installing and it launches correctly from installed shortcuts

(In reply to mailinglists35 from comment #32)

this is not resolved for me.

I just installed nightly on windows and at the end of installer process if the checkbox to run is enabled (default), when I press finish it tells me firefox is already running.

nightly should automatically create the nightly profile even if regular firefox is running during nightly install.

Please file a new bug.

Assignee

Updated

2 months ago
Regressions: 1546694

Updated

24 days ago
Regressions: 1553929

Updated

23 days ago
Regressions: 1554252

Updated

21 days ago
Regressions: 1553604

Updated

21 days ago
Regressions: 1554564

Updated

21 days ago
Regressions: 1554577

Updated

20 days ago
Regressions: 1554419

Updated

19 days ago
Regressions: 1553526

Updated

19 days ago
Regressions: 1553399

Updated

13 days ago
Depends on: 1556592

Updated

13 days ago
Regressions: 1556592
Assignee

Updated

13 days ago
No longer depends on: 1556592
No longer regressions: 1556592

Updated

12 days ago
Regressions: 1557014

Updated

11 days ago
See Also: → 1557117
See Also: → 1557125

Updated

3 days ago
Regressions: 1558597
You need to log in before you can comment on or make changes to this bug.