Implement profile-per-install

RESOLVED FIXED in Firefox 67

Status

()

enhancement
RESOLVED FIXED
10 months ago
2 days ago

People

(Reporter: mossop, Assigned: mossop)

Tracking

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

unspecified
mozilla67
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(relnote-firefox 67+, firefox67 fixed)

Details

Attachments

(3 attachments, 2 obsolete attachments)

(Assignee)

Description

10 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

10 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

10 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

10 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

10 months ago
See Also: → 1373244
(Assignee)

Updated

9 months ago
Blocks: 1098986
(Assignee)

Updated

8 months ago
Depends on: 1484844
(Assignee)

Updated

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

Updated

7 months ago
Depends on: 1491126

Updated

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

Updated

7 months ago
Depends on: 1491404

Comment 7

7 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

7 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

7 months ago
Depends on: 1493310
(Assignee)

Updated

7 months ago
Depends on: 1493315
Depends on: 1493386

Comment 9

7 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

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

Updated

6 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

6 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

6 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

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

Comment 16

6 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

6 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

6 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

5 months ago
Blocks: 1367391

Updated

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

Updated

3 months ago
Depends on: 1518587

Updated

3 months ago
Depends on: 1518766

Updated

3 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

3 months ago
Depends on: 1522694
Depends on: 1522836
(Assignee)

Comment 21

3 months ago

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

3 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

3 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

3 months ago
bugherder
Status: NEW → RESOLVED
Last Resolved: 3 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla67
(Assignee)

Updated

3 months ago
Blocks: 1518632
(Assignee)

Updated

3 months ago
Blocks: 1523024
(Assignee)

Updated

3 months ago
Blocks: 1522751
(Assignee)

Updated

3 months ago
Blocks: 1518634

Updated

2 months ago
Depends on: 1525262

Updated

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

2 months 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.

Updated

2 months ago
Depends on: 1526248

Updated

2 months ago
Depends on: 1526367
Depends on: 1526373

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

Updated

2 months ago
Depends on: 1527604
Depends on: 1527704

Updated

2 months ago
Depends on: 1527851

Updated

2 months ago
Depends on: 1528252

Updated

2 months ago
Depends on: 1528309

Updated

2 months ago
Depends on: 1529879
Depends on: 1530615

Updated

2 months ago
Depends on: 1530962
(Assignee)

Updated

2 months ago
No longer depends on: 1530615
Depends on: 1531719
Depends on: 1531799

Updated

2 months ago
Depends on: 1533009
(Assignee)

Updated

2 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!

(Assignee)

Comment 29

a month ago

(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
You need to log in before you can comment on or make changes to this bug.