1282982 - Implement chrome.management.setEnabled

Status: ASSIGNED

(WebExtensions :: General, enhancement, P5)

Description

[Matthew Wein [:mattw]]

Chrome documentation: https://developer.chrome.com/extensions/management#method-setEnabled

Comment 1

[Bob Silverberg [:bsilverberg]]

Some examples of usage from "popular chrome extensions":

- Video Downloader Pro is using it to enable a particular extension (Google Cast), after asking the user's permission.

- Adblock has a feature that allows a user to disable all other extensions, for which it uses setEnabled.

Comment 2

[Bob Silverberg [:bsilverberg]]

We are going to hold off on implementing this API method until some compelling use cases are presented by the developer community.

Comment 3

[vincent]

Here is an example of use case for wich I need this API working also to enable / disable a WebExtension.

I have a WebExtension (call it A) with allow users to enable / disable several parameters related to our company user experience, including the use of our a newtab page.
As in WebExtension, newTab feature is provided by key chrome_url_overrides in manifest, I can't enable or disable it on the fly from my Extension. A solution is to have a dedicated webExtension (call it B) who only provide this newTab feature, and we propose to our users to install it only if they want to enable this feature. 

If a user change his mind, and want to disable it, we would like to have a simple way to disable it.
To allow users to enable or disable this new tab page in one click from extension A, I need to enable or disable extension B. That means calling setEnable extension B from A.

Comment 4

[ottodevs]

(In reply to Bob Silverberg [:bsilverberg] from comment #2)
> We are going to hold off on implementing this API method until some
> compelling use cases are presented by the developer community.

2 years later and setEnabled still only works for themes...

Here is one of the best use cases:

An extension manager, where the user can manage selective activation of add-ons from a handful icon on the add-ons bar, primarly for security purposes, like the metamask extension add-ons or other cryptocurrencies/financial/sensitive related add-ons that expose their APIs to other tabs with potential harmful effects, this kind of "add-on manager" would also be useful for performance purposes, where the user can define profiles or sets of enabled/disabled add-ons to quickly change their state.

The Chrome web store has plenty of this extension managers, being very popular some of them, like Extensity or Extension Manager.

Comment 5

[Firefox Bug Husbandry Bot]

Bulk move of bugs per https://bugzilla.mozilla.org/show_bug.cgi?id=1483958

Comment 6

[Chris Royer]

Another example it would help someone develop a better add-on manager since Bug 1499500 was caused in version 59, things like https://ainoob.com/en/project/nooboss could be developed for Firefox.

Comment 7

[Trishul]

I really need this API to support extensions to complete my addon (I have it working seamlessly in chrome)

Firefox - https://addons.mozilla.org/en-US/firefox/addon/permission-inspector/
Chrome - https://chrome.google.com/webstore/detail/permission-inspector/ahfoecogpaccmnaiilgchbfemajmkcdi

Comment 8

[anon]

After the changes to the add-on manager in Firefox 68, it would be nice if this feature could be reconsidered. The add-on manager is fine for users with only a few extensions. However, for users that have many extensions installed, the add-on manager is inefficient. Here are some issues with the current about:addons page:

• Interacting with an extension now requires multiple clicks.
• Not many extensions are displayed on the screen and a lot of scrolling may be required to find one.
• Enabled and disabled extensions look the same. When scrolling fast, it's easy to miss when the other section begins.
• If a user wishes to temporarily enable/disable multiple extensions that are displayed on the screen, the extensions are immediately sorted into the opposite category, requiring more scrolling to access them again.

With the capability to enable/disable an extension, extension managers in Firefox could do the following:

• Compactly display the extensions in either a sidebar, toolbar button popup, or customized add-on page.
• Display a find box that could search through extension names as well as descriptions.
• Sort the extensions by enabled/disabled or alphabetically with favorite extensions optionally on top of the list.
• Enable or disable extensions with a single click.
• Go to an extensions options page or home page with a single click.
• Switch between groups of extensions with profiles.
• Disable all extensions and then restore the same extensions back to enabled with a toggle switch.
• Use tabs or folders to place extensions into categories like enabled, disabled, favorites, recent, etc...

10 of the top Chrome extension managers currently have around 500k users. While a small number, it still shows that there is an audience for this feature.

Google Chrome extension managers:

• Extensity (166k)
• SimpleExtManager (78k)
• Extensions Manager (aka Switcher) (74.6k)
• Extension Manager (65k)
• Disable Extensions Temporarily (36.6k)
• Chrome Extension Manager (35.8k)
• One Click Extensions Manager (19.5k)
• Custom Chrome - Extension Manager (11.6k)
• Extensions Manager (10.8k)
• NooBoss(9.9k)

Comment 9

[github]

Would like to add additional pain points from the built in add-on manager:

• can't stack add-on icons in toolbar (useful for hiding mostly passive security/privacy add-ons)
• can't quickly (few clicks) add/remove/enable/disable/configure add-ons from toolbar
• add-on screen doesn't allow sorting/organizing of list
• add-on screen doesn't support ctl+f
• no add-on scoping (tab,container,site) /automation

Comment 10

[[e-mail]]

If you have more than a handful of extensions, firefox's addon menu is very tedious. The vast amounts of empty space does not help.

Comment 11

[Rob Wu [:robwu]]

Bug 1336908 added support for enabling/disabling themes. Disabling/enabling extensions is not supported yet due to concerns of abuse.

If a patch comes along that has safeguards against abuse (e.g. prompting the user before allowing an extension to disable another extension, with clear attribution and hooking up with the "Report abuse" feature, potentially with an opt-in (internal permission / preference)), then we are willing to approve it.

Comment 12

[szh7379]

(In reply to [e-mail] from comment #10)

If you have more than a handful of extensions, firefox's addon menu is very tedious. The vast amounts of empty space does not help.

Can't agree more, nobody only install few addons, not every addon need be enabled all the time, it hurt the performance of Firefox.

Comment 13

[Mike Kaply [:mkaply]]

What about allowing it for enterprise force_installed extensions?

Comment 14

[[:7sDream]]

Please consider implementing this feature, as allowing the enable/disable functionality for extensions can be very useful, not limited to a better add-on manager.

The NooBoss extension (on Chrome) has an automatic management feature, which can automatically enable or disable certain extensions based on the currently opened URLs. I use it frequently; for example, enable the video capture extension only when I watching YouTube; enable the "remove Google redirect" extension only when I visit Google search; enable Tampermonkey only for websites where I need it, and so on.

This can significantly reduce the background tasks of extensions unrelated to the current user activity, which I believe is beneficial for both performance and battery runtime.

Comment 15

[Mike Kaply [:mkaply]]

Attachment: Bug 1282982 - Allow setEnabled for policy installed extensions. r=robwu!

Comment 16

[Mike Kaply [:mkaply]]

[Tracking Requested - why for this release]: At the RSA conference, I heard from multiple enterprise addon vendors that this was a major issue for them. So I'd like to get it in this release is possible.

I'm actively working on a patch.

It will be a very isolated, enterprise only patch.

Comment 17

[BugBot [:suhaib / :marco]]

The bug is marked as tracked for firefox139 (beta). We have limited time to fix this, the soft freeze is in 9 days. However, the bug still has low priority and has low severity.

:mixedpuppy, could you please increase the priority and increase the severity for this tracked bug? If you disagree with the tracking decision, please talk with the release managers.

For more information, please visit BugBot documentation.

Comment 18

[Mike Kaply [:mkaply]]

This will land in nightly today.

Comment 19

[Rob Wu [:robwu]]

Mike - this bug requests the feature in general, but the patch does not make the feature generally available. It limits the feature to extensions installed through the enterprise policy. Would it make sense to move the patch to a new bug blocking this bug for clarity?

Comment 20

[Mike Kaply [:mkaply]]

Yeah, that's fair.

Comment 21

[Phabricator Automation]

Comment on attachment 9485358 [details]
Bug 1282982 - Allow setEnabled for policy installed extensions. r=robwu!

Revision D247771 was moved to bug 1966113. Setting attachment 9485358 [details] to obsolete.

Comment 22

[Mike Kaply [:mkaply]]

I opened https://bugzilla.mozilla.org/show_bug.cgi?id=1966113 for this./

Comment 23

[Kory Smith]

Attachment: Bug 1282982 - Simplify setEnabled session permission tracking r?robwu

Comment 24

[Mike Kaply [:mkaply]]

What's the context here? Enterprise installed addons should be able to enable/disable other addons without user intervention.

Comment 25

[Mike Kaply [:mkaply]]

Sorry, totally misread the patch.

So you're enabling it for everyone with confirmation and leaving theme/enterprise alone.

Nice!

Comment 26

[Kory Smith]

Thank you :) I would much prefer no confirmation, but maintainers indicated the confirmation was a requirement, so I think the "allow all for this session" is a good compromise.

Comment 27

[Mike Kaply [:mkaply]]

Chrome solves this by requiring addons that use this permission to go through very strict review.

Comment 28

[Rob Wu [:robwu]]

Coincidentally, the topic of user visibility into management.setEnabled calls was just raised in the WECG today: https://github.com/w3c/webextensions/issues/955

Meeting notes pending review at https://github.com/w3c/webextensions/pull/956

Comment 29

[Rob Wu [:robwu]]

While chatting with a coworker about the proposed patch, we were wondering for the use cases behind wanting to use management.setEnabled from an extension to disable another extension. Can you elaborate on that?

The proposed patch includes a blocking modal dialog, similar to what is shown when uninstallSelf() is called. In contrast to uninstallSelf(), the prompt would not immediately offer a way for users to get rid of annoying extensions, because the prompt only asks whether to allow enabling/disabling the request (whereas in the uninstallSelf() case, the user can confirm uninstallation).

If the reasons behind controling this behavior are very niche, we could also consider introducing other mechanisms, such as a pref to allow users to opt in to extension management.

Note: Chrome recognizes the risk of allowing extensions to disable other extensions, and is working on adding a notification to the chrome://extensions/ page to warn about extensions disabled by other extensions. For backwards compatibility, they don't think that they can require user interaction/consent in management.setEnabled, but we are not bound to this backwards compatibility concern because we have not supported management.setEnabled for regular extensions yet.

Comment 30

[Kory Smith]

I'd be happy to elaborate :) My thinking is entirely selfish, and probably very specific.

Firefox is my main browser. I make heavy use of extensions. Two of these extensions are Dashlane (password manager) and SurfingKeys (use Vim keybindings to navigate the web). Whenever Dashlane auto-fills a password, it triggers SurfingKeys, which does all sorts of bad things ranging from closing my browser window to bricking the page I was trying to log into. I've opened issues in both extensions, but nobody seems interested in fixing the issue. All I wanted was a way to, with a keyboard shortcut, toggle SurfingKeys on and off. I couldn't find any way to do that.

I thought "surely there's a Firefox extension that will let me toggle other extensions," since I couldn't find this functionality natively in Firefox. So I looked in the addons store, and saw that all extensions in this category have horrible ratings. I naively thought "I'll make one that works!" which led to me learning that the management.setEnabled isn't implemented for Firefox, which brings us here.

Less selfishly, I think that the popularity of the "extension manager" extension category in Chrome (this one has 100,000 users, for example) is proof that this is something people want. Probably you don't decide on what to implement based just on what people want, but I think it's a good signal regardless.

Comment 31

[[:7sDream]]

I mentioned some of my use cases in my reply from a year ago.

Although as MV3 progresses, background extension management is becoming increasingly strict, I believe no form of control can be more energy-efficient than fully disable them. Additionally, launching specific extensions based on date/time is also a common usage scenario for me—for example, automatically enabling dark reader after 6:00 PM.

Comment 32

[Rob Wu [:robwu]]

These use cases would require the ability for extensions to be able to disable and enable extensions without further user interaction. The current patch implements a user prompt upon invocation, with the approval cached in memory. This mitigates some abuse concerns, but also at the expense of limiting the use cases.

Have you tried to use enterprise policies to force-install the extension? Extensions installed in this way are already allowed to manage other extensions.

Here are my current thoughts beyond that:

• first and foremost, users not needing this functionality should not be put at risk of a malicious extension breaking their other extensions.
• the typical use case involves one extension as the manager extension, to manage some of the extensions.
• the users of these extensions are power users.
• such power users are interested in having any way to achieve their needs. about:addons visibility is not required, about:config flags are acceptable to them.

A potential conclusion for these constraints is to simply introduce a new preference that allows users to specify the extension to serve as a manager and/or the extensions to be managed.

A potential risk in this (or any implementation of the feature) is that a user blindly follows instructions, and when they have long forgotten about the customization, become a victim of the extension's behavior. That risk can be mitigated in several ways. E.g. by presenting a notification somewhere, warning what the manager extension has done, with controls to disable the manager extension to contain abuse.

Comment 33

[fregante]

I understand the concern for abuse, there are several ways to go about this without limiting correct use cases:

• Limit management to extensions that are clearly named as such, don't allow the "Gmail Auto-Reply" extension to manage other extensions for example
• Limit extension manager extensions to this single purpose. This makes the first point easier to uphold
• Warn against extension managers both in the store and in the extension list: "THIS EXTENSION CAN DISABLE OTHER EXTENSIONS"
• Make the installation prompt scarier than "it can manage extensions", perhaps add a 10 second timer
• Add a warning when the manager disables the first extension, for example "XYZ was disabled by ABC, was this intentional? If not, click [Disable ABC]". This however feels less necessary if managers are already clearly marked AND single-purpose