Closed Bug 616457 Opened 14 years ago Closed 14 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]
Status: NEW → RESOLVED
Closed: 14 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: