Consider shipping built-in extensions as being installed into profiles

VERIFIED FIXED in seamonkey2.1b3

Status

SeaMonkey
Build Config
VERIFIED FIXED
6 years ago
5 years ago

People

(Reporter: Robert Kaiser, Assigned: Robert Kaiser)

Tracking

Trunk
seamonkey2.1b3
Dependency tree / graph

Firefox Tracking Flags

(blocking-seamonkey2.1 -, seamonkey2.1 verified)

Details

Attachments

(1 attachment)

(Assignee)

Description

6 years ago
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.
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
Requesting Blocking seamonkey-2.1 (final) as I think this will dramatically improve our user experience!
blocking-seamonkey2.1: --- → ?
(Assignee)

Comment 3

6 years ago
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.
status-seamonkey2.1: --- → wanted
(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?
Version: unspecified → Trunk
(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.
(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 ;-)
(Assignee)

Comment 7

6 years ago
(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.
(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?
(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.
(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.
(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.
Iiuc, bug 594858 should be an example of what needs to be done (for our 3 add-ons and maybe DebugQA too).
Depends on: 594858
(Assignee)

Comment 13

6 years ago
I agree with Callek's comment #9, FWIW. We only want to care about DOMi, ChatZilla, and venkman in here.
Blocks: 629037
(Assignee)

Comment 14

6 years ago
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.
No longer blocks: 629037
(Assignee)

Comment 15

6 years ago
Strongly wanted, but I wouldn't block on it.
blocking-seamonkey2.1: ? → -

Comment 16

6 years ago
(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
(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

6 years ago
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? ...
(Assignee)

Comment 19

6 years ago
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.
(Assignee)

Comment 20

6 years ago
I'm testing a patch right now :)
Assignee: nobody → kairo
Target Milestone: --- → seamonkey2.1b3
(Assignee)

Comment 21

6 years ago
Created attachment 520478 [details] [diff] [review]
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.
Attachment #520478 - Flags: review?(bugspam.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)
Attachment #520478 - Flags: review?(bugspam.Callek) → review-
Comment on attachment 520478 [details] [diff] [review]
v1: move shipped extensions into distribution/

...Whops, forgot this was all ifdef OMNIJAR
Attachment #520478 - Flags: review- → review?(bugspam.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.
Attachment #520478 - Flags: review?(bugspam.Callek) → review+
(Assignee)

Comment 25

6 years ago
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
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Depends on: 646719
=> VERIFIED. See bug 646719 comment #3 for details.
Status: RESOLVED → VERIFIED
Blocks: 647394
No longer blocks: 647394
Depends on: 647394

Updated

6 years ago
Depends on: 649810
status-seamonkey2.1: wanted → verified
You need to log in before you can comment on or make changes to this bug.