597397 - "Install Updates" only updates first addon in "Available Updates" addon list

Status: VERIFIED FIXED

(Toolkit :: Add-ons Manager, defect)

Description

[Paul [pwd]]

User-Agent:       Mozilla/5.0 (Windows NT 6.1; rv:2.0b7pre) Gecko/20100917 Firefox/4.0b7pre
Build Identifier: 

If you click "Install Updates", expected behaviour is for it to install all updates in list, however it only updates the first, forcing a manual update of the second.

Reproducible: Always

Comment 1

[Henrik Skupin [:whimboo][⌚️UTC+1]]

I have problems to install extensions from AMO right now. So I cannot really confirm this issue right now. Can you please tell me which extensions do you have installed and if all of those are marked for manual update?

Comment 2

[Sven Grull]

I see this too in recent trunk builds. This happens if you have disabled automatic add-on updates and want to install the updates Firefox found via "Available Updates". This does not depend on a special add-on, it happens if there are more than one add-on to update.

Comment 3

[u279076]

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b7pre) Gecko/20100917 Firefox/4.0b7pre
SQLite Manager 0.6.1
Adblock Plus 1.2.1

Bug confirmed using the two above addon versions.

STR:
1. Install an older version of SQLite Manager
2. Install an older version of Adblock Plus
3. Restart Minefield
4. Tools > Add-ons
5. Set each add-on's automatic update pref to "off"
6. Click the utility button > check for updates
7. Click "View Available Updates"
8. Make sure "Include Update" is checked for both
9. Click Install Updates

Result:
Only the first add-on is installed.  I have to click Install Updates a second time to install the other add-on.

Expected:
Install all "checked" add-on updates.

Comment 4

[Paul [pwd]]

All of my addons are on manual updates and have been seeing this with Adblock Plus and NoScript dev versions amongst others.

Comment 5

[Dave Townsend [:mossop]]

Is this still a problem? I'm unable to reproduce this

Comment 6

[Dave Townsend [:mossop]]

Wait I misspoke, I see the problem

Comment 7

[Paul [pwd]]

Re-confirming as well.

Comment 8

[Dave Townsend [:mossop]]

Attachment: patch rev 1

A few broken things here. As a comment in the code says, things get screwy because the view refreshes while you're iterating the list of items to install, unfortunately that means just caching the elements isn't enough because when the view refreshes they lose their binding and upgrade method. But I don't know why the view needs to refresh in response to the download events at all, it really should only need it from new installs and cancelling/done stuff. The elements themselves handle updating their progress etc. for downloading.

Added an additional item to the test to verify this and also corrected what seems to be bad state at the end, the install updates button should be enabled immediately after since there is still an available update there.

Since it is no longer refreshing the view during updates I'm just using an executeSoon once both installs are done. By then the other install will either have started downloading or it never will so I think it is safe.

Comment 9

[Blair McBride [:Unfocused] (UNAVAILABLE)]

Comment on attachment 488080 [details] [diff] [review]
patch rev 1

(In reply to comment #8)
> But I don't know
> why the view needs to refresh in response to the download events at all

There was a reason why I originally needed to do it that way, but I can't remember what :\ But a lot of things have changed since that was added, so if you're not seeing any weirdness, then that old code is probably no longer relevant.

Comment 10

[Dave Townsend [:mossop]]

Landed: http://hg.mozilla.org/mozilla-central/rev/6f359bbf2b7b

Comment 11

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Verified fixed with Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b8pre) Gecko/20101111 Firefox/4.0b8pre ID:20101111030745