Support profile chrome content and overlays (for XPI installs)



18 years ago
8 years ago


(Reporter: m_mozilla, Assigned: hewitt)


Dependency tree / graph

Firefox Tracking Flags

(Not tracked)





18 years ago
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

17 years ago
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.  
Component: XP Apps → Installer: XPInstall Engine
OS: Mac System 9.x → All
Hardware: Macintosh → All
Summary: XUL application installs do not persist past mozilla upgrade → Allow XPI to install overlays to the profile folder

Comment 2

17 years ago
Assignee: trudelle → dveditz
QA Contact: sairuh → jimmylee
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.
Assignee: dveditz → trudelle
Component: Installer: XPInstall Engine → XP Apps

Comment 4

17 years ago
Updating QA Contact.  Ccing myself.
QA Contact: jimmylee → sairuh

Comment 5

17 years ago
Assignee: trudelle → hewitt
*** Bug 148235 has been marked as a duplicate of this bug. ***

Comment 7

17 years ago
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!
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.
Summary: Allow XPI to install overlays to the profile folder → Support profile chrome content and overlays (for XPI installs)
Depends on: 162960

Comment 9

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

Comment 10

17 years ago
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.
*** Bug 184693 has been marked as a duplicate of this bug. ***
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.
Last Resolved: 16 years ago
Resolution: --- → FIXED

Comment 13

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

The language packs attempt to load globally, then fall back to profile if that
fails. See

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.
rs vrfy.

Comment 16

16 years ago
*** Bug 189336 has been marked as a duplicate of this bug. ***
Product: Core → Mozilla Application Suite
You need to log in before you can comment on or make changes to this bug.