I have tried to follow the thread, but don’t have a history of working with extensions.
Is there a web page that details the “best practice” for installing extensions, dictionaries, language packs, etc? Should we be following http://kb.mozillazine.org/Installing_extensions#Global_installation to install extensions as of today? From: Enterprise <enterprise-boun...@mozilla.org> On Behalf Of Mike Kaply Sent: Friday, November 01, 2019 10:59 AM To: Stephen Dowdy <sdo...@ucar.edu> Cc: Mozilla.org <enterprise@mozilla.org> Subject: Re: [Mozilla Enterprise] Mozilla To Stop Supporting Sideloaded Extensions In Firefox ________________________________ CAUTION: This email originated from outside TDHCA's email system. DO NOT open attachments or click links unless you expect them from the sender and know the content is safe. On Fri, Nov 1, 2019 at 10:39 AM Stephen Dowdy <sdo...@ucar.edu<mailto:sdo...@ucar.edu>> wrote: On 11/1/19 9:21 AM, Mike Kaply wrote: > You can deploy extensions as a part of Firefox by putting them in the > distribution/extensions directory and then locking them via policy. > > This has always been a better way then putting them in system directories > where they might not get updated properly. Mike, i composed the below before this current response from you came out, but it sounds like, firefox will STILL support APPDIR extensions deployment, but not user PROFDIR deployments (this changes the extensions.*scopes preferences functionality i would assume.) So, is there a guide on how the old-school stuff should now be done with Policies? The thing that is going away is the concept of sideloading where you put extensions in a central location and they get loaded into Firefox and the user can't remove them (they can only disable them). You will still be able to put extensions into distribution/extensions because they simply get installed into Firefox as normal extensions. To be blunt: I really still am puzzled by the entire Policies thing, as the autoconfig stuff (to me) seems to be more useful/functional and stuff like locking/defaulting Policies was bolted on after it was discovered they didn't offer the same functionality of defaultPref() lockPref() etc... (i.e. it seems to be playing catchup rather than offering me something of value. Security? Maintainability? ?) autoconfig for setting/locking preferences continues to be available and will always be available. The only thing being locked down in autoconfig on release (not ESR) is the fact that you could use autoconfig to bypass Firefox security and access everything in Firefox (this is how the CCK2 works). The reason I haven't made every preference available in policy is: 1. There are way too many preferences. 2. Folks change a ton of preferences without having any idea what they do. I still ponder this every so often, but then I see some of the preferences people change and bang my head against a wall. If there are prefs you need, please let me know. There seems to be a lot of chaos for what i don't see as a benefit. It appears a lot of us are getting frustrated over having to bang our heads on just maintaining status-quo operations, and if there is some well-defined reasoning, getting some better P.R. out on that might help. (for me, the camel that broke my back was removing 'user.js' functionality for one freakin' stat() call of "performance". this is just insane) (i have been cursing Mozilla for the past year over these types of things, though) I don't think user.js has been removed yet, has it? user.js isn't just about performance. We've seen malware using user.js to do some serious hijacking of Firefox. A lot of what we do is in the interest of protecting users. Folks don't see all the terrible ways these various mechanisms are used to ruin user experience. By moving to policies, we can have a standard way to do things and stop the hodgepodge we had before (which I largely created). I really appreciate you *personally* being so engaged and responsive, however. So a big Thank You for that. Thanks Mike --stephen ----- (previously composed message) ----- This is totally unclear to me what's happening (from the blog post). Does this apply to the APPDIR 'extensions' folders? (it seems clear it applies to PROFDIR extensions folders). If so, PLEASE tell me how i am supposed to support an enterprise install that has preloaded extensions in a SYSADMIN controlled space? (at least for linux) I don't presently do this for *firefox*, but i do for 'thunderbird' (yeah, the announcement doesn't say tbird, but i presume it'll hit there sometime) I load 'mailredirect' because thunderbird fails to offer that function. (into /usr/local/thunderbird/extensions/{..}.xpi) and presently, until 'enigmail' is replaced by builtin PGP functionality, i add that, too. Replacing a programmatic install with site-selected addons with a request for interactive action: "Hey, user, please go to A.M.O. and download this addon after you start the app the first time", is totally untenable. thanks, --stephen _______________________________________________ Enterprise mailing list Enterprise@mozilla.org<mailto:Enterprise@mozilla.org> https://mail.mozilla.org/listinfo/enterprise<https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.mozilla.org_listinfo_enterprise&d=DwMFaQ&c=2WwxlqHD_9GeHFEUsOHZXg&r=a0pF-r4VjZCyzB4zxbRDcONPyw-KRRoDiBPd4lDRky8&m=vLC5tnWjd_KzOeR8Hn8ulc5BttIHEPC6_5BB650d-oo&s=-kpWC32mIC4qdHrk6TDGCbydPEcS9hnfOCs5gKm_4k0&e=> To unsubscribe from this list, please visit https://mail.mozilla.org/listinfo/enterprise<https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.mozilla.org_listinfo_enterprise&d=DwMFaQ&c=2WwxlqHD_9GeHFEUsOHZXg&r=a0pF-r4VjZCyzB4zxbRDcONPyw-KRRoDiBPd4lDRky8&m=vLC5tnWjd_KzOeR8Hn8ulc5BttIHEPC6_5BB650d-oo&s=-kpWC32mIC4qdHrk6TDGCbydPEcS9hnfOCs5gKm_4k0&e=> or send an email to enterprise-requ...@mozilla.org<mailto:enterprise-requ...@mozilla.org> with a subject of "unsubscribe"
_______________________________________________ Enterprise mailing list Enterprise@mozilla.org https://mail.mozilla.org/listinfo/enterprise To unsubscribe from this list, please visit https://mail.mozilla.org/listinfo/enterprise or send an email to enterprise-requ...@mozilla.org with a subject of "unsubscribe"
