1528082 - Add an environment variable to disable dedicated profiles

Status: VERIFIED FIXED

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

Description

[Dave Townsend [:mossop]]

We already do this for Snap, but in case the method of detecting Snap changes it would be good to add a specific environment variable for it, maybe MOZ_DISABLE_DEDICATED_PROFILE.

Comment 1

[sdowdy]

Please also add a Pref (mozilla.cfg) for this to make my life easier (i stopped creating Front-End-Setup scripts with renamed binaries to exec after EnvVar setups a while back ( ... ; exec ${progdir}/firefox.real ) and really don't want to have to start doing that again.

I install firefox to versioned shared directories (e.g. /usr/local/firefox-76.0/), so every release from here out will screw up my users. I did not detect this problem when i swung the default 'firefox' symlink (/usr/local/firefox->firefox-67.0) in my shared linux environment because i test with 'firefox -P ...' which does not exhibit this problem.

I had to backout 67.0 after the first user reported "I lost all my bookmarks". (yes, user apparently didn't read/understand the popups and overridden startpage, but that's the nature of this business).

I believe this is represented in 'compatibility.ini' by the LastAppDir or such).

[Compatibility]
LastVersion=67.0_20190516215225/20190516215225
LastOSABI=Linux_x86_64-gcc3
LastPlatformDir=/var/autofs/mnt/linux-amd64/common/local/firefox-67.0
LastAppDir=/var/autofs/mnt/linux-amd64/common/local/firefox-67.0/browser

Note: clearly the NFS automounter is involved here, and symlink resolution gives a different resolved path).

I find this change to be inexplicable. Users who work with multiple profiles (i have 40 in profiles.ini right now (sigh)), or multiple firefox installs KNOW how to deal with incompatibilities. Everybody else is only going to be inconvenienced when their existing profile is ripped out from under them and they have to be pointed back to their old profile.

Thanks,
--stephen

Comment 2

[Dave Townsend [:mossop]]

Attachment: Bug 1528082: Add an environment variable to disable dedicated profiles for enterprise use. r=froydnj

Comment 3

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/fe329dcd1c71
Add an environment variable to disable dedicated profiles for enterprise use. r=froydnj

Comment 4

[Arthur Iakab [arthur_iakab]]

https://hg.mozilla.org/mozilla-central/rev/fe329dcd1c71

Comment 5

[Dave Townsend [:mossop]]

Comment on attachment 9072680 [details]
Bug 1528082: Add an environment variable to disable dedicated profiles for enterprise use. r=froydnj

Beta/Release Uplift Approval Request

• User impact if declined: Enterprise users will have no mechanism for disabling dedicated profiles in the next ESR.
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Simple addition of an environment variable to check to activate a pre-existing codepath.
• String changes made/needed:

Comment 6

[Julien Cristau [:jcristau]]

Comment on attachment 9072680 [details]
Bug 1528082: Add an environment variable to disable dedicated profiles for enterprise use. r=froydnj

approved for 68.0b14

Comment 7

[Razvan Maries]

https://hg.mozilla.org/releases/mozilla-beta/rev/5c9288e6d56a

Comment 8

[Cristian Baica [:cbaica], Release Desktop QA]

Tested the implementation using latest Firefox 69.0a1, Firefox 68.0b14, Firefox 68.0 ESR (intermediary build from treeherder) on Ubuntu 18.04, macOS 10.14 and Windows 10 x64.
The dedicated profiles feature is off when MOZ_LEGACY_PROFILES is set to 1 at environment level, while the downgrade protection is still enabled.