889523 - We show the add-on update window on startup too often for multi-installs

Status: RESOLVED INACTIVE

(Toolkit :: Add-ons Manager, defect)

Description

[Brian R. Bondy [:bbondy]]

A large number of people use multiple installs of Firefox wile having the same profile.  For example I have Release, Aurora, and Nightly.

We have a check for add-on compatibility in place, where if the version you are using isn't the same as last time, we check for add-on updates on startup.

This slows down startup a lot for a lot of people for something that was only meant to run after updates.

Comment 1

[Brian R. Bondy [:bbondy]]

By the way, I don't know this code well so I'm not sure if this bug belongs in Firefox component or in Toolkit / Add-ons manager.  But I know I've been seeing this add-on window for a long time and just discovered why.

Comment 2

[Brian R. Bondy [:bbondy]]

Also note, this bug isn't related to recent talks about the add-on update option and win8.

Comment 3

[Robert Strong (they/them - no direct email)]

(In reply to Brian R. Bondy [:bbondy] from comment #0)
> A large number of people use multiple installs of Firefox wile having the
> same profile.  For example I have Release, Aurora, and Nightly.
> 
> We have a check for add-on compatibility in place, where if the version you
> are using isn't the same as last time, we check for add-on updates on
> startup.
> 
> This slows down startup a lot for a lot of people for something that was
> only meant to run after updates.

The assumption that it is only suppose to run after update is incorrect. It runs after app version change because an add-on that was compatible with one app version can be incompatible with a different app version.

Comment 4

[Brian R. Bondy [:bbondy]]

I still think that the check should only happen once per versuon unless addons change.

Comment 5

[Brian R. Bondy [:bbondy]]

*version

Comment 6

[Robert Strong (they/them - no direct email)]

Sure. I was just pointing out the actual reason it is displayed. There are other operations that it performs such as syncing add-on compatibility info with the remote rdf to prevent incompatible add-ons that had their compatibility info locally modified from breaking Firefox (crashes, broken UI, etc.) which used to be a pretty horrific and cause lots of bug reports and user annoyance even though they were the ones modifying it the majority of time.

There have been discussions in the past about improving this flow but there weren't the resources to do so in the past. For example, making it so add-on updates and add-on compatibility updates are staged for the next update version should prevent displaying this add-ons manager UI after an app update and I am fairly certain that would provide value to a greater population than not showing it when changing versions using the same profile.

Comment 7

[Brian R. Bondy [:bbondy]]

k cool.

Steps to reproduce this issue:
1. Install Firefox release
2. Install Nightly
3. Open Firefox release channel
4. Open Nightly (add-on compat check occurs on startup)
5. Open Firefox (add-on compat check occurs on startup)
6. Go to Step 4 and repeat, add-on compat check occur on each startup.

Comment 8

[Robert Strong (they/them - no direct email)]

(In reply to Robert Strong [:rstrong] (do not email) from comment #6)
>...
> There have been discussions in the past about improving this flow but there
> weren't the resources to do so in the past. For example, making it so add-on
> updates and add-on compatibility updates are staged for the next update
> version should prevent displaying this add-ons manager UI after an app
> update and I am fairly certain that would provide value to a greater
> population than not showing it when changing versions using the same profile.
Filed bug 890100 for this

Comment 9

[BMO Automation]

Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.