Closed Bug 1528082 Opened 9 months ago Closed 5 months ago

Add an environment variable to disable dedicated profiles

Categories

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

enhancement

Tracking

()

VERIFIED FIXED
mozilla69
Tracking Status
firefox68 --- verified
firefox69 --- verified

People

(Reporter: mossop, Assigned: mossop)

References

Details

Attachments

(1 file)

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.

Priority: -- → P3

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

Assignee: nobody → dtownsend
Priority: P3 → P1
Pushed by dtownsend@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/fe329dcd1c71
Add an environment variable to disable dedicated profiles for enterprise use. r=froydnj
Status: NEW → RESOLVED
Closed: 5 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla69

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:
Attachment #9072680 - Flags: approval-mozilla-beta?

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

approved for 68.0b14

Attachment #9072680 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Flags: qe-verify+
QA Contact: cristian.baica

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.

Status: RESOLVED → VERIFIED
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.