Closed
Bug 1231202
Opened 8 years ago
Closed 7 years ago
add about:config flag to unhide system add-ons
Categories
(Toolkit :: Add-ons Manager, defect)
Toolkit
Add-ons Manager
Tracking
()
RESOLVED
INCOMPLETE
People
(Reporter: rhelmer, Assigned: rhelmer)
Details
(Whiteboard: triaged)
Attachments
(1 file)
MozReview Request: Bug 1231202 - about:config flag to unhide system add-ons in about:addons r?mossop
40 bytes,
text/x-review-board-request
|
mossop
:
review+
|
Details |
Currently there is no way to disable current system add-ons, although they are visible in a few places (about:support and about:debugging, maybe others). We should have an about:config switch to display these in the add-ons manager, where they can be disabled. They will not be able to be removed since they are part of the Firefox application directory.
Assignee | ||
Comment 1•8 years ago
|
||
Bug 1231202 - about:config flag to unhide system add-ons in about:addons r?mossop
Attachment #8696791 -
Flags: review?(dtownsend)
Comment 2•8 years ago
|
||
Comment on attachment 8696791 [details] MozReview Request: Bug 1231202 - about:config flag to unhide system add-ons in about:addons r?mossop https://reviewboard.mozilla.org/r/27439/#review24879 Codewise this looks good. I'm wondering if we should add some confirmation dialog when a user disables a system add-on to make it clear that they are integral pieces of Firefox and disabling them may break things and we don't support that. I think it would be good to get a product manager to sign off here. ::: browser/app/profile/firefox.js:76 (Diff revision 1) > +pref("extensions.hideSystemAddons", true); I would rather not add this and just have it be a hidden pref just to make it slightly harder to stumble across.
Attachment #8696791 -
Flags: review?(dtownsend) → review+
Comment 3•8 years ago
|
||
FWIW, the pocket addon was written and tested around the notion that the user would indeed be able to disable/enable/upgrade the addon. Nothing should break if the user disabled pocket. I cant speak towards hello on this issue. IMO it should be a requirement that system addons do not break anything if disabled, if they do there is potential for breaking things if an out-of-band update were done on that addon.
Comment 4•8 years ago
|
||
The suggestion that a system add-on can't break anything else seems like it limits what we could put in a system add-on. Could we have this be a configurable within the add-on?
Comment 5•8 years ago
|
||
(In reply to Andy McKay [:andym] from comment #4) > The suggestion that a system add-on can't break anything else seems like it > limits what we could put in a system add-on. Could we have this be a > configurable within the add-on? Why should an addon be allowed to break firefox if it is disabled? If the addon is required for firefox to run, why bother with an addon at all?
Assignee | ||
Comment 6•8 years ago
|
||
(In reply to Shane Caraveo (:mixedpuppy) from comment #5) > (In reply to Andy McKay [:andym] from comment #4) > > The suggestion that a system add-on can't break anything else seems like it > > limits what we could put in a system add-on. Could we have this be a > > configurable within the add-on? > > Why should an addon be allowed to break firefox if it is disabled? If the > addon is required for firefox to run, why bother with an addon at all? I don't think a system add-on should be allowed to "break" Firefox if it's disabled (I think we should be using automated testing with/without system add-ons enabled to measure perf and to check for this). While we primarily want to use this mechanism to ship faster, I think that the logical distinction of "core" browser versus "non-core" features is worth keeping. Add-ons that ship with Firefox are exposed to users as any other feature, the rationale and pros/cons are described in the PRD: https://docs.google.com/document/d/1H0be9rVfK-molaEa3KPvPLO4hS6iSKs-eHy2HGQwMNY The PRD does mention features being "pref-offable", whether this should be in the about:addons UI or via some other UI (main Firefox preferences maybe?) or whether this is something add-ons themselves expose is worth considering.
Comment 7•8 years ago
|
||
The existence of an add-on (https://addons.mozilla.org/addon/disable-hello-pocket-reader/) to enable/disable system addons individually seems to indicate that there is a demand for such functionality; and now that that add-on does exist, if disabling one or the other system add-on breaks Firefox (which I don't think likely but you never know), bug reports about such breakage are bound to come in. FWIW, personally I haven't noticed any breakage in Fx47a1, which I use with system add-ons disabled; but I don't use Firefox as intensively as SeaMonkey (2.44a1/47.0a1) so I could quite possibly have missed the circumstances (if any) where breakage happens.
As well as the sheer existence of the "disable-hello-pocket-reader" addon mentioned by Tony Mechelynck, there is further popular demand for this functionality here: http://www.ghacks.net/2016/03/29/mozilla-system-add-ons-controls (which currently carries 44 comments).
Updated•8 years ago
|
Whiteboard: triaged
Assignee | ||
Comment 9•7 years ago
|
||
I don't think exposing these in `about:addons` is the right place. We've been using system add-ons to implement features that we can ship updates too, they aren't proper "add-ons" and have already diverged in terms of what you can control. They aren't uninstallable (they are part of the build) and can't be set into userDisabled state, for instance. It makes more sense for individual features implemented this way to provide a means through `about:config` or the Preferences UI.
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → INCOMPLETE
You need to log in
before you can comment on or make changes to this bug.
Description
•