Implement "chrome.storage.managed"
Categories
(WebExtensions :: Storage, defect, P5)
Tracking
(firefox67 verified, firefox68 verified)
People
(Reporter: ido.y, Assigned: mkaply)
References
(Blocks 2 open bugs)
Details
(Keywords: dev-doc-complete, Whiteboard: [design-decision-approved][triaged])
Attachments
(3 files)
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
Updated•8 years ago
|
Comment 2•8 years ago
|
||
there's nothing in Fx that enables setting all to same back end configuration - Jeff are there plans?
Comment 3•8 years ago
|
||
(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.
Comment 4•8 years ago
|
||
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/
Updated•7 years ago
|
Updated•7 years ago
|
Updated•7 years ago
|
Comment 6•7 years ago
|
||
To be discussed at Dec. 13, 2016 WE triage meeting. Agenda: https://docs.google.com/document/d/1S1QrBK1hrulE7dlLiQzjMupHUUSwDYRYAOXiqtMHe-k/edit
Updated•7 years ago
|
Assignee | ||
Comment 8•7 years ago
|
||
This would be a blocker for distributions as well. Is there a reason this is still unconfirmed if it has been triaged/approved?
Comment 9•7 years ago
|
||
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 :)
Updated•7 years ago
|
Comment 11•7 years ago
|
||
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.
Comment 12•6 years ago
|
||
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?
Comment 13•6 years ago
|
||
(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)
Comment 14•6 years ago
|
||
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.
Updated•6 years ago
|
Updated•5 years ago
|
Comment 15•5 years ago
|
||
: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?
Assignee | ||
Comment 16•5 years ago
|
||
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.
Assignee | ||
Comment 17•5 years ago
|
||
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.
Assignee | ||
Updated•5 years ago
|
Assignee | ||
Comment 18•5 years ago
|
||
https://superuser.com/questions/1303910/translate-google-chromes-storage-from-policies-managed-json-to-firefox
Assignee | ||
Comment 19•5 years ago
|
||
I'm moving this to I plan to start work on this soon.
Assignee | ||
Comment 20•5 years ago
|
||
Assignee | ||
Comment 21•5 years ago
|
||
When this patch lands, this page:
https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/storage/managed
Needs to be updated.
Comment 22•5 years ago
|
||
Pushed by mozilla@kaply.com: https://hg.mozilla.org/integration/autoland/rev/1a0f3a7891f4 Add support for setting chrome.storage.managed via enterprise policy. r=Felipe,zombie,flod
Comment 23•5 years ago
|
||
bugherder |
Assignee | ||
Comment 24•5 years ago
|
||
Attached are files for testing this bug.
There is a policies.json that sets the value in policy.
There is a simple extension that can be loaded via about:debugging.
After loading, you can debug the extension and view the console and see that the value you set in policy is displayed in the console.
Comment 25•5 years ago
•
|
||
This issue is verified as fixed on Firefox 68.0a1(20190319095054) and Firefox 67.0b3(20190318154932) under Win 7 64-bit and Mac OS X 10.14.1.
Please see the attached screenshot.
Comment 26•4 years ago
|
||
This issue is tracked here: mdn/sprints #1430
Comment 27•4 years ago
|
||
Is the message here that this is a new way to allow managed installation of web extensions, or should it be discussed as the preferred way because it makes it easier to create cross-browser extensions? Is the existing Firefox managed storage method going away or is it going to remain as an alternative?
These probably seem like stupid questions, but I don't want to give the wrong message.
Assignee | ||
Comment 28•4 years ago
|
||
I would call it a new way. The API (chrome.storage.managed) is the same.
We didn't implement it originally via policy because we didn't have policy.
We have no plans to remove the JSON option.
Comment 29•4 years ago
|
||
Confirming the documentation requirements:
- new manifest key page for
storage
with the propertymanaged_schema
in line with https://developer.chrome.com/apps/manifest/storage - update to storage.managed to note that, on Firefox, the content of managed storage can be defined optionally by the
managed_schema
to provide compatibility with Chrome. (Firefox will continue to support arbitrary json in manage storage, without a schema).
Assignee | ||
Comment 30•4 years ago
|
||
We're actually not using the managed_schema concept at all. For us, it's just a matter of doing the right thing in a policies.json file or GPO.
you can see an example here:
https://github.com/mozilla/legacy-browser-support/blob/master/README.md
Comment 31•4 years ago
|
||
A new page has been added to MDN to describe the storage manifest key, with compatibility data pending in PR 5575. Please let me know if any further changes are needed.
Updated•1 year ago
|
Description
•