Hello, > To clarify, loading them directly into <FF/TB install>/extensions is > going away, and the "as normal extensions" deployment means loading into > distribution/extensions, where they are copied into and then run from > the user profile?
If I understand the blog post correctly, it is "yes". As the result version lock and controlling of update timing about addons installed in this way (or via GPO) become virtually impossible. Sideloaded addons can be updated by simple replacing of installed files. On the other hand, updating of addons installed into user profiles can be done only via the auto update. (It is painful for the system administrator that replacing all files placed under each user profile.) Otherwise, I think we need to distribute addon packages with custom update URL for each case. If the addon is a public addon, you look to need to repack it with custom ID and custom update URL. https://extensionworkshop.com/documentation/manage/updating-your-extension/ I'm not a system administrator on a company but a support vendor for enterprise customers and I provided different versions for each ESR68 customer as sideloaded addons. Thus I think I must provide repacked XPIs for each customer on the next ESR... On 2019/11/02 1:04, Kris Lou via Enterprise wrote: > 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 clarify, loading them directly into <FF/TB install>/extensions is > going away, and the "as normal extensions" deployment means loading into > distribution/extensions, where they are copied into and then run from > the user profile? > > > > On Fri, Nov 1, 2019 at 8:59 AM Mike Kaply <mka...@mozilla.com > <mailto:mka...@mozilla.com>> wrote: > > 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 > > To unsubscribe from this list, please visit > https://mail.mozilla.org/listinfo/enterprise 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 <mailto: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 > <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" > -- 下田 洋志 <SHIMODA Hiroshi> E-mail: shim...@clear-code.com 株式会社クリアコード 〒113-0033 東京都文京区本郷3-27-12 本郷デントビル2階 TEL : 03-6231-7270 FAX : 03-6231-7271 WWW : http://www.clear-code.com/ _______________________________________________ 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"
