Closed Bug 1230802 Opened 5 years ago Closed 2 years ago
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.73 Safari/537.36
https://developer.chrome.com/extensions/manifest/storage the managed storage is allow to externally config extension for massive installation (e.g. by using GPO) in XUL we had the option to do that by using the "nsIWindowsRegKey" in webExtension that will be the best alternative for doing the configuration
there's nothing in Fx that enables setting all to same back end configuration - Jeff are there plans?
Priority: -- → P3
(In reply to :shell escalante from comment #2) > there's nothing in Fx that enables setting all to same back end > configuration - Jeff are there plans? We have some initial discussions about reforming ESR to be more useful to enterprises. I don't think this feature is on the list yet, and I think I would prefer any Firefox work be driven from Web Extensions requirements. The initial ESR work will almost certainly be mainly installer work.
This is quite required for my cases. For my customer companies I provide some addons for their common requirements, and distribute it with an MCD configuration file to change their behaviors for each customer. For example: https://addons.mozilla.org/firefox/addon/force-addon-status/ https://addons.mozilla.org/firefox/addon/permissions-auto-registerer/ https://addons.mozilla.org/firefox/addon/ui-text-overrider/
is there anything new about this?
To be discussed at Dec. 13, 2016 WE triage meeting. Agenda: https://docs.google.com/document/d/1S1QrBK1hrulE7dlLiQzjMupHUUSwDYRYAOXiqtMHe-k/edit
Priority: P3 → P5
Whiteboard: [design-decision-needed][triaged] → [design-decision-approved][triaged]
This would be a blocker for distributions as well. Is there a reason this is still unconfirmed if it has been triaged/approved?
Because we rarely bother flipping the status from unconfirmed, its always seemed like a pointless make work step in Bugzilla to me. I've flipped it to new :)
Status: UNCONFIRMED → NEW
Ever confirmed: true
Mozilla Bug 1215062 decided to disallow to access about:config preferences. So, It is impossible to convert Configuration Mania to a WebExtension. Not only this extensions such as QuickJ , GuI config , TMP etc cannot be ported as well. Since these are top extensions and have at some point been featured on mozilla, Mozilla should probably allow some leeway and implement the necessary apis or face user backlash.
With the conversion of extensions to WebExtensions, we are unable to deploy our settings to various deployed extensions, such as uBlock Origin. If this is not the proper way for an extension to allow settings to be managed by an administrator, then what is?
(In reply to Austin from comment #12) > With the conversion of extensions to WebExtensions, we are unable to deploy > our settings to various deployed extensions, such as uBlock Origin. If this > is not the proper way for an extension to allow settings to be managed by an > administrator, then what is? As a workaround for enterprise (business) use, I've developed a native messaging host to read configs from MCD configuration files. Until chrome.storage.managed is landed, we need to do something like this by self. https://github.com/clear-code/mcd-go (library for Golang) https://github.com/clear-code/ieview-we (example application)
Please note that bug 1386427 contains a basic implementation of chrome.storage.managed and I've successfully used this to configure extensions. A test of uBlock Origin would be appreciated.
:mkaply - with support for chrome.storage.managed in release 57, and support for Windows GPO in release 60, is this bug still applicable? Or can it be closed?
This bug is still applicable. I think we need to add support to GPO for settings chrome.storage.managed values? I honestly don't know how the mapping works. I'll see if this is something our intern wants to take on.
Right now the managed storage only looks in Native Manifests: https://searchfox.org/mozilla-central/source/toolkit/components/extensions/parent/ext-storage.js#29 We would need to add code to support a new type of manifest maybe? And then provide policy code to set it.
I'm moving this to I plan to start work on this soon.
Status: NEW → ASSIGNED
Pushed by firstname.lastname@example.org: https://hg.mozilla.org/integration/autoland/rev/1a0f3a7891f4 Add support for setting chrome.storage.managed via enterprise policy. r=Felipe,zombie,flod
You need to log in before you can comment on or make changes to this bug.