Closed Bug 1474285 Opened 2 years ago Closed 2 years ago

Implement profile-per-install

Categories

(Toolkit :: Startup and Profile System, enhancement)

enhancement
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla67
Tracking Status
relnote-firefox --- 67+
firefox67 --- fixed

People

(Reporter: mossop, Assigned: mossop)

References

(Depends on 1 open bug, Regressed 2 open bugs)

Details

(Keywords: feature)

Attachments

(3 files, 2 obsolete files)

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.
Attached file Bug 1474285: Make nsINIParser mutable. (obsolete) —
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
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.
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.
See Also: → 1373244
Blocks: 1098986
Depends on: 1484844
Depends on: 1484846
Attachment #8990697 - Attachment is obsolete: true
Attachment #8990696 - Attachment is obsolete: true
Depends on: 1491126
Depends on: 1491305
Depends on: 1491404
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)
(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: 1493310
Depends on: 1493315
Depends on: 1493386
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
Depends on: 1499749
Attachment #8990698 - Attachment description: Bug 1474285: Implement profiles-per-install. → Bug 1474285: Implement profiles-per-install. r=froydnj
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.
Then everytime I upgrade I will have all settings erased. That doesn't sound like a good design.
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.
Blocks: 1367391
Depends on: 1518451
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
Depends on: 1522694

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.

Pushed by dtownsend@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/e69cac07b209
Implement dedicated profiles per install. r=froydnj, r=Gijs
Pushed by dtownsend@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/58babf220962
Implement dedicated profiles per install. r=froydnj, r=Gijs
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla67
Blocks: 1518632
Blocks: 1523024
Blocks: 1522751
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

(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

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

Depends on: 1527604
Depends on: 1527704
Depends on: 1527851
Depends on: 1528252
Depends on: 1528309
Depends on: 1529879
Depends on: 1530962
No longer depends on: 1530615
Depends on: 1531799
Depends on: 1533009
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!

Depends on: 1533677
No longer depends on: 1527704
Regressions: 1527704

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.

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

Regressions: 1546694
Regressions: 1553929
Regressions: 1554252
Regressions: 1553604
Regressions: 1554564
Regressions: 1554577
Regressions: 1554419
Regressions: 1553526
Regressions: 1553399
Depends on: 1556592
Regressions: 1556592
No longer depends on: 1556592
No longer regressions: 1556592
Regressions: 1557014
See Also: → 1557117
See Also: → 1557125
Regressions: 1558597
Regressions: 1564580
No longer regressions: 1553399
You need to log in before you can comment on or make changes to this bug.