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

Status: RESOLVED FIXED

(Firefox :: Distributions, defect)

Description

[Ben Bucksch (:BenB)]

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

Reproduction:

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

or

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

Ben

Comment 1

[Dave Townsend [:mossop]]

This is currently by design

Comment 2

[Ben Bucksch (:BenB)]

xref bug 474289

Comment 3

[Ben Bucksch (:BenB)]

s/extension installed/extension appearing in UI/

Comment 4

[Tony Mechelynck [:tonymec]]

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.

Comment 5

[Tony Mechelynck [:tonymec]]

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).

Comment 6

[Ben Bucksch (:BenB)]

Thanks, Tony, but this bug is about end-user distribution, so the user having to do something is not a workaround.

Comment 7

[Tony Mechelynck [:tonymec]]

(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.

Comment 8

[Marcus Semblano]

This bug seems heavily related to bug 772544 (https://bugzilla.mozilla.org/show_bug.cgi?id=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.

Comment 9

[Tony Mechelynck [:tonymec]]

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.

Comment 12

[Mike Kaply [:mkaply]]

Attachment: Install add-on if it has never been installed

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.

Comment 13

[Mike Kaply [:mkaply]]

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 14

[Dave Townsend [:mossop]]

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.

Comment 15

[Mike Kaply [:mkaply]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=c3b60490f403

Comment 16

[Mike Kaply [:mkaply]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=53ab130d76b2

Comment 17

[Mike Kaply [:mkaply]]

Here's my talos runs.

https://treeherder.mozilla.org/perf.html#/compare?originalProject=try&originalRevision=6e0a1c5fa5fa&newProject=try&newRevision=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.

Comment 18

[Dave Townsend [:mossop]]

(In reply to Mike Kaply [:mkaply] from comment #17)
> Here's my talos runs.
> 
> https://treeherder.mozilla.org/perf.html#/
> 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.

Comment 19

[Mike Kaply [:mkaply]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=f8a465697b54

Comment 20

[Mike Kaply [:mkaply]]

https://treeherder.mozilla.org/perf.html#/compare?originalProject=try&originalRevision=76caa5c8d76e&newProject=try&newRevision=e15997fceec7&framework=1&showOnlyImportant=0

Comment 21

[Mike Kaply [:mkaply]]

Mossop:

Any thoughts on that last try run? It looks good to me...

Comment 22

[Dave Townsend [:mossop]]

(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.

Comment 23

[Mike Kaply [:mkaply]]

https://hg.mozilla.org/integration/fx-team/rev/7df47cf5b048a1325db8c970aa7a9259a9472a33
Bug 667963 - Load distribution extensions for existing profiles; r=Mossop

Comment 24

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/7df47cf5b048