For enterprise use, the system administrator hopes to manage site permissions by himself and don't want users to modify default permissions. Currently we can do it by userChrome.css or something to hide those UIs, but after XUL is ended we need something to alter it. This is related to the bug 1268422, similar to the bug 1268407.
3 years ago
I think the API will appear like: chrome.contentSettings.lock() chrome.contentSettings.unlock() Under the namespace https://developer.chrome.com/extensions/contentSettings
To be discussed at Jan 10 WebExtensions triage meeting. Agenda: https://docs.google.com/document/d/18K97o1juaHSeYEkes1iMz8AayjuVkUuIK844ErGaa-c/edit
Currently I think this should be discussed as a part of MCD/mission control desktop feature for enterprise environment.
Assignee: nobody → mozilla
Component: WebExtensions: Untriaged → AutoConfig (Mission Control Desktop)
Product: Toolkit → Core
Whiteboard: [design-decision-needed]triaged → triaged
Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.
Status: NEW → RESOLVED
Last Resolved: a year ago
Resolution: --- → INACTIVE
Done as part of policy.
Resolution: INACTIVE → FIXED
This looks not fixed yet, for some permissions listed at Ctrl-I (Page Info) => Permissions: * Access Your Location * Automatically Play Media with Sound * Load Images * Override Keyboard Shortcuts * Receive Notifications * Share the Screen * Store Data in Persistent Storage * Switch to this Tab * Use the Camera * Use the Microphone Should I file new bugs for each permission?
We're doing a few of these (location, camera, microphone, notifications) and I see no reason to do the rest. Our goal is not to add policies for everything in the browser, it's to add policies for things that enterprises need to customize.
You need to log in before you can comment on or make changes to this bug.