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?
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
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
Updating QA Contact. Ccing myself.
QA Contact: jimmylee → sairuh
Assignee: trudelle → hewitt
*** Bug 148235 has been marked as a duplicate of this bug. ***
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)
*** Bug 169918 has been marked as a duplicate of this bug. ***
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.
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED
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 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.
Status: RESOLVED → VERIFIED
*** Bug 189336 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.