Closed Bug 582833 Opened 9 years ago Closed 9 years ago

Add-on manager updates add-ons whose location is not managed by Firefox


(Toolkit :: Add-ons Manager, defect)

Not set



Tracking Status
blocking2.0 --- betaN+


(Reporter: morac, Assigned: mano)


(Keywords: regression)


(1 file, 1 obsolete file)

When working on developing my add-on I keep it in a location outside of the extensions folder and link to it using the "Any location specified in a text file with a {GUID} name" method as specified in the "Install Locations" section of

That works in the Trunk loads, but if I publish a version with a larger version and have Firefox 4.0 check for an update, it downloads and installs the update into the extensions folder and removes the "link" to the current version.

Firefox 3.6.x and older won't allow this and gives an "Update not supported (install location is not managed by Firefox)" message in the Add-ons window.

The reason this is a problem is that even when I update the install.rdf file for my development version, the version isn't updated in the browser itself unless I uninstall and re-install.  In any case this is a regression and Firefox 4.0 shouldn't be doing this.
Strange, could have sworn I had guarded against this.
Assignee: nobody → dtownsend
blocking2.0: --- → betaN+
I don't know if it's related or not, but in the console right after the "Install of xxxxx completee." I see:

*** WARN addons.manager: InstallListener threw exception when calling onInstallEnded: TypeError: this.mControl.onInstallCompleted is not a function

Probably not since the add-on has already been downloaded and installed at that point.
Flags: in-testsuite?
Flags: in-litmus?
OS: Windows XP → All
Hardware: x86 → All
-> me.
Assignee: dtownsend → mano
Just a FYI, the extensions.cache lists that that add-on is in the "app-profile", but it has an absolute rather than relative path.
What is the status here, are you actually working on this Mano?
Attached patch patch (obsolete) — Splinter Review
So, are there any tests for addons installed this way?
Attachment #490616 - Flags: review?(dtownsend)
Comment on attachment 490616 [details] [diff] [review]

>+  /**
>+   * Returns true if the given addon was installed in this location by a text
>+   * file pointing to its real path.
>+   *
>+   * @param aId
>+   *        The ID of the addon
>+   */
>+  isLinkedAddon: function(aId) {
>+    return this._linkedAddons.indexOf(aId) != -1;

You could just get the directory for the add-on and check if its parent is the install location's directory rather than maintaining this array. Not terribly bothered either way though.

Tests for the file pointers can be found in test_filepointer.js
I thought about that option, but I figured it's quite pointless not to go through nsIFile for data we have handy.
Comment on attachment 490616 [details] [diff] [review]

Seems fine, but let's get a test for it too
Attachment #490616 - Flags: review?(dtownsend) → review+
Whiteboard: [has patch][needs test]
Attached patch patch with testSplinter Review
Attachment #490616 - Attachment is obsolete: true
Attachment #495559 - Flags: review?(dtownsend)
Whiteboard: [has patch][needs test]
Attachment #495559 - Flags: review?(dtownsend) → review+
Closed: 9 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Verified fixed with Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b12pre) Gecko/20110211 Firefox/4.0b12pre
Flags: in-testsuite?
Flags: in-testsuite+
Flags: in-litmus?
Flags: in-litmus-
Target Milestone: --- → mozilla2.0b9
You need to log in before you can comment on or make changes to this bug.