Closed Bug 597397 Opened 10 years ago Closed 9 years ago

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


(Toolkit :: Add-ons Manager, defect)

Not set



Tracking Status
blocking2.0 --- betaN+


(Reporter: pwd.mozilla, Assigned: mossop)



(Whiteboard: [AOMTestday])


(1 file)

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
Blocks: 550048, 562622
blocking2.0: --- → ?
Version: unspecified → Trunk
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?
No longer blocks: 550048
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.
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.

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

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

Install all "checked" add-on updates.
Ever confirmed: true
OS: Windows 7 → All
Hardware: x86 → All
All of my addons are on manual updates and have been seeing this with Adblock Plus and NoScript dev versions amongst others.
blocking2.0: ? → betaN+
Is this still a problem? I'm unable to reproduce this
Wait I misspoke, I see the problem
Re-confirming as well.
Attached patch patch rev 1Splinter Review
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.
Assignee: nobody → dtownsend
Attachment #488080 - Flags: review?(bmcbride)
Whiteboard: [AOMTestday] → [AOMTestday][has patch][needs review Unfocused]
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.
Attachment #488080 - Flags: review?(bmcbride) → review+
Closed: 9 years ago
Flags: in-testsuite+
Flags: in-litmus-
Resolution: --- → FIXED
Whiteboard: [AOMTestday][has patch][needs review Unfocused] → [AOMTestday]
Target Milestone: --- → mozilla2.0b8
Verified fixed with Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b8pre) Gecko/20101111 Firefox/4.0b8pre ID:20101111030745
You need to log in before you can comment on or make changes to this bug.