787699 - Don't prompt users to update explicitly disabled or blocklisted plugins

Status: RESOLVED DUPLICATE of bug 760356

(Toolkit :: Add-ons Manager, enhancement)

Description

[Joe Drew (not getting mail)]

I updated my mother-in-law's Firefox installation to 13.0.1 to 15 (she had been away from her computer for a month or two), and when 15 started up, it interrupted me with a dialog for the various disabled addons she has.

In this case, she has some addons that have been disabled either by me (Microsoft .Net assistant and Skype click-to-call) or by Mozilla (Default Manager 2.2). Firefox ineffectually looked for an update to those addons that would make them compatible, even though they would be disabled regardless.

My suggestion: don't look for addon updates on app update for blocklisted addons or addons I've explicitly disabled. In my mother-in-law's case, I believe this would have made the update entirely silent.

Comment 1

[Tony Mechelynck [:tonymec]]

There's a reason updates are looked for even for disabled addons:

In the case of user-disabled, you might want to reenable them at some future time (otherwise why keep them disabled rather than uninstall them?) and in that case you would certainly not want to unwittingly enable an out-of-date version.

In the case of app-disabled, that usually happens because (temporarily, one hopes) there is no version of those addons which is compatible with your current browser version. The assumption is that if a compatible version is found, it should be enabled back. Similarly, in the case of the few blacklisted addons (which Firefox, SeaMonkey or Thunderbird will refuse to enable even though their install.rdf says they are compatible), the blacklisting normally applies only to some specific addon versions: if the addon author publishes a new addon version which doesn't misbehave the way the older one did, then there is no reason to blacklist the new version.

Then the reason why, when upgrading to a different browser version, a dialog is displayed with a progress bar or a throbber on it, is so that you wouldn't think the browser is hung: it is taking longer than usual to start up, but that's because there is something that needs to be done before loading the first page.

I suggest WONTFIX. Blair, what do you think?

Comment 2

[Joe Drew (not getting mail)]

I don't disagree with any of the reasons to look for updates _in general_. What I object to is blocking the new version of Firefox from starting up so it to look for updates to addons that I or Mozilla have explicitly said don't use.

My proposal is just "don't run the firstrun update check for addons that are disabled or blocklisted." Check for updates in the background later for those addons, though!

One other thing:

> (otherwise why keep them disabled rather than uninstall them?)

You can't remove addons that weren't installed by Firefox, like the Skype click-to-call addon.

Comment 3

[Blair McBride [:Unfocused] (UNAVAILABLE)]

The long pole is to try to move the functionality of that dialog into the app update process itself - that's bug 760346. It's not simple, and there are various yaks to shave - including the current need to update compatibility override metadata for compatibly-by-default addons in that dialog. And there's various edge cases that mean it can't be completely removed from the tree.

Currently that dialog indiscriminately checks for updates for everything, but most people don't care that everything is perfectly up to date - just that it works and doesn't interrupt them. So the shorter-term (and much easier) fix is to make it so we only check for updates of extensions that need an update to work, and just safely skip over updating everything else until the next regular background update check. And since most add-ons are compatible-by-default now, that should remove the need to check for most add-ons. That's bug 760356, which I'll dupe to.

I think disabled add-ons fit into the category that don't need updating immediately. I wish we had data on this, but I doubt its common to re-enable a disabled add-on immediately after app-update (when taking all disabled addons for everyone into account). And for those that do do that, they need to go to the Add-ons Manager UI anyway, so can update it then if its marked as incompatible. So add-ons can just get updated during the normal background update check, rather than via the dialog.

Blocklisted add-ons that aren't user-disabled should ideally get checked as soon as possible - since any available update is likely to make the add-on usable again. However, if the add-on was already blocklisted, then there's no sudden loss of functionality at the time of the app update - so arguably the updates to those add-ons could be postponed also.