Open Bug 579990 Opened 14 years ago Updated 2 years ago

Update Add-ons in the background especially before an update install

Categories

(Firefox :: General, defect)

defect

Tracking

()

People

(Reporter: jhill, Unassigned)

References

(Blocks 3 open bugs)

Details

(Keywords: perf, ux-interruption)

Add-ons should be updated, and should check for updates, in the background. Currently, the add-ons check for updates and update during the startup process which makes our startup seem slow.

Recommendation:
1. Have add-ons check for updates in the background (idle time, etc)
2. Update add-ons in the background just like Firefox.
Blocks: 580046
See also bug 468072
Summary: Update Add-ons in the background → Update Add-ons in the background before an update install
Summary: Update Add-ons in the background before an update install → Update Add-ons in the background especially before an update install
Blocks: 489138
Blocks: 447581
Irving, does this fall into your lap?
Flags: needinfo?(irving)
Currently the upgrade sequence goes something like this:

1. Ping AUS for app update
2. Realize we have an app update, download it
3. Restart
4. Apply the update
5. Check/Ask for add-on updates, download, install.
6. Start.

Instead, after 1, we can already do 5, simultaneously with 2. Of course, that means in the worst case we may need to compat check again when we do apply the update if we have broken add-ons.

Irving and/or Dave, do you think that'll work?
Flags: needinfo?(dtownsend+bugmail)
(In reply to :Gijs Kruitbosch from comment #3)
> Currently the upgrade sequence goes something like this:
> 
> 1. Ping AUS for app update
> 2. Realize we have an app update, download it
> 3. Restart
> 4. Apply the update
> 5. Check/Ask for add-on updates, download, install.
> 6. Start.
> 
> Instead, after 1, we can already do 5, simultaneously with 2. Of course,
> that means in the worst case we may need to compat check again when we do
> apply the update if we have broken add-ons.
> 
> Irving and/or Dave, do you think that'll work?

Yes however we can only safely update the add-on if it is compatible with both the current and the new version of the app, there will still be some cases where the updated add-on is only compatible with the new version of the app and so will still have to be installed after the app updates.

Given that we check for and install add-on updates once a day already the only case this would improve would be where a new version of an add-on was released in the time between the last add-on update check and the app update check.
Flags: needinfo?(dtownsend+bugmail)
(In reply to Dave Townsend (:Mossop) from comment #4)
> (In reply to :Gijs Kruitbosch from comment #3)
> > Currently the upgrade sequence goes something like this:
> > 
> > 1. Ping AUS for app update
> > 2. Realize we have an app update, download it
> > 3. Restart
> > 4. Apply the update
> > 5. Check/Ask for add-on updates, download, install.
> > 6. Start.
> > 
> > Instead, after 1, we can already do 5, simultaneously with 2. Of course,
> > that means in the worst case we may need to compat check again when we do
> > apply the update if we have broken add-ons.
> > 
> > Irving and/or Dave, do you think that'll work?
> 
> Yes however we can only safely update the add-on if it is compatible with
> both the current and the new version of the app, there will still be some
> cases where the updated add-on is only compatible with the new version of
> the app and so will still have to be installed after the app updates.

But we can download it immediately and only install it as part of the upgrade process, right? Or is there no way we can stage add-ons like this and/or would it be hard to add such a thing?


> Given that we check for and install add-on updates once a day already the
> only case this would improve would be where a new version of an add-on was
> released in the time between the last add-on update check and the app update
> check.

This is a good point I hadn't thought about. On the other hand, could we cache compat info about add-ons that are installed and not update-ping on upgrade iff the add-on is marked compatible and we've last checked for compat < N hours ago? Or is that too scary?
(In reply to :Gijs Kruitbosch from comment #5)
> (In reply to Dave Townsend (:Mossop) from comment #4)
> > (In reply to :Gijs Kruitbosch from comment #3)
> > > Currently the upgrade sequence goes something like this:
> > > 
> > > 1. Ping AUS for app update
> > > 2. Realize we have an app update, download it
> > > 3. Restart
> > > 4. Apply the update
> > > 5. Check/Ask for add-on updates, download, install.
> > > 6. Start.
> > > 
> > > Instead, after 1, we can already do 5, simultaneously with 2. Of course,
> > > that means in the worst case we may need to compat check again when we do
> > > apply the update if we have broken add-ons.
> > > 
> > > Irving and/or Dave, do you think that'll work?
> > 
> > Yes however we can only safely update the add-on if it is compatible with
> > both the current and the new version of the app, there will still be some
> > cases where the updated add-on is only compatible with the new version of
> > the app and so will still have to be installed after the app updates.
> 
> But we can download it immediately and only install it as part of the
> upgrade process, right? Or is there no way we can stage add-ons like this
> and/or would it be hard to add such a thing?

We don't have any way to do that right now, at least not one that handles the possibility of the app update failing to apply.

I don't know enough about the code that applies the app update to know how difficult it would be to add such a thing to that, I suspect difficult since it would need to access the profile folder and I don't think it knows anything about profiles.

I could imagine adding a way to stage add-on updates so they only got applied on update if the app version matched what we expected, that might be the easiest way to go about this but I think there's a lot of complicated issues around figuring out how the UI should look and behave when there is an add-on like this staged and probably difficulties around restartless add-ons which we normally don't stage for any length of time. Given the paragraph below I'm not sure it would be worth investing much time in it but maybe we could get metrics to help us understand how much pain it might solve.

> > Given that we check for and install add-on updates once a day already the
> > only case this would improve would be where a new version of an add-on was
> > released in the time between the last add-on update check and the app update
> > check.
> 
> This is a good point I hadn't thought about. On the other hand, could we
> cache compat info about add-ons that are installed and not update-ping on
> upgrade iff the add-on is marked compatible and we've last checked for
> compat < N hours ago? Or is that too scary?

The app update process already performs compatibility checks for all installed add-ons and we should only be doing checking after the restart if there are some that aren't compatible.
Flags: needinfo?(irving)
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.