Autoconfig vs. Policy-templates : and the winner is?

[ghost]

Hi,

I've been using Firefox's Autoconfig far before the new Policy templates. I use both for the time being. When both handle a same setting with different values which of the two wins the battle?

Example: Firefox screenshots, true or false

With Autoconfig : lockPref("extensions.screenshots.disabled", true); With Policy template :"DisableFirefoxScreenshots": true,

I have disabled Firefox screenshots only with the policy-template and this leads to extensions.screenshots.disabled:false in my about:config, just to point out that the policy-template in this case does handle a specific about:config setting.

Should I set one to true and the other to false, which of the two will take precedence?

Thanks

[mkaply]

The answer is autoconfig is executed first, so policy templates would override it.

[ghost]

OK, thanks @mkaply . Of course I could have experienced myself but the challenge was rather intended to illustrate my questionings regarding two Firefox preferences' lockers working on same settings even if Privacy templates can manage user choices that Autoconfig cannot (such as Firefox Sync).

I remain nevertheless puzzled that either (in this case Policy Templates because it executes after Autoconfig) can modify what has been locked, and locked therefor means in the area of Firefox itself.

Thanks.

[mkaply]

I remain nevertheless puzzled that either (in this case Policy Templates because it executes after Autoconfig) can modify what has been locked, and locked therefor means in the area of Firefox itself.

The concept of locking is about the user being able to change a preference, not Firefox. Even in the days of legacy extensions, an extension could unlock a preference and do what they want with it.

There will always be a weird relationship between Autoconfig and policies because we are not always prefs for what the policies does.

In the long run, I'd love for folks not to have to use Autoconfig at all.

My general statement is "use Policies as much as possible, use autoconfig for stuff that can't be set in policies (yet)"

[ghost]

The concept of locking is about the user being able to change a preference, not Firefox.

OK, I can conceive that, I wasn't thinking correctly.

In the long run, I'd love for folks not to have to use Autoconfig at all.

That would make sens in that both share a common action ground, more sense even given Policy templates seems to handle settings more in-depth so to say given it performs beyond about:config settings.

My general statement is "use Policies as much as possible, use autoconfig for stuff that can't be set in policies (yet)"

That's good sense and maybe as such why I've adopted this statement as soon as I realized that at the time Policy templates wasn't fully mature yet. The first incentive in my case was that it could handle Firefox Sync (within Firefox accounts) with "DisableFirefoxAccounts" given Autoconfig no longer could starting Firefox 57+ (cannot remember what version exactly) from what I concluded that Policy templates was closer to the browser's core than Autoconfig. But that's nothing but a neophyte's basic logic!

Thanks for having brought this insight.

EDIT: I forgot to mention the following when quoting,

In the long run, I'd love for folks not to have to use Autoconfig at all.

My belief is that Autoconfig would remain pertinent in that it allows tailored tuning which may not be, or not always be as tailored with Policy templates. For example a user who wishes (as I do) to include several about:config settings he has in a profile-specific user.js file, in Autoconfig in order to have these about:config settings apply to any new Firefox profile. The point is Autoconfig, because of its basic relationship to about:config settings (with moreover "enhanced" lockPref and defaultPref plus two other less used), is handled easily when Policy templates, because they consider (at least in some schemes) wider areas of Firefox code, may not be as suitable in this scenario... unless I'm missing something.

[Atavic]

OK, I can conceive that, I wasn't thinking correctly.

The OSI Model may help. The user is the last chain after the application, in this case, Firefox.