Closed Bug 667963 Opened 10 years ago Closed 6 years ago

Extension in distribution/ not installed when browser with same version already ran


(Firefox :: Distributions, defect)

Not set



Firefox 48
Tracking Status
firefox48 --- fixed


(Reporter: BenB, Assigned: mkaply)




(1 file)

- A branded build of Firefox 5.0 with a custom extension in Firefox
  <Firefox install dir>/distribution/extensions/<emid>/


1. install FF 5.0 original
2. create a new profile
3. install FF 5.0 branded with extension
4. start the same profile


1. install FF 5.0 original and FF 5.0 branded in parallel
2. create a new profile with FF 5.0 original
3. start the same profile with FF 5.0 branded

Actual result:
No extension installed

Expected result:
Extension installed

This is currently by design
xref bug 474289
s/extension installed/extension appearing in UI/
Mozilla/5.0 (X11; Linux x86_64; rv:7.0a1) Gecko/20110630 Firefox/7.0a1 SeaMonkey/2.4a1 ID:20110630003039

In reply with comment #1: I have another use case, maybe more convincing since it uses only true-blue Mozilla builds, and related with the bugfix mentioned in comment #2:

- I test SeaMonkey trunk nightlies. Four extensions are distributed in distribution/extensions/ then automatically installed in the profile.
- Between one nightly and the next, there may be bugfixes in ChatZilla or DOMi (two of these extensions) with no change in either the app version or the extension version.
- And yet, I regret the time when all those bugfixes would immediately become active. I know it was a SeaMonkey decision, not a Toolkit decision; but I'd like some Toolkit mechanism to apply "same-version" upgrades. Even if it were, let's say, a button (manual use only) in the addons manager.

In reply to comment #0:
Workaround (not a fix) (for Firefox or SeaMonkey):
1. In about:support, find the GUID (either in email-like form or in {xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx} form where each x is a hex digit)
2. Browse to <appdir>/distribution/extensions/ (for instance for me, /usr/local/seamonkey/distribution/extensions/ — for Firefox on Windows it might be e.g. "C:\Program Files\Mozilla Firefox\distribution\extensions\" or something similar)
3. Click the xpi with the name found at step 1. This will forcibly reinstall the version of the XPI which was distributed with the current version of the browser.

A similar but slightly different workaround can be outlined for Thunderbird if necessary.
Whiteboard: [workaround see comment #4]
Oh, and of course, "browse to..." should be in URL form, e.g. for the directory I gave as a Windows example, file:///C:/Program%20Files/Mozilla%20/Firefox/distribution/extensions/ (with file:/// in front, *forward* slashes as path separators, and spaces replaced by %20).
Thanks, Tony, but this bug is about end-user distribution, so the user having to do something is not a workaround.
Whiteboard: [workaround see comment #4]
(In reply to comment #6)
> Thanks, Tony, but this bug is about end-user distribution, so the user
> having to do something is not a workaround.

Ben, a workaround is always something the user has to do to work around the fact that an actual fix is missing. If the user didn't need to do anything, it wouldn't be a workaround: it would be a fix. Either an elegant fix or an ugly hack but still a fix.
Blocks: 772544
This bug seems heavily related to bug 772544 (

I'm packaging a customized Firefox for my organization, based on the ESR release. When extracting my extension, on MAC, to distribution/extensions/ it do not get installed on current profile. Only when creating a new profile it gets installed.

When extracting to the same path (distribution/extensions/) on windows or linux, the extension gets installed to all profiles, including the current one.
Another workaround (than that in comment #4) consists of changing the value of extensions.lastAppVersion in prefs.js while the application is not running, in order to force a recheck of all extensions' version compatibilities. A side-effect of such a recheck is that any extension in distribution/extensions is brought into the current profile unless there already is an equal or later version of the same extension in that profile.

Of course, in the scenario of two distributions of the same version of Firefox (or Thunderbird, or SeaMonkey), one of them being a "branded" version with an additional addon in distribution/extensions, that addon won't go away if you run the unbranded version after the branded version in the same profile.
Duplicate of this bug: 660255
Assignee: nobody → mozilla
Component: Add-ons Manager → Distributions
Product: Toolkit → Firefox
Version: 5 Branch → Trunk
Duplicate of this bug: 641746
This is a fix for the specific problem called out in this bug.

If a profile is opened on an existing distribution of Firefox that has add-ons, those add-ons are added.

This might affect startup a tiny bit because we do some file I/O to determine the ID of the addon to do the preference check.

I think there is other work to do here, but this is a start.
Attachment #8727492 - Flags: review?(dtownsend)
This would fix bug 660255 as well.

The only open issue would be 641746 which I think is a non issue because those extensions should be updated as normal extensions, they shouldn't rely on the distro to update them.
Comment on attachment 8727492 [details] [diff] [review]
Install add-on if it has never been installed

Review of attachment 8727492 [details] [diff] [review]:

Looks good but before landing please do some talos runs on try to see what impact it has on desktop and mobile startup times.
Attachment #8727492 - Flags: review?(dtownsend) → review+
Here's my talos runs.

These are desktop only. I didn't see any Talos tests for mobile.

I honestly don't know what to look for. Any advice appreciated.
(In reply to Mike Kaply [:mkaply] from comment #17)
> Here's my talos runs.
> compare?originalProject=try&originalRevision=6e0a1c5fa5fa&newProject=try&newR
> evision=8777fe92c01f&framework=1&showOnlyImportant=0
> These are desktop only. I didn't see any Talos tests for mobile.
> I honestly don't know what to look for. Any advice appreciated.

ts_paint would be the main one to be interested in here and that is looking fine for linux. Windows tends to have worse file I/O performance though so I've gone ahead and triggered windows builds so we can double check the numbers there too.

Any thoughts on that last try run? It looks good to me...
Flags: needinfo?(dtownsend)
(In reply to Mike Kaply [:mkaply] from comment #21)
> Mossop:
> Any thoughts on that last try run? It looks good to me...

Sorry, missed your comment. Looks good to me, let's land this.
Flags: needinfo?(dtownsend)
Bug 667963 - Load distribution extensions for existing profiles; r=Mossop
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 48
You need to log in before you can comment on or make changes to this bug.