627240 - Consider shipping built-in extensions as being installed into profiles

Status: VERIFIED FIXED

(SeaMonkey :: Build Config, defect)

Description

[Robert Kaiser]

If I read bug 474289 correctly (Mossop, please correct me if I'm wrong), our current way of shipping add-on in the application's main extensions/ directory didn't change, but if we ship them in a distribution/extensions/ directory instead, they'll be installed into the users' profiles instead and we can escape the conflicts we have right now with different versions shipping in the app and being in profiles due to updates via AMO (esp. ChatZilla and DOMi have seen that, maybe also venkman).

In that case, we should consider moving to that, given it's the new way of doing things and makes things generally work better.

Comment 1

[Dave Townsend [:mossop]]

Yep this will allow your users to update and uninstall the add-ons you ship this way as they choose but you can also ship updates with your app

Comment 2

[Justin Wood (:Callek)]

Requesting Blocking seamonkey-2.1 (final) as I think this will dramatically improve our user experience!

Comment 3

[Robert Kaiser]

I don't dare to block on it if we don't know that someone will work on it...
It's wanted for sure, though.

Comment 4

[Serge Gautherie (:sgautherie)]

(In reply to comment #0)

> If I read bug 474289 correctly (Mossop, please correct me if I'm wrong), our

That bug changeset is all in Core/Toolkit.

> current way of shipping add-on in the application's main extensions/ directory
> didn't change, but if we ship them in a distribution/extensions/ directory
> instead

What does SeaMonkey need to do?
"Just" change the directory which the extensions are shipped in?
Maybe something to remove them from the older location too, or not?

Comment 5

[Dave Townsend [:mossop]]

(In reply to comment #4)
> (In reply to comment #0)
> 
> > If I read bug 474289 correctly (Mossop, please correct me if I'm wrong), our
> 
> That bug changeset is all in Core/Toolkit.
> 
> > current way of shipping add-on in the application's main extensions/ directory
> > didn't change, but if we ship them in a distribution/extensions/ directory
> > instead
> 
> What does SeaMonkey need to do?
> "Just" change the directory which the extensions are shipped in?
> Maybe something to remove them from the older location too, or not?

Yes, you might also want to switch to shipping them as packed XPIs instead of unpacked directories now too (in fact you could do that regardless of this move) for performance reasons.

Comment 6

[Serge Gautherie (:sgautherie)]

(In reply to comment #5)
> you might also want to switch to shipping them as packed XPIs instead of
> unpacked directories now too (in fact you could do that regardless of this
> move) for performance reasons.

Ftr, KaiRo already did that part with the switch to omni.jar ;-)

Comment 7

[Robert Kaiser]

(In reply to comment #4)
> That bug changeset is all in Core/Toolkit.

Sure, Firefox doesn't ship any built-in addons that should be installed in the profile. The patch just enables this to be done.

> What does SeaMonkey need to do?
> "Just" change the directory which the extensions are shipped in?

Yes, just change the location the XPIs for DOMI, venkman, and chatzilla end up in finally to be distribution/extensions/ instead of just extensions/

> Maybe something to remove them from the older location too, or not?

Yes, we'll probably want to put the current locations into removed-files (even though it only affects nightly users so far, we never shipped packaged XPIs in a milestones, and the unpackaged ones are in removed-files anyhow.

Comment 8

[Tony Mechelynck [:tonymec]]

(In reply to comment #7)
> Yes, just change the location the XPIs for DOMI, venkman, and chatzilla end up
> in finally to be distribution/extensions/ instead of just extensions/

also, I suppose, DebugQA in nightlies? Then what about the built-in themes?

Comment 9

[Justin Wood (:Callek)]

(In reply to comment #8)
> (In reply to comment #7)
> > Yes, just change the location the XPIs for DOMI, venkman, and chatzilla end up
> > in finally to be distribution/extensions/ instead of just extensions/
> 
> also, I suppose, DebugQA in nightlies? 

In my opinion, DebugQA can stay a shipped extension; and we can have code to remove it in the "real" final release, easily. No need to have it propagate to the profile.

>Then what about the built-in themes?

I think these *need* to stay shipped with the app, I'm open to be proven wrong though.

Comment 10

[Dave Townsend [:mossop]]

(In reply to comment #9)
> (In reply to comment #8)
> >Then what about the built-in themes?
> 
> I think these *need* to stay shipped with the app, I'm open to be proven wrong
> though.

Assuming the theme's jar files are actually in the extension directory (this isn't the case for Firefox's theme so maybe not for yours either) then they could go to the profile, I'd expect you to want to keep at least one with the application though.

Comment 11

[Serge Gautherie (:sgautherie)]

(In reply to comment #9)

> In my opinion, DebugQA can stay a shipped extension; and we can have code to
> remove it in the "real" final release, easily.

I assume we can do without such code: nightlies and releases should (be expected to) not be mixed.

> No need to have it propagate to the profile.

Iiuc, only extensions likely to be updated "asynchronously to releases" should be moved to the profile: they should be CZ, DOMi and Venkman only.

Comment 12

[Serge Gautherie (:sgautherie)]

Iiuc, bug 594858 should be an example of what needs to be done (for our 3 add-ons and maybe DebugQA too).

Comment 13

[Robert Kaiser]

I agree with Callek's comment #9, FWIW. We only want to care about DOMi, ChatZilla, and venkman in here.

Comment 14

[Robert Kaiser]

This doesn't block bug 629037, as that one is a current regression and beta blocker, while the bug here is an enhancement (one we want to have, but don't have to for shipping something).
When working on this bug here, we should also take into account fixing the installer in the places pointed out by bug 629037, though.

Comment 15

[Robert Kaiser]

Strongly wanted, but I wouldn't block on it.

Comment 16

[therube]

(In reply to comment #4)
> Maybe something to remove them from the older location too, or not?

I had run into issues with ChatZilla in the past: http://therube.pastebin.com/Jba2ikUf

Comment 17

[Serge Gautherie (:sgautherie)]

(In reply to comment #16)
> I had run into issues with ChatZilla in the past:
> http://therube.pastebin.com/Jba2ikUf

Could you make a brief summary of that, wrt this bug?

Comment 18

[therube]

When I migrated from SeaMonkey 2.0.x Branch to 2.1.x Trunk I kept my existing 2.0 Profile, using that also for 2.1.

That worked fine for a long time.

At one point I noticed that Chat was not behaving properly; status bar information [date, time] stopped displaying.

A new Profile did work as expected.

Exploring, I then realized that I had in fact two installed copies of cZ.  One in my Profile directory, installed along with 2.0, & one in SeaMonkey's installation directory, installed along with 2.1.

Would seem that for SeaMonkey, a downloaded cZ .xpi, should ... not sure?  Only install globally, into the SeaMonkey installation directory?  Or should check to see if there is an existing version there, & if so, then only install there.  If not existing, suppose a Profile install could be OK.  But then what happens if you download & install a new SeaMonkey & this time do choose to install cZ.  Then the installer needs to check - for existing Profiles, & instances of cZ there, & figure what to do with that? ...

Comment 19

[Robert Kaiser]

therube, this bug will solve those problems by never using the add-ons from inside the app but only deliver updates with the app and always use an in-profile copy. Conveniently, all those add-ons we ship are always backwards-compatible with a few more versions, so that all should do fine.

Comment 20

[Robert Kaiser]

I'm testing a patch right now :)

Comment 21

[Robert Kaiser]

Attachment: v1: move shipped extensions into distribution/

Here's the patch, seems to pass my tests but I can't test the Windows installer.

Note that you need to trigger an on-startup add-on compat check when launching to trigger installation of the add-ons into the profile, so you need to either re-set the extensions.lastAppVersion to something else than the current version or use a fresh profile.

Comment 22

[Justin Wood (:Callek)]

Comment on attachment 520478 [details] [diff] [review]
v1: move shipped extensions into distribution/

>diff --git a/suite/installer/package-manifest.in b/suite/installer/package-manifest.in
> [chatzilla]
> #ifdef MOZ_OMNIJAR
>-@BINPATH@/extensions/{59c81df5-4b7a-477b-912d-4e0fdf64e5f2}.xpi
>+@BINPATH@/distribution/extensions/{59c81df5-4b7a-477b-912d-4e0fdf64e5f2}.xpi
> #else
> @BINPATH@/extensions/{59c81df5-4b7a-477b-912d-4e0fdf64e5f2}/chrome/chatzilla@JAREXT@

The non-OMNIJAR codepath on these needs to be changed too, you are setting them to distribution/ either way.

(Still going over patch, but wanted to point that out now)

Comment 23

[Justin Wood (:Callek)]

Comment on attachment 520478 [details] [diff] [review]
v1: move shipped extensions into distribution/

...Whops, forgot this was all ifdef OMNIJAR

Comment 24

[Justin Wood (:Callek)]

Comment on attachment 520478 [details] [diff] [review]
v1: move shipped extensions into distribution/

Looks good on code inspection, will build fresh and generate the installer in just a bit. Please hold landing until we test the win installer.

Comment 25

[Robert Kaiser]

Tested an installer made by Callek and verified it works fine both on a fresh install as well as an install over a current trunk build.

With that verified and an OK from Callek via IRC, landed the patch as http://hg.mozilla.org/comm-central/rev/9bc8ca36184a

Comment 26

[Tony Mechelynck [:tonymec]]

=> VERIFIED. See bug 646719 comment #3 for details.