Closed Bug 597397 Opened 10 years ago Closed 9 years ago
"Install Updates" only updates first addon in "Available Updates" addon list
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
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. 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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows 7 → All
Hardware: x86 → All
10 years ago
All of my addons are on manual updates and have been seeing this with Adblock Plus and NoScript dev versions amongst others.
Is this still a problem? I'm unable to reproduce this
Wait I misspoke, I see the problem
Re-confirming as well.
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+
Status: NEW → RESOLVED
Closed: 9 years ago
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
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.