User.js: sticky: mozilla.cfg pref issues

[Thorin-Oakenpants]

background: https://github.com/intika/Librefox-Firefox/issues/7, I'll use this OP to document them

:banana: don't slip up on these

• 2802 privacy.sanitize.sanitizeOnShutdown boolean and pref()
  
  
  
  • use defaultPref
  
  

[earthlng]

another sticky?

Why would anyone use a mozilla.cfg and use pref() instead of lockPref()? Makes no sense to me.
I'm pretty sure it works with lockPref() because I believe there's also an enterprise policy that does that.

Assuming it doesn't work with lockPref(), can we mention this in 1.5 Lock Prefs instead of another sticky? Because that's where it belongs if that's indeed the case (but I doubt it)

[Thorin-Oakenpants]

Why would anyone use a mozilla.cfg and use pref() instead of lockPref() ... I'm pretty sure it works with lockPref()

I have no idea. And I also can't be F testing anything because I don't need to use a cfg file and don't have one set up. Maybe @intika can answer why he's using pref()

Lets leave it open for now, Intika has a list of some prefs to add.

[intika]

@earthlng i am not using pref() under mozilla.cfg this was just an internal note for me to debug...

Also there are 3 or 4 bugs about locked settings in the gui... i fixed one of them by directly patching firefox i will post back here once i publish that and probably fill a bug report (i don't have the time for that for the moment)... i know it's a different topic, but basically the bug is that the setting is not grayed even if its locked (the user think he activated a settings and in reality it does nothing because it's locked)

Back to the topic... (i did not test if the bug still persist in v64 but was the case in v63)

mozilla.cfg pref issues :

// MIGRATED : To defaulting section
// WARNING : Do not change this settings here or proxy settings will be locked
// lockPref("network.proxy.autoconfig_url.include_path", false); 

* use defaultPref

// Pref : Send DNS request through SOCKS when SOCKS proxying is in use
// https://trac.torproject.org/projects/tor/wiki/doc/TorifyHOWTO/WebBrowsers
// BUG : This lock proxy settings from the panel
// BUG-Fix : Fixed with defaulting section
// MIGRATED : To defaulting section
// WARNING : Do not change this settings here or proxy settings will be locked
//lockPref("network.proxy.socks_remote_dns", true);

* use defaultPref

// Pref : 0707 : disable (or setup) DNS-over-HTTPS (DoH) (FF60+)
// TRR = Trusted Recursive Resolver
// .mode: 0=off, 1=race, 2=TRR first, 3=TRR only, 4=race for stats, but always use native result
// [WARNING] DoH bypasses hosts and gives info to yet another party (e.g. Cloudflare)
// [1] https://www.ghacks.net/2018/04/02/configure-dns-over-https-in-firefox/
// [2] https://hacks.mozilla.org/2018/05/a-cartoon-intro-to-dns-over-https/ 
// BUG : This seem to disable socks_remote_dns ?! need to check with wireshark 
// If true, just settings urls to null should be enough to disable 
// Without impacting socks_remote_dns
lockPref("network.trr.mode", 0);
lockPref("network.trr.bootstrapAddress", "");
lockPref("network.trr.uri", "");

* Not fixed (the settings is enabled its not grayed)

// Pref : Manage certificates button
//lockPref("security.disable_button.openCertManager", false);
// Disabled because of a bug that disable the button no matter what is the value

* Not fixed ?

// Pref : Manage security devices button
//lockPref("security.disable_button.openDeviceManager", false);
// Disabled because of a bug that disable the button no matter what is the value

* Not fixed ?

// Pref : Disable Cookie Exception Button
// WARNING Bug !!! This lock the button whether its false or true  
//lockPref("pref.privacy.disable_button.cookie_exceptions", false);

* Not fixed ?

[Thorin-Oakenpants]

Thanks for the info @intika .. we'll decide where to stick this info (at some stage) - probably our lock pref wiki page, and then unsticky it and close it. But keep in contact man .. knowledge is power :kiss:

[intika]

there we go for the patch i was talking about... https://github.com/intika/Librefox-Firefox/blob/master/omni-patching/browser/omni.ja/chrome/browser/content/browser/preferences/in-content/privacy.js.patch i don't know if its useful here...

[earthlng]

there we go for the patch i was talking about...

what if I lock it to true? :)

[intika]

it act as if its not locked on the gui but technically its locked

[Thorin-Oakenpants]

actually, this is something I'm not going to bother with. Although it's interesting from an enterprise viewpoint (i.e settings not covered by Enterprise Policy, which is still adding more settings), it's just something else to maintain, and I'm sure Enterprise folks can deal with any weird pref behaviors themselves.