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

VERIFIED FIXED in mozilla2.0b8



Add-ons Manager
7 years ago
7 years ago


(Reporter: Paul [pwd], Assigned: mossop)


Bug Flags:
in-testsuite +
in-litmus -

Firefox Tracking Flags

(blocking2.0 betaN+)


(Whiteboard: [AOMTestday])


(1 attachment)



7 years ago
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


7 years ago
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

Comment 2

7 years ago
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
Whiteboard: [AOMTestday]

Comment 4

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


7 years ago
blocking2.0: ? → betaN+

Comment 5

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

Comment 6

7 years ago
Wait I misspoke, I see the problem

Comment 7

7 years ago
Re-confirming as well.

Comment 8

7 years ago
Created attachment 488080 [details] [diff] [review]
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.
Assignee: nobody → dtownsend
Attachment #488080 - Flags: review?(bmcbride)


7 years ago
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+

Comment 10

7 years ago
Landed: http://hg.mozilla.org/mozilla-central/rev/6f359bbf2b7b
Last Resolved: 7 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.