125610 - Support profile chrome content and overlays (for XPI installs)

Status: VERIFIED FIXED

(SeaMonkey :: UI Design, defect)

Description

[m_mozilla]

I install the prefs toolbar each time I switch nightlies.

Fortunately, that's the only XUL app I install, and I know where to find it when
I need to re-isntall... which I need to do every time I upgrade mozilla.

I can imagine that joe-sixpack might get some spiffy XUL app from his geek
friend, and then months later update his mozilla and not be able to get his
spiffy XUL app because he doesn't have a clue where it came from.

Is there any way we could have an option to install these things into profile
space, so they'd be more persistant?

Comment 1

[Andy Edmonds]

Changing title from "XUL application installs do not persist past mozilla
upgrade" to "Allow XPI to install overlays to the profile folder".

This would allow installs to persist across Mozilla installs as language packs
do.  In addition, it would solve a variety of Linux permisssion errors where a
user may not have write access to the chrome folder. 

This was recognized as a serious and known issue at the CMU developer's day.  

Comment 2

[Peter Trudelle]

->component

Comment 3

[Daniel Veditz [:dveditz]]

Back to XP Apps. XPInstall will happily attempt to register chrome in the 
profile and calls the Chrome Registry to do so. 
If nsIChromeRegistry::InstallPackage() with the isProfile arg true doesn't work 
that's not an XPInstall problem.

Comment 4

[Jimmy Lee]

Updating QA Contact.  Ccing myself.

Comment 5

[Peter Trudelle]

->hewitt

Comment 6

[Daniel Veditz [:dveditz]]

*** Bug 148235 has been marked as a duplicate of this bug. ***

Comment 7

[Glen Nakamura]

Is someone working on this bug?  I'm actually finding that XPInstall will
successfully install overlays into the profile, but Mozilla fails to load them
when it starts.  I've filed a complementary bug report (Bug 162960) and
submitted a patch which fixes the problem on my system.  Could I please get
someone to review it?  Thanks!

Comment 8

[Daniel Veditz [:dveditz]]

Changing summary to reflect the fact that the work is in the chrome registry,
not XPInstall. The patch Glen contributed in bug 162960 solves a big chunk of
the problem, maybe all of it, I'll play around.

Comment 9

[R.K.Aa.]

*** Bug 169918 has been marked as a duplicate of this bug. ***

Comment 10

[Dan Price]

I'm playing around with a custom toolbar similar to the googlebar to roll
out to users as a front-end to an LXR installation; for various reasons
a sherlock plugin doesn't give me a rich enough search tool (chief among
them is that the search has too many parameters and options-- the LXR tracks
many different, disjoint source bases).

Many of our users rely on a shared installation of mozilla.  As such, we
can't install googlebar and other similar tools cleanly.  If this bug
solves that problem, *please* fix it!  Thanks!

This will be of particular benefit to large-installation UNIX users.  Kudos
to Glen for taking a swipe at a fix.

Comment 11

[Asa Dotzler [:asa]]

*** Bug 184693 has been marked as a duplicate of this bug. ***

Comment 12

[Daniel Veditz [:dveditz]]

This should work now that bug 162960 has been fixed. add-on authors will have to
re-write their installs to take advantage of this, though. They can either
install to the profile always, or check for write-errors to the global location
and fall-back to the profile the way the locale installs do.

Comment 13

[Dan Price]

Is there an example or tutorial somewhere of how to do this
(comment #12) properly?

Comment 14

[Daniel Veditz [:dveditz]]

The language packs attempt to load globally, then fall back to profile if that
fails. See
http://lxr.mozilla.org/mozilla/source/xpinstall/packager/windows/langenus.jst

A chrome provider may also wish to skip the global installation (or make it an
option) and go straight for the profile. That's simpler to script, and has the
advantage of not getting blown away each time the user upgrades their nightly
Mozilla build since the profile is not touched.

Comment 15

[sairuh (rarely reading bugmail)]

rs vrfy.

Comment 16

[Jon Henry]

*** Bug 189336 has been marked as a duplicate of this bug. ***