Closed Bug 1574963 Opened 2 years ago Closed 2 years ago

Disable profile per channel/directory for the ESR

Categories

(Toolkit :: Startup and Profile System, task, P2)

task

Tracking

()

VERIFIED FIXED
mozilla71
Tracking Status
firefox-esr68 70+ verified
firefox70 --- fixed
firefox71 --- fixed

People

(Reporter: mkaply, Assigned: mkaply)

References

Details

Attachments

(2 files)

We were waiting for some input from enterprises that started deploying the ESR before deciding if we should turn off profile per install.

Based on experiences in this bug:

https://bugzilla.mozilla.org/show_bug.cgi?id=1572789

and comments on the enterprise list, I believe we should turn off this feature for the ESR until we have solved of these issues.

The main issues seem to be:

  1. default profile gets renamed to default-esr
  2. Two profiles are always created (default and default-esr)
  3. Migration from 32 to 64 bit (where 32 bit is uninstalled) causes a new profile (Program Files (x86) to Program Files

There are also unknown issues happen on Mac as well.

(In reply to Mike Kaply [:mkaply] from comment #0)

We were waiting for some input from enterprises that started deploying the ESR before deciding if we should turn off profile per install.

Based on experiences in this bug:

https://bugzilla.mozilla.org/show_bug.cgi?id=1572789

and comments on the enterprise list, I believe we should turn off this feature for the ESR until we have solved of these issues.

The main issues seem to be:

  1. default profile gets renamed to default-esr

Just to be clear, no profiles get renamed as a part of this feature. What is happening in bug 1572789 is that Firefox decides not to use an existing profile and instead creates a new one for use.

  1. Two profiles are always created (default and default-esr)

This is required in order to avoid cases of downgrading to pre-67 builds of Firefox.

Just to be clear, no profiles get renamed as a part of this feature. What is happening in bug 1572789 is that Firefox decides not to use an existing profile and instead creates a new one for use.

I phrased that poorly. I'm referring to the behavior that if on the ESR, the default profile is no longer called default, it's called default-esr, but there is an empty profile that uses the old name default.

This is creating problems for existing scripts and automation.

[Tracking Requested - why for this release]: Romain and I had discussed watching general feedback on this feature from enterprise before deciding whether or not to disable for ESR68. Based on what we've been seeing over the past week (as folks have started to deploy 68), it's causing issues so we should disable for now and figure out a plan moving forward.

Fixing tests for these is going to be problematic. All of the tests assume profile per channel.

Any thoughts on how best to accomplish this?

Flags: needinfo?(dtownsend)

Here's what the patch looked like:

bool nsToolkitProfileService::UseLegacyProfiles() {
  return StringEndsWith(
             NS_LITERAL_CSTRING(NS_STRINGIFY(MOZ_APP_VERSION_DISPLAY)),
             NS_LITERAL_CSTRING("esr")) ||
         !!PR_GetEnv("MOZ_LEGACY_PROFILES");
}

I'm not sure there is a good way. There are a few tests written to check that reverting to legacy profiles works, it might just mean making sure theose work on esr and disabling the rest.

Flags: needinfo?(dtownsend)
Type: defect → task
Priority: -- → P2

Hi, are there any updates on this bug? I'd like to send the ESR smoketesting email to the Enterprise list next week and it would be good if this change was included in it if we are going to proceed with making this change.

Flags: needinfo?(mozilla)

Unfortunately it's way too complicated to remove because it breaks all the tests. I'm going to add a quick windows only policy to disable it.

Flags: needinfo?(mozilla)
Pushed by mozilla@kaply.com:
https://hg.mozilla.org/integration/autoland/rev/18cdbda1b5e1
Add a policy for using legacy profiles on Windows. r=mossop
Pushed by mozilla@kaply.com:
https://hg.mozilla.org/integration/autoland/rev/eaa0c1e72e51
Add a policy for using legacy profiles on Windows. r=mossop

Forgot to #ifdef windows code. Fixed.

Flags: needinfo?(mozilla)
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla71
Assignee: nobody → mozilla

Is this something you wanted to uplift for 68.2esr?

Flags: qe-verify+
Flags: needinfo?(mozilla)

Yes, but I forgot the translation. As soon as that's approved and in, I'll request.

Flags: needinfo?(mozilla)
Pushed by mozilla@kaply.com:
https://hg.mozilla.org/integration/autoland/rev/009c68b4bc9b
Add description for LegacyProfiles policy. r=flod,fluent-reviewers

Comment on attachment 9097818 [details]
Bug 1574963 - Add a policy for using legacy profiles on Windows.

Beta/Release Uplift Approval Request

  • User impact if declined: Administrators not able to prevent creation of additional profiles (common problem).
    Putting on beta to match corresponding ESR.
  • Is this code covered by automated tests?: No
  • Has the fix been verified in Nightly?: No
  • 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): Low risk. Only affects Windows policy, code path already existed.
  • String changes made/needed: String involved, but l10n has already OKed English only for policy strings.

ESR Uplift Approval Request

  • If this is not a sec:{high,crit} bug, please state case for ESR consideration: This has been a consistent problem on the enterprise mailing list (ESR creating extra profiles and breaking people).
  • User impact if declined: Administrators not able to prevent creation of additional profiles (common problem).
    Putting on beta to match corresponding ESR.
  • Fix Landed on Version: 71
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): Low risk. Only affects Windows policy, code path already existed.
  • String or UUID changes made by this patch: String involved, but l10n has already OKed English only for policy strings.
Attachment #9097818 - Flags: approval-mozilla-esr68?
Attachment #9097818 - Flags: approval-mozilla-beta?
Attachment #9099361 - Flags: approval-mozilla-beta? approval-mozilla-esr68?

Comment on attachment 9097818 [details]
Bug 1574963 - Add a policy for using legacy profiles on Windows.

Allows enterprise users to disable profile-per-install via policy. l10n changes approved by product (English-only strings not a problem). Approved for 70.0b14 and 68.2esr.

Attachment #9097818 - Flags: approval-mozilla-esr68?
Attachment #9097818 - Flags: approval-mozilla-esr68+
Attachment #9097818 - Flags: approval-mozilla-beta?
Attachment #9097818 - Flags: approval-mozilla-beta+
Attachment #9099361 - Flags: approval-mozilla-esr68?
Attachment #9099361 - Flags: approval-mozilla-esr68+
Attachment #9099361 - Flags: approval-mozilla-beta?
Attachment #9099361 - Flags: approval-mozilla-beta+
QA Whiteboard: [qa-triaged]

Hi Mike, can you please add a scenario or some STR in order to be able to verify this fix, please let us know what is the expected behaviour in this case. Please let us know how do you want to proceed. Also, Dave, I know that you created the Dedicated feature, so I think it will be a good idea to have your opinion on this, maybe some risk areas. Thanks

Flags: needinfo?(mozilla)

Hi Mike, can you please add a scenario or some STR in order to be able to verify this fix, please let us know what is the expected behaviour in this case. Please let us know how do you want to proceed. Also, Dave, I know that you created the Dedicated feature, so I think it will be a good idea to have your opinion on this, maybe some risk areas. Thanks

This is the equivalent of setting the MOZ_LEGACY_PROFILES environment variable to turn this feature completely off.

I'll create a new ADMX file so you can test this.

Flags: needinfo?(mozilla)

I've added this policy to the ADMX file here:

https://github.com/mozilla/policy-templates/tree/master/windows

To test, put two copies of the ESR in two different directories and verify they share a profile and don't create separate profiles.

I verified this issue on Windows 10 (1903) with FF ESR 68.2(2019-10-10) and I can confirm the fix, only one profile is created. I see that the Firefox 71 and 70 flags are marked as fixed, this means that the fix should be verified also on 71 and 70?

Prerequisites that I did to be able to verify this issue on ESR:

  1. Go to https://github.com/mozilla/policy-templates
  2. Download the zip and from the windows folder copy the .admx in C:\Windows\PolicyDefinitions
  3. From the same folder (step2) go to the en-US and copy the .adml files into C:\Windows\PolicyDefinitions\en-US
  4. Give a Windows search after gpedit.msc -> the local Group Policy Editor user interface is open.
  5. Go to Administrative Templates -> Mozilla -> Firefox - in the normal way it doesn't make any difference from where you access it (Local Computer Policy or User Configuration)
  6. You will see the Legacy Profiles file, change enable or disable, depends on what do you want to do.

Please let me know if there is something more that needs to be done here.

That was exactly right. Thanks!

Status: RESOLVED → VERIFIED
QA Whiteboard: [qa-triaged]
Flags: qe-verify+
Duplicate of this bug: 1577330

I have a similiar problem on a mac. I am trying to restrict a user's web usage through the leechblock application. I can force install leechblock via policies, but all of the settings are lost when a new profile is created. Yet simply copying the firefox application file allows a user to create a new profile. Any extension of this policy to macs would be greatly appreciated.

My recommendation would be that you set the environment variables at the system level on the machine:

https://support.mozilla.org/en-US/kb/understanding-depth-profile-installation

Unfortunately there's no easy way to read Mac configuration profiles at startup in our current architecture.

You need to log in before you can comment on or make changes to this bug.