1251846 - System Add-ons such as Hello and Pocket should be able to be uninstalled by all users.

Status: RESOLVED WONTFIX

(Toolkit :: Add-ons Manager, enhancement)

Description

[WildcatRay]

At present, users can only disable system add-ons like Hello and Pocket. It appears that if they delete the .xpi files from \browser\features in an attempt to remove these system add-ons, partial updates will fail forcing the users to have to endure a full push update.

What should happen is users should be prompted during the install process if they also wish to have these system add-ons installed or not. These choices should not be hidden under Standard installation either.

Also, when updating the browser when any system add-ons have not been installed by the user, the following should happen. The update process shall gracefully skip over any part of the update involving missing system add-ons while install all other parts of the update without issue.

Comment 1

[u52928]

I agree with WildcatRay 100%.

Comment 2

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

or at least option to disable them will be also nice, the same like it's with plugins

Comment 3

[Dave Townsend [:mossop]]

System add-ons are really just an implementation detail. They are just a different way of shipping Firefox features. We might be exposing a way to disable them but why would we need a way to uninstall them?

Comment 4

[msth67]

Because when I decide I'm no longer using an addon, I usually uninstall it instead of just disabling it and leaving it there? 
 
And because of security issues such as this one https://bugzilla.mozilla.org/show_bug.cgi?id=959893 I may not want to have this code at all in my browser.

What's the difference between disabling such "system addons" vs. toggling them off in about:config ?

Comment 5

[WildcatRay]

(In reply to Dave Townsend [:mossop] from comment #3)
> System add-ons are really just an implementation detail. They are just a
> different way of shipping Firefox features. We might be exposing a way to
> disable them but why would we need a way to uninstall them?

By definition, an add-on is not essential to the basic function of a web browser which is to browse the internet. Therefore, it should be up to the user whether or not they want that add-on installed.

Also, an add-on is "code-bloat" that will use the users' computer resources unless users know to disable it or, as the bug seeks to do, empower the user to decide whether or not the add-on is installed on their computers at all.

(In reply to [e-mail] from Comment #4)
> What's the difference between disabling such "system addons" vs. toggling them off in about:config ?

At present, all a user can do is go into about:config, locate the pref and disable it there unless they install another add-on that provides a UI to disable the system add-on. Classic Theme Restorer is one such add-on.

:mossop does mention in Comment #3 that a way other than going into about:config may be added. My guess is somewhere in Options, users will be able to (un)check a box to (disable)enable a system add-on. Of course, users will have to know to go to where the choice option is and choose whether or not to disable/enable the system add-on.

Again, this bug seeks to avoid the need for all this added complexity and potential user confusion.

Comment 6

[Dave Townsend [:mossop]]

(In reply to WildcatRay from comment #5)
> (In reply to Dave Townsend [:mossop] from comment #3)
> > System add-ons are really just an implementation detail. They are just a
> > different way of shipping Firefox features. We might be exposing a way to
> > disable them but why would we need a way to uninstall them?
> 
> By definition, an add-on is not essential to the basic function of a web
> browser which is to browse the internet. Therefore, it should be up to the
> user whether or not they want that add-on installed.

User installable add-ons maybe. But system add-ons really shouldn't be called add-ons at all, they are just Firefox features that happen to be packaged in a different way.

> Also, an add-on is "code-bloat" that will use the users' computer resources
> unless users know to disable it or, as the bug seeks to do, empower the user
> to decide whether or not the add-on is installed on their computers at all.

Whether the feature is disabled or not affects whether it uses resources (beyond a small amount of disk space). Whether it is installed or not has no impact.

> (In reply to [e-mail] from Comment #4)
> > What's the difference between disabling such "system addons" vs. toggling them off in about:config ?
> 
> At present, all a user can do is go into about:config, locate the pref and
> disable it there unless they install another add-on that provides a UI to
> disable the system add-on. Classic Theme Restorer is one such add-on.
> 
> :mossop does mention in Comment #3 that a way other than going into
> about:config may be added. My guess is somewhere in Options, users will be
> able to (un)check a box to (disable)enable a system add-on. Of course, users
> will have to know to go to where the choice option is and choose whether or
> not to disable/enable the system add-on.
> 
> Again, this bug seeks to avoid the need for all this added complexity and
> potential user confusion.

Providing a way to uninstall these also adds complexity and potential user confusion.

Comment 7

[matthias koplenig [:metasieben]]

> Providing a way to uninstall these also adds complexity and potential user confusion.

While an easier way to disable system-addons would be welcome, adding to the current mess of addons/extensions/plugins/… with yet another one seems rather silly. (exposed via about:addons?)

Currently there are at least two ways to disable system-addons in Nightly, at least one in Firefox 45.

Maybe shipping about:performance will satisfy most users demands?

Comment 8

[WildcatRay]

(In reply to Dave Townsend [:mossop] from comment #6)
> (In reply to WildcatRay from comment #5)
> > (In reply to Dave Townsend [:mossop] from comment #3)
> > > System add-ons are really just an implementation detail. They are just a
> > > different way of shipping Firefox features. We might be exposing a way to
> > > disable them but why would we need a way to uninstall them?
> > 
> > By definition, an add-on is not essential to the basic function of a web
> > browser which is to browse the internet. Therefore, it should be up to the
> > user whether or not they want that add-on installed.
> 
> User installable add-ons maybe. But system add-ons really shouldn't be
> called add-ons at all, they are just Firefox features that happen to be
> packaged in a different way.

What you are trying to use is semantics to defend your position. Mozilla is calling them “system add-ons”. The terminology of “system add-ons” defines them as not essential to the browser and therefore they should not be included as an integrated part of the browser.

> > Also, an add-on is "code-bloat" that will use the users' computer resources
> > unless users know to disable it or, as the bug seeks to do, empower the user
> > to decide whether or not the add-on is installed on their computers at all.
> 
> Whether the feature is disabled or not affects whether it uses resources
> (beyond a small amount of disk space). Whether it is installed or not has no
> impact.
> 
> > (In reply to [e-mail] from Comment #4)
> > > What's the difference between disabling such "system addons" vs. toggling them off in about:config ?
> > 
> > At present, all a user can do is go into about:config, locate the pref and
> > disable it there unless they install another add-on that provides a UI to
> > disable the system add-on. Classic Theme Restorer is one such add-on.
> > 
> > :mossop does mention in Comment #3 that a way other than going into
> > about:config may be added. My guess is somewhere in Options, users will be
> > able to (un)check a box to (disable)enable a system add-on. Of course, users
> > will have to know to go to where the choice option is and choose whether or
> > not to disable/enable the system add-on.
> > 
> > Again, this bug seeks to avoid the need for all this added complexity and
> > potential user confusion.
> 
> Providing a way to uninstall these also adds complexity and potential user
> confusion.

I can tell you how to avoid that complexity. Instead of including system add-ons in the compiled program, they can be offered by links on the startup page or an under toolbar banner that appears after install or update of the browser. That is much simpler than what either of us have discussed previously. It also moves system add-ons to where they should be, offered only through addons.mozilla.org and installed in the user's profile and about:addons.

Comment 9

[WildcatRay]

(In reply to matthias koplenig from comment #7)
> > Providing a way to uninstall these also adds complexity and potential user confusion.
> 
> While an easier way to disable system-addons would be welcome, adding to the
> current mess of addons/extensions/plugins/… with yet another one seems
> rather silly. (exposed via about:addons?)
> 
> Currently there are at least two ways to disable system-addons in Nightly,
> at least one in Firefox 45.
> 
> Maybe shipping about:performance will satisfy most users demands?

Empowering users to not have to deal with unwanted add-ons is what will satisfy users who do not want those add-ons included in their browser. That is why I filed this bug.

Comment 10

[Dave Townsend [:mossop]]

(In reply to WildcatRay from comment #8)
> (In reply to Dave Townsend [:mossop] from comment #6)
> > (In reply to WildcatRay from comment #5)
> > > (In reply to Dave Townsend [:mossop] from comment #3)
> > > > System add-ons are really just an implementation detail. They are just a
> > > > different way of shipping Firefox features. We might be exposing a way to
> > > > disable them but why would we need a way to uninstall them?
> > > 
> > > By definition, an add-on is not essential to the basic function of a web
> > > browser which is to browse the internet. Therefore, it should be up to the
> > > user whether or not they want that add-on installed.
> > 
> > User installable add-ons maybe. But system add-ons really shouldn't be
> > called add-ons at all, they are just Firefox features that happen to be
> > packaged in a different way.
> 
> What you are trying to use is semantics to defend your position. Mozilla is
> calling them “system add-ons”. The terminology of “system add-ons” defines
> them as not essential to the browser and therefore they should not be
> included as an integrated part of the browser.

You're doing the same by saying that just because we (mistakenly IMO) locked onto calling these things "add-ons" that that makes them non-essential. I'm just working from the actual requirements we defined for these things: https://wiki.mozilla.org/Firefox/Go_Faster/Client_Requirements

> > > Also, an add-on is "code-bloat" that will use the users' computer resources
> > > unless users know to disable it or, as the bug seeks to do, empower the user
> > > to decide whether or not the add-on is installed on their computers at all.
> > 
> > Whether the feature is disabled or not affects whether it uses resources
> > (beyond a small amount of disk space). Whether it is installed or not has no
> > impact.
> > 
> > > (In reply to [e-mail] from Comment #4)
> > > > What's the difference between disabling such "system addons" vs. toggling them off in about:config ?
> > > 
> > > At present, all a user can do is go into about:config, locate the pref and
> > > disable it there unless they install another add-on that provides a UI to
> > > disable the system add-on. Classic Theme Restorer is one such add-on.
> > > 
> > > :mossop does mention in Comment #3 that a way other than going into
> > > about:config may be added. My guess is somewhere in Options, users will be
> > > able to (un)check a box to (disable)enable a system add-on. Of course, users
> > > will have to know to go to where the choice option is and choose whether or
> > > not to disable/enable the system add-on.
> > > 
> > > Again, this bug seeks to avoid the need for all this added complexity and
> > > potential user confusion.
> > 
> > Providing a way to uninstall these also adds complexity and potential user
> > confusion.
> 
> I can tell you how to avoid that complexity. Instead of including system
> add-ons in the compiled program, they can be offered by links on the startup
> page or an under toolbar banner that appears after install or update of the
> browser. That is much simpler than what either of us have discussed
> previously. It also moves system add-ons to where they should be, offered
> only through addons.mozilla.org and installed in the user's profile and
> about:addons.

This adds complexity to the first-run experience possible putting users off. And the point of these is that they are features we expect all of our users to have.

Comment 11

[WildcatRay]

(In reply to Dave Townsend [:mossop] from comment #10)
> (In reply to WildcatRay from comment #8)
> > (In reply to Dave Townsend [:mossop] from comment #6)
> > > (In reply to WildcatRay from comment #5)
> > > > (In reply to Dave Townsend [:mossop] from comment #3)
> > > > > System add-ons are really just an implementation detail. They are just a
> > > > > different way of shipping Firefox features. We might be exposing a way to
> > > > > disable them but why would we need a way to uninstall them?
> > > > 
> > > > By definition, an add-on is not essential to the basic function of a web
> > > > browser which is to browse the internet. Therefore, it should be up to the
> > > > user whether or not they want that add-on installed.
> > > 
> > > User installable add-ons maybe. But system add-ons really shouldn't be
> > > called add-ons at all, they are just Firefox features that happen to be
> > > packaged in a different way.
> > 
> > What you are trying to use is semantics to defend your position. Mozilla is
> > calling them “system add-ons”. The terminology of “system add-ons” defines
> > them as not essential to the browser and therefore they should not be
> > included as an integrated part of the browser.
> 
> You're doing the same by saying that just because we (mistakenly IMO) locked
> onto calling these things "add-ons" that that makes them non-essential. I'm
> just working from the actual requirements we defined for these things:
> https://wiki.mozilla.org/Firefox/Go_Faster/Client_Requirements

Requirements change all the time. Naming them "system add-ons" was prescient. These are optional. These are not necessary to browse the internet. Therefore the users should be not be bothered by them being installed without the users' approval.

> 
> > > > Also, an add-on is "code-bloat" that will use the users' computer resources
> > > > unless users know to disable it or, as the bug seeks to do, empower the user
> > > > to decide whether or not the add-on is installed on their computers at all.
> > > 
> > > Whether the feature is disabled or not affects whether it uses resources
> > > (beyond a small amount of disk space). Whether it is installed or not has no
> > > impact.
> > > 
> > > > (In reply to [e-mail] from Comment #4)
> > > > > What's the difference between disabling such "system addons" vs. toggling them off in about:config ?
> > > > 
> > > > At present, all a user can do is go into about:config, locate the pref and
> > > > disable it there unless they install another add-on that provides a UI to
> > > > disable the system add-on. Classic Theme Restorer is one such add-on.
> > > > 
> > > > :mossop does mention in Comment #3 that a way other than going into
> > > > about:config may be added. My guess is somewhere in Options, users will be
> > > > able to (un)check a box to (disable)enable a system add-on. Of course, users
> > > > will have to know to go to where the choice option is and choose whether or
> > > > not to disable/enable the system add-on.
> > > > 
> > > > Again, this bug seeks to avoid the need for all this added complexity and
> > > > potential user confusion.
> > > 
> > > Providing a way to uninstall these also adds complexity and potential user
> > > confusion.
> > 
> > I can tell you how to avoid that complexity. Instead of including system
> > add-ons in the compiled program, they can be offered by links on the startup
> > page or an under toolbar banner that appears after install or update of the
> > browser. That is much simpler than what either of us have discussed
> > previously. It also moves system add-ons to where they should be, offered
> > only through addons.mozilla.org and installed in the user's profile and
> > about:addons.
> 
> This adds complexity to the first-run experience possible putting users off.
> And the point of these is that they are features we expect all of our users
> to have.

By that logic, there should be nothing on first run after install or update because even the littlest thing could be off-putting to users.

Of course, being forced to deal with system add-ons is also off-putting to users, too. Is there anyone at Mozilla championing these users?

Comment 12

[Dave Townsend [:mossop]]

(In reply to WildcatRay from comment #11)
> Requirements change all the time. Naming them "system add-ons" was
> prescient. These are optional. These are not necessary to browse the
> internet. Therefore the users should be not be bothered by them being
> installed without the users' approval.

Many features fit that definition, we don't seem to have bugs about making those uninstallable. So far I've not heard a valid argument for why uninstalling is needed vs. simply disabling (which is discussed elsewhere).

> > This adds complexity to the first-run experience possible putting users off.
> > And the point of these is that they are features we expect all of our users
> > to have.
> 
> By that logic, there should be nothing on first run after install or update
> because even the littlest thing could be off-putting to users.

No, it's just a trade-off like everything else. I'm just pointing out that your proposed solution isn't free of complexity.

> Of course, being forced to deal with system add-ons is also off-putting to
> users, too. Is there anyone at Mozilla championing these users?

Well, since they aren't really surfaced anywhere most users correctly see no difference between features shipped in this way and other features bundled with the browser.

Since this bug is devolving into discussion I'm going to close it. Feel free to bring this up with the wider development team in the firefox-dev mailing list.