Closed Bug 1230802 Opened 9 years ago Closed 5 years ago

Implement "chrome.storage.managed"

Categories

(WebExtensions :: Storage, defect, P5)

Product:
WebExtensions
Component:
Storage
Version:
45 Branch
Type:
defect

Tracking

(firefox67 verified, firefox68 verified)

Status:
VERIFIED FIXED
Milestone:
mozilla67
Tracking Flags:
Tracking Status
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)

Bug 1230802 - Add support for setting chrome.storage.managed via enterprise policy.
47 bytes, text/x-phabricator-request
Details | Review
Test files for this bug
850 bytes, application/zip
Details
Bug1230802.png
171.09 KB, image/png
Details 
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
Component: Add-ons Manager → WebExtensions
there's nothing in Fx that enables setting all to same back end configuration - Jeff are there plans?
Flags: needinfo?(jgriffiths)
Priority: -- → P3
Whiteboard: triaged
(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.
Flags: needinfo?(jgriffiths)
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?
Blocks: 1279446
Whiteboard: triaged → [design-decision-needed][triaged]
Blocks: 1291627
Component: WebExtensions: Untriaged → WebExtensions: General
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?
Blocks: 1333828
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?
See Also: → 1386427
(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)
Depends on: 1386427
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.
No longer blocks: 1333828
Component: WebExtensions: General → WebExtensions: Storage
Product: Toolkit → WebExtensions
: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?
Flags: needinfo?(mozilla)
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.
Flags: needinfo?(mozilla)
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: nobody → mozilla
I'm moving this to I plan to start work on this soon.
Status: NEW → ASSIGNED
Depends on: 1530465

When this patch lands, this page:

https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/storage/managed

Needs to be updated.

Keywords: dev-doc-needed
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

https://hg.mozilla.org/mozilla-central/rev/1a0f3a7891f4

Status: ASSIGNED → RESOLVED
Closed: 5 years ago
status-firefox67: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla67

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.

Attached image Bug1230802.png —

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.

Status: RESOLVED → VERIFIED
status-firefox67: fixed → verified
status-firefox68: --- → verified

This issue is tracked here: mdn/sprints #1430

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.

Flags: needinfo?(mozilla)

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.

Flags: needinfo?(mozilla)

Confirming the documentation requirements:

  • new manifest key page for storage with the property managed_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).
Flags: needinfo?(mozilla)

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

Flags: needinfo?(mozilla)

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.

Flags: needinfo?(mozilla)

This looks good to me.

Flags: needinfo?(mozilla)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: