Re: [Mozilla Enterprise] Mozilla To Stop Supporting Sideloaded Extensions In Firefox

[YUKI Hiroshi]

Hello,

> However, what policy settings do I need to have an arbitrary extension
> enabled by default for all users?
>
> I've put the extensions in distribution/extensions - but they don't
> appear in the extensions list when running Firefox

XPI packages placed under distribution/extensions are installed only on
the initial startup with a new profile. In other words, it is
unavailable to install extra more addons after you start using of Firefox.

Instead you need to list XPI files on the policy: "Extensions" =>
"Install". Addons listed there are installed on the next startup even if
there is any existing profile.

https://github.com/mozilla/policy-templates#extensions

> Also, I don't want these extensions to be installed in a user's profile
> - just loaded from the install tree

Sadly it looks impossible anymore on the new way, with official Firefox
builds.



On 2019/11/02 2:48, James Pearson wrote:
> As I just happen to setting up ESR 68 (on Linux) with a couple of third 
> party extensions that I want to be loaded by default - this thread is 
> rather timely ...
> 
> However, what policy settings do I need to have an arbitrary extension 
> enabled by default for all users?
> 
> I've put the extensions in distribution/extensions - but they don't 
> appear in the extensions list when running Firefox
> 
> Also, I don't want these extensions to be installed in a user's profile 
> - just loaded from the install tree
> 
> Thanks
> 
> James Pearson
> 
> 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
>>
>> On Fri, Nov 1, 2019 at 8:47 AM Luca Olivetti 
>> mailto:l...@wetron.es>> wrote:
>> El 1/11/19 a les 14:26, Mike Kaply ha escrit:
>>> This method was deprecated by Chrome years ago and we provide new and
>>> better methods via policy.
>>
>> If I wanted to deploy chrome I would be deploying chrome. Maybe it would
>> spare me a lot of headaches.
>>
>>>
>>> As it stands today, any extension installed by these mechanisms gets
>>> disabled anyway.
>>>
>>> And we've actually made deployment easier with each release.
>>
>> Not really if you remove facilities that have been working since day one
>> (I've been deploying mozilla since it was a monolithic application, and
>> I preferred it that way, just one application to deploy instead of two
>> that have a lot of overlap).
>> Maybe I wasn't using a "sanctioned" method to to the deployment, but
>> that was just because there was *no* method to do it when I started
>> doing it, hence, with each new release, I had to jump through hoops to
>> keep it working.
>> Anyway, the "new", "improved" methods are less straightforward than the
>> old fashioned ones.
>>
>> Bye
>>
>> --
>> Luca Olivetti
>> Wetron Automation Technology http://www.wetron.es/
>> Tel. +34 93 5883004 (Ext.3010)  Fax +34 93 5883007
>> ___
>> 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"
> 

-- 
結城 洋志 
E-mail: y...@clear-code.com
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"

Re: [Mozilla Enterprise] Mozilla To Stop Supporting Sideloaded Extensions In Firefox

[Luca Olivetti]

El 1/11/19 a les 16:59, Mike Kaply ha escrit:

You will still be able to put extensions into distribution/extensions 
because they simply get installed into Firefox as normal extensions.


I still prefer browser/extensions, this way users cannot mess up with 
the extensions I preinstall.
I don't really like the fact that if I put it in distribution/extensions 
it will be treated like a normal extensions (i.e. copied in the user's 
profile).
Anyway, will it work with languagepacks and dictionaries? That's what 
I'm using the current approach for (and it worked up until now, after 
some head scratching when the disabled scopes was introduced).


Bye
--
Luca Olivetti
Wetron Automation Technology http://www.wetron.es/
Tel. +34 93 5883004 (Ext.3010)  Fax +34 93 5883007
___
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"

Re: [Mozilla Enterprise] Mozilla To Stop Supporting Sideloaded Extensions In Firefox

[James Pearson]

As I just happen to setting up ESR 68 (on Linux) with a couple of third 
party extensions that I want to be loaded by default - this thread is 
rather timely ...


However, what policy settings do I need to have an arbitrary extension 
enabled by default for all users?


I've put the extensions in distribution/extensions - but they don't 
appear in the extensions list when running Firefox


Also, I don't want these extensions to be installed in a user's profile 
- just loaded from the install tree


Thanks

James Pearson

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

On Fri, Nov 1, 2019 at 8:47 AM Luca Olivetti 
mailto:l...@wetron.es>> wrote:
El 1/11/19 a les 14:26, Mike Kaply ha escrit:

This method was deprecated by Chrome years ago and we provide new and
better methods via policy.


If I wanted to deploy chrome I would be deploying chrome. Maybe it would
spare me a lot of headaches.



As it stands today, any extension installed by these mechanisms gets
disabled anyway.

And we've actually made deployment easier with each release.


Not really if you remove facilities that have been working since day one
(I've been deploying mozilla since it was a monolithic application, and
I preferred it that way, just one application to deploy instead of two
that have a lot of overlap).
Maybe I wasn't using a "sanctioned" method to to the deployment, but
that was just because there was *no* method to do it when I started
doing it, hence, with each new release, I had to jump through hoops to
keep it working.
Anyway, the "new", "improved" methods are less straightforward than the
old fashioned ones.

Bye

--
Luca Olivetti
Wetron Automation Technology http://www.wetron.es/
Tel. +34 93 5883004 (Ext.3010)  Fax +34 93 5883007
___
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"

Re: [Mozilla Enterprise] Mozilla To Stop Supporting Sideloaded Extensions In Firefox

[SHIMODA Hiroshi]

Hello,

> To clarify, loading them directly into /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 /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  > wrote:
> 
> On Fri, Nov 1, 2019 at 10:39 AM Stephen Dowdy  > 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' 

Re: [Mozilla Enterprise] Mozilla To Stop Supporting Sideloaded Extensions In Firefox

[Kris Lou via Enterprise]

>
> 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 /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  wrote:

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

Re: [Mozilla Enterprise] Mozilla To Stop Supporting Sideloaded Extensions In Firefox

[Mike Kaply]

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

Re: [Mozilla Enterprise] enabledScopes in GPO

[Fjoerfoks]

Awesome, thanks!
Wim

Op vr 1 nov. 2019 16:49 schreef Mike Kaply :

> Our new ExtensionSettings policy is even better for this :).
>
> https://github.com/mozilla/policy-templates#extensionsettings
>
> Fine grained control where you need it, but global control in other cases.
>
> Mike
>
> On Fri, Nov 1, 2019 at 10:33 AM Fjoerfoks  wrote:
>
>> Hi,
>>
>> I like the option to be able to lock certain addons as an admin, but also
>> give users some control over less important preinstalled addons, like
>> disabling yes/no, uninstall yes/no, etc. on a per addon basis.
>> enableScopes is/was perfect for this.
>>
>> Wim
>>
>> Op do 31 okt. 2019 22:42 schreef Mike Kaply :
>>
>>> I haven't made the scopes preferences available via GPO because my hope
>>> was that the new methods for installing and locking extensions would remove
>>> the need for them.
>>>
>>> Are you mainly looking to force enable third party extensions?
>>>
>>> Mike
>>>
>>> On Thu, Oct 31, 2019 at 4:32 PM Fjoerfoks 
>>> wrote:
>>>
 Hi Mike,

 Short question:
 is it still possible to use the pref extensions.enabledScopes somewhere
 when using GPO,
 or is there another method for GPO?

 Kind regards,
 Wim
 ___
 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"

Re: [Mozilla Enterprise] Mozilla To Stop Supporting Sideloaded Extensions In Firefox

[Fjoerfoks]

We also struggled with the switch from cck to GPO, but 2 weeks ago we
succesfully deployed Firefox 68. The GPO does what we need although it
feels cck gave more control, since you could add your own preferences,
which does not seem possible with gpo.
During testfase we encountered a problem with saving passwords, so we
contacted Mike and he fixed it for 68.0.2. Well done I'd say!
Maybe it is not perfect yet, but gpo also gives you flexibility for
usermanagement and no need to rebuild cck again and again.
New enhancements? Mike is here to help.

Wim

Op vr 1 nov. 2019 16:39 schreef Stephen Dowdy :

> 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?
>
> 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? ?)
>
> 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 really appreciate you *personally* being so engaged and responsive,
> however. So
> a big Thank You for that.
>
> --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"

Re: [Mozilla Enterprise] enabledScopes in GPO

[Mike Kaply]

Our new ExtensionSettings policy is even better for this :).

https://github.com/mozilla/policy-templates#extensionsettings

Fine grained control where you need it, but global control in other cases.

Mike

On Fri, Nov 1, 2019 at 10:33 AM Fjoerfoks  wrote:

> Hi,
>
> I like the option to be able to lock certain addons as an admin, but also
> give users some control over less important preinstalled addons, like
> disabling yes/no, uninstall yes/no, etc. on a per addon basis.
> enableScopes is/was perfect for this.
>
> Wim
>
> Op do 31 okt. 2019 22:42 schreef Mike Kaply :
>
>> I haven't made the scopes preferences available via GPO because my hope
>> was that the new methods for installing and locking extensions would remove
>> the need for them.
>>
>> Are you mainly looking to force enable third party extensions?
>>
>> Mike
>>
>> On Thu, Oct 31, 2019 at 4:32 PM Fjoerfoks 
>> wrote:
>>
>>> Hi Mike,
>>>
>>> Short question:
>>> is it still possible to use the pref extensions.enabledScopes somewhere
>>> when using GPO,
>>> or is there another method for GPO?
>>>
>>> Kind regards,
>>> Wim
>>> ___
>>> 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"

Re: [Mozilla Enterprise] Mozilla To Stop Supporting Sideloaded Extensions In Firefox

[Stephen Dowdy]

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?

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? ?)

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 really appreciate you *personally* being so engaged and responsive, however. 
So
a big Thank You for that.

--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"

Re: [Mozilla Enterprise] enabledScopes in GPO

[Fjoerfoks]

Hi,

I like the option to be able to lock certain addons as an admin, but also
give users some control over less important preinstalled addons, like
disabling yes/no, uninstall yes/no, etc. on a per addon basis.
enableScopes is/was perfect for this.

Wim

Op do 31 okt. 2019 22:42 schreef Mike Kaply :

> I haven't made the scopes preferences available via GPO because my hope
> was that the new methods for installing and locking extensions would remove
> the need for them.
>
> Are you mainly looking to force enable third party extensions?
>
> Mike
>
> On Thu, Oct 31, 2019 at 4:32 PM Fjoerfoks  wrote:
>
>> Hi Mike,
>>
>> Short question:
>> is it still possible to use the pref extensions.enabledScopes somewhere
>> when using GPO,
>> or is there another method for GPO?
>>
>> Kind regards,
>> Wim
>> ___
>> 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"

Re: [Mozilla Enterprise] Mozilla To Stop Supporting Sideloaded Extensions In Firefox

[Mike Kaply]

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

On Fri, Nov 1, 2019 at 8:47 AM Luca Olivetti  wrote:

> El 1/11/19 a les 14:26, Mike Kaply ha escrit:
> > This method was deprecated by Chrome years ago and we provide new and
> > better methods via policy.
>
> If I wanted to deploy chrome I would be deploying chrome. Maybe it would
> spare me a lot of headaches.
>
> >
> > As it stands today, any extension installed by these mechanisms gets
> > disabled anyway.
> >
> > And we've actually made deployment easier with each release.
>
> Not really if you remove facilities that have been working since day one
> (I've been deploying mozilla since it was a monolithic application, and
> I preferred it that way, just one application to deploy instead of two
> that have a lot of overlap).
> Maybe I wasn't using a "sanctioned" method to to the deployment, but
> that was just because there was *no* method to do it when I started
> doing it, hence, with each new release, I had to jump through hoops to
> keep it working.
> Anyway, the "new", "improved" methods are less straightforward than the
> old fashioned ones.
>
> Bye
>
> --
> Luca Olivetti
> Wetron Automation Technology http://www.wetron.es/
> Tel. +34 93 5883004 (Ext.3010)  Fax +34 93 5883007
> ___
> 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"

Re: [Mozilla Enterprise] Mozilla To Stop Supporting Sideloaded Extensions In Firefox

[Luca Olivetti]

El 1/11/19 a les 14:26, Mike Kaply ha escrit:
This method was deprecated by Chrome years ago and we provide new and 
better methods via policy.


If I wanted to deploy chrome I would be deploying chrome. Maybe it would 
spare me a lot of headaches.




As it stands today, any extension installed by these mechanisms gets 
disabled anyway.


And we've actually made deployment easier with each release.


Not really if you remove facilities that have been working since day one 
(I've been deploying mozilla since it was a monolithic application, and 
I preferred it that way, just one application to deploy instead of two 
that have a lot of overlap).
Maybe I wasn't using a "sanctioned" method to to the deployment, but 
that was just because there was *no* method to do it when I started 
doing it, hence, with each new release, I had to jump through hoops to 
keep it working.
Anyway, the "new", "improved" methods are less straightforward than the 
old fashioned ones.


Bye

--
Luca Olivetti
Wetron Automation Technology http://www.wetron.es/
Tel. +34 93 5883004 (Ext.3010)  Fax +34 93 5883007
___
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"

Re: [Mozilla Enterprise] Mozilla To Stop Supporting Sideloaded Extensions In Firefox

[Mike Kaply]

This method was deprecated by Chrome years ago and we provide new and
better methods via policy.

As it stands today, any extension installed by these mechanisms gets
disabled anyway.

And we've actually made deployment easier with each release.

Mike



On Fri, Nov 1, 2019 at 8:18 AM Luca Olivetti  wrote:

>
> https://news.slashdot.org/story/19/11/01/0331216/mozilla-to-stop-supporting-sideloaded-extensions-in-firefox
>
>
> Really?
> If so, thank you (not!) for making deployment more difficult with each
> release.
>
> Bye
> --
> Luca Olivetti
> Wetron Automation Technology http://www.wetron.es/
> Tel. +34 93 5883004 (Ext.3010)  Fax +34 93 5883007
> ___
> 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"

[Mozilla Enterprise] Mozilla To Stop Supporting Sideloaded Extensions In Firefox

[Luca Olivetti]

https://news.slashdot.org/story/19/11/01/0331216/mozilla-to-stop-supporting-sideloaded-extensions-in-firefox


Really?
If so, thank you (not!) for making deployment more difficult with each 
release.


Bye
--
Luca Olivetti
Wetron Automation Technology http://www.wetron.es/
Tel. +34 93 5883004 (Ext.3010)  Fax +34 93 5883007
___
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"

Re: [Mozilla Enterprise] ESR 52.x to 68.2.0 lost bookmarks

[Mike Kaply]

Can you see if the user has a directory called bookmarkbackups in their
profile? If so, these files can be imported via the bookmarks manager.

The problem is that places.sqlite changed between 52 and 68, so typically
we take people through what we call watershed releases so things get
migrated.

There might also be a file called places.sqlite.corrupt that can be used to
recover things. If that's there, let me know and we can figure things out.

Mike Kaply

On Fri, Nov 1, 2019 at 7:14 AM James M. Pulver  wrote:

> We had a user who had the management software stop working properly on
> his PC and so didn't get updated along the way to 60.0 and point
> releases etc. I fixed that yesterday, and so Firefox was updated from 32
> bit 52.x to 64 bit 68.2.0. This is on Windows 10 1607 LTSB.
>
> Afterwards, it looked like the same profile was being used as before -
> we checked profile.ini and it was pointing to the one profile the user
> had, which was the default profile. However, no bookmarks were found.
> There was a bookmarks.html that we imported, but the user says this is a
> very old set of bookmarks. I'm at a loss - is there anything we can do
> with the profile to get the bookmarks 52.x were using?
>
> Note, we haven't seen this with most upgrades between any versions of
> Firefox before. If it gets the profile, everything is there. But that
> doesn't seem to be the case here.
> --
> James Pulver
> CLASSE Computer Group
> Cornell University
> ___
> 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"

[Mozilla Enterprise] ESR 52.x to 68.2.0 lost bookmarks

[James M. Pulver]

We had a user who had the management software stop working properly on 
his PC and so didn't get updated along the way to 60.0 and point 
releases etc. I fixed that yesterday, and so Firefox was updated from 32 
bit 52.x to 64 bit 68.2.0. This is on Windows 10 1607 LTSB.

Afterwards, it looked like the same profile was being used as before - 
we checked profile.ini and it was pointing to the one profile the user 
had, which was the default profile. However, no bookmarks were found. 
There was a bookmarks.html that we imported, but the user says this is a 
very old set of bookmarks. I'm at a loss - is there anything we can do 
with the profile to get the bookmarks 52.x were using?

Note, we haven't seen this with most upgrades between any versions of 
Firefox before. If it gets the profile, everything is there. But that 
doesn't seem to be the case here.
-- 
James Pulver
CLASSE Computer Group
Cornell University
___
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"

Re: [Mozilla Enterprise] Issues with multiprocessing

[Samuel Ambaye]

Hi,

Yes. We also had to temporarily set the value to false to avoid a few issues 
(SSO, capability.policy.policynames, start up errors).
We are removing usage of the FF setting capability.policy.policynames so that 
we can restore support for multiprocessing and avoid SSO issues.

Best,
Samuel


From: Enterprise  on behalf of Tiago Marques 
Delboni 
Date: Thursday, 31 October 2019 at 17:24
To: "enterprise@mozilla.org" 
Subject: [Mozilla Enterprise] Issues with multiprocessing

Hi!

Since ESR 52.x and now with ESR 60.x, both Windows/64bits, we are having issues 
with multiprocessing enabled - FF hangs or some funcionalities of 
sites/applications doesn't work as expected. We observed this behavior on 
OpenCMS based websites, Alfresco and a few others.

To fix this, we had to set "browser.tabs.remote.autostart=false" in our 
organization.

Anyone else having this kind os issues?
--

Tiago Marques Delboni

___
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"