Closed Bug 616457 Opened 14 years ago Closed 13 years ago

Update check also checks for updates of removed add-ons

Categories

(Toolkit :: Add-ons Manager, defect)

defect
Not set
normal

Tracking

()

VERIFIED FIXED
mozilla2.0b9
Tracking Status
blocking2.0 --- betaN+

People

(Reporter: whimboo, Assigned: mossop)

References

()

Details

(Whiteboard: [AOMTestday])

Attachments

(1 file)

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b8pre) Gecko/20101201 Firefox/4.0b8pre ID:20101201030318

When an extension has been removed within a browsing session and an update check is performed without a restart, we also check for updates for the partially removed extensions. I have seen that while verifying bug 308522.

Steps:
1. Install an older version of an add-on (see URL)
2. Restart the browser and remove the add-on from within the add-ons manager
3. Check for updates

After step 3 we expose an available update to the UI, which shouldn't happen.
Good catch, I suspect in the worst case a background update check will actually update an extension waiting to be uninstalled without the user's knowledge.
blocking2.0: --- → beta9+
Assignee: nobody → dtownsend
Attached patch patch rev 1Splinter Review
Straightforward fix, marks add-ons as un-upgradable when they are pending uninstall.
Attachment #501031 - Flags: review?(robert.bugzilla)
Whiteboard: [AOMTestday] → [AOMTestday][has patch][needs review rs]
Attachment #501031 - Flags: review?(robert.bugzilla)
Whiteboard: [AOMTestday][has patch][needs review rs] → [AOMTestday][has patch][waiting on try]
blocking2.0: beta9+ → betaN+
Attachment #501031 - Flags: review?(robert.bugzilla)
Whiteboard: [AOMTestday][has patch][waiting on try] → [AOMTestday][has patch][needs review rs]
Comment on attachment 501031 [details] [diff] [review]
patch rev 1

Looks straightforward enough... just one minor nit

>diff --git a/toolkit/mozapps/extensions/XPIProvider.jsm b/toolkit/mozapps/extensions/XPIProvider.jsm
>--- a/toolkit/mozapps/extensions/XPIProvider.jsm
>+++ b/toolkit/mozapps/extensions/XPIProvider.jsm
>@@ -6478,24 +6478,26 @@ function AddonWrapper(aAddon) {
>   this.__defineGetter__("permissions", function() {
>     let permissions = 0;
>     if (!aAddon.appDisabled) {
>       if (aAddon.userDisabled)
>         permissions |= AddonManager.PERM_CAN_ENABLE;
>       else if (aAddon.type != "theme")
>         permissions |= AddonManager.PERM_CAN_DISABLE;
>     }
>-    if (aAddon._installLocation) {
>-      if (!aAddon._installLocation.locked) {
>-        if (!aAddon._installLocation.isLinkedAddon(aAddon.id))
>-          permissions |= AddonManager.PERM_CAN_UPGRADE;
>-
>-        if (!aAddon.pendingUninstall)
>-          permissions |= AddonManager.PERM_CAN_UNINSTALL;
>-      }
>+    // Add-ons that have no install location (those that are pending install) or
>+    // that are in locked install locations or are pending uninstall cannot be
>+    // upgraded or uninstalled
nit: too may or's
// Add-ons that have no install location (those that are pending install),
// are in locked install locations, or are pending uninstall cannot be
// upgraded or uninstalled

Also, it would be a good thing if the comment made it clear if only add-ons that are pending install don't have an install location.
Attachment #501031 - Flags: review?(robert.bugzilla) → review+
Whiteboard: [AOMTestday][has patch][needs review rs] → [AOMTestday][has patch]
Landed: http://hg.mozilla.org/mozilla-central/rev/0548fd8f2b18
Status: NEW → RESOLVED
Closed: 13 years ago
Flags: in-testsuite+
Flags: in-litmus-
Resolution: --- → FIXED
Whiteboard: [AOMTestday][has patch] → [AOMTestday]
Target Milestone: --- → mozilla2.0b9
Verified fixed with Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b9pre) Gecko/20110109 Firefox/4.0b9pre ID:20110109030350
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: