Closed Bug 760346 Opened 12 years ago Closed 6 years ago

Checking for compatible add-ons should happen in the background similar to bgupdates


(Toolkit :: Add-ons Manager, defect)

Not set





(Reporter: jaws, Unassigned)



Currently, after an update is applied upon restart Firefox pauses to iterate through the installed add-ons to make sure that each is compatible with the new version.

This checking should happen in the background after the updates have been applied by the background update service.

Until this bug is fixed, updates will not truly be silent.
If an add-on is found to be incompatible, then we should display a tab showing the add-ons we've disabled. This tab can be similar to the one introduced by bug 476430.
Unlike an individual installed Mozilla application, add-ons are profile specific, each system can have multiple profiles, and there can be multiple versions of an installed applications used by each profile. Also, the maintenance service intentionally does not have network access (which is required by the process you are trying to replace) to avoid a large class of attack vectors (not that the number of attack vectors was small with the maintenance service... it is just MUCH larger if it has network access).

It is also quite likely that the add-ons manager could perform all of what you are asking without using the maintenance service with a lot less complexity after the application update is being downloaded prior to applying it and then after it is applied apply those results based on whether the update was successful or not. It is also important to note that the actions that this is suppose to replace would still need to happen during startup when the user launched a different version of the application with a profile that was previously used by a different application version than the one being launched.

I personally don't think the proposed solution using the maintenance service is a good way to go to solve this for the reasons noted above and that there are alternatives that even though they are complex would be MUCH more complex if it were done in the maintenance service.
Removing dependency due to bgupdates being about a specific set of app update functionality around staging a downloaded update so we can apply them faster and this bug is about the add-ons manager's incompatible check that happens when ever a profile is used with a different application version, has nothing to do with staging application updates, and this bug could be implemented without any of the work in bug 307181.
No longer depends on: bgupdates
As Rob says the multiple users of the same install case makes this problematic. There are some case where we show this UI but it is unnecesary, mostly around the D2C changes but were punted to follow-ups. It might be more productive to take those out first.
Yea, easy win is to just only check for updates for addon that are now incompatible - right now it indiscriminately does it for all addons. I thought we had a bug for that...

Another big issue is making sure the compatiblity override data is up to date, so we know which D2C addons are known to be incompatible. We currently do that in that dialog.
(In reply to Blair McBride (:Unfocused) from comment #5)
> Yea, easy win is to just only check for updates for addon that are now
> incompatible - right now it indiscriminately does it for all addons. I
> thought we had a bug for that...

I could have sworn so too but couldn't find one so I filed bug 760356
For the > 80% case users should only have one profile for their machine, so any addons not handled by bug 760356 could also be checked for compatibility while the application is still running (before restart & update).

In the case of multiple profiles we can still show this UI for all but the profile that was running when the user updated.
This kind of compat checking no longer happens I believe with WebExtensions.
Closed: 6 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.