>
> 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> wrote:
> On Fri, Nov 1, 2019 at 10:39 AM Stephen Dowdy <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
>> 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"
>>
> _______________________________________________
> 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"
>
_______________________________________________
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"
