Closed
Bug 45701
Opened 25 years ago
Closed 18 years ago
[seamonkey] user profile directory should have a components subdirectory to hold locally-installed XPCOM components
Categories
(SeaMonkey :: General, defect, P3)
SeaMonkey
General
Tracking
(Not tracked)
VERIFIED
WONTFIX
Future
People
(Reporter: ekrock, Unassigned)
References
Details
(Keywords: helpwanted, topembed-, Whiteboard: [t2])
User profiles need to include a components subdirectory to hold locally installed XPCOM components for loading by Mozilla. This will enable local installation in the user's profile of XPCOM components on Linux where Mozilla is being run from a shared directory to which the user doesn't have write access.
Reporter | ||
Comment 1•25 years ago
|
||
Marking FUTURE as Netscape engineering is overburdened. This amounts to an enhancement request for enabling distributed installation of components in shared installation environments, and the target for FCS is individual consumers. For the first release, we can settle for users having to install components centrally. helpwanted--mozilla community members by all means please sign up to lend a hand!
Keywords: helpwanted
Summary: user profile directory should have a components subdirectory to hold locally-installed XPCOM components → user profile directory should have a components subdirectory to hold locally-installed XPCOM components
Target Milestone: --- → Future
Doing a mass reassign to Conrad Carlen. Conrad is going address all current and upcoming profile manager issues. Please do not hesitate to involve me in any of the issues.
Assignee: racham → ccarlen
If XPCOM is really intended to be more than just a Mozilla thing, shouldn't this directory be *outside* the user profile directory?
Comment 5•23 years ago
|
||
If "User profiles" is meant in terms of mozilla user profles, I don't think this is a good idea. So much of xpcom and the application has to be initialized before it is possible to even know where the mozilla user profile dir is. And then what if we changed profile dirs? What happens to components registered from a profile dir that is no longer the current profile? That would put severe limitations on what kind of component could be used in this way. It *would* be possible to load components from the OS-level user dir or the OS-level shared bin dir. Changing component to XPCOM.
Assignee: ccarlen → dougt
Component: Profile Manager BackEnd → XPCOM Registry
QA Contact: gbush → dougt
Comment 6•23 years ago
|
||
Conrad, I suspect that dir scanning code (plugins and XPCOM registration) would have to listen to profile change notifications, and re-scan upon switch.
It would be really helpfull esp. on Unixes because it would allow to install some obscure XPCOMs by individual users without affecting the system wide install. Nominating to near-past mozilla 1.0.
Updated•23 years ago
|
Keywords: mozilla1.0+
Updated•23 years ago
|
Updated•23 years ago
|
Keywords: mozilla1.0+ → mozilla1.0-
Comment 9•22 years ago
|
||
Per discussion w/arun. wont fix
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → WONTFIX
Comment 10•22 years ago
|
||
Why does Arun, not a developer, get the final say? There is tremendous interest from the add-ons community to make XUL apps work when installed in a profile (they currently don't). Eventually those same folks are likely to come up with more complex stuff that requires a true component. I'm fine with "Future", but it's a legitimate request that many folks are interested in.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Comment 11•22 years ago
|
||
the decision was per the edt, not just Arun. Reclosing
Status: REOPENED → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → WONTFIX
Comment 12•22 years ago
|
||
What's the edt? This is an open source project. Please, no unappealable, undocumented, unaccountable star-chamber decisions. Please leave the bug open, reassigned to nobody@mozilla.org, if you don't want dougt working on it. /be
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Comment 13•22 years ago
|
||
no conspiracy. I am sure it was a mistake. just for the record: do not close *any* of my bugs without talking to me -- Futured or not. I do work on mozilla outside of my duties at Netscape. Furthermore, it just aint nice.
Comment 15•22 years ago
|
||
Duh, sorry dougt: of course, bugzilla etiquette frowns on others closing your bugs. I thought the EDT non-conspiracy controlled you, or something ;-). I'm happiest when individual assignees own their own bugs. In this case, even if you didn't have time for this bug, I bet someone else would make time (helpwanted is still set). /be
Comment 16•22 years ago
|
||
I think that the simpliest thing that we can do is the following: On startup, the application can call AutoRegister() passing the location of the user's components directory. On shutdown, the application can unregister that directory. This allows the maximum flexibly for embedding applications. So, basically what we have to do for the Mozilla browser, is after the call to InitXPCOM, we aquire the component registar and call AutoRegister on the userβs components directory β or any other directories that we want XPCOM to grovel through. We should also call AutoUnregister before we make the call to xpcom shutdown. We do this unregister every shutdown since some platforms allow write access to the component registry. For these systems we donβt want users components being shared between users. We want these users components to never persist. (Note that there is only one registry file for each application β not multiple registries.) This being said, it should be quite easy for someone to hack on nsAppRunner.cpp to support this functionality.
Comment 17•22 years ago
|
||
Why can't we have a second component registry (or fragment)? The chrome registry, for example, manages to handle it. Obviously this is more work than you've described, and maybe there'd never be so many profile components where the performance difference matters.
Comment 18•22 years ago
|
||
we could have something like a component registry in that directory. However I do not think it is required.
Comment 19•22 years ago
|
||
Whoa... i'm sorry to be the public whipping boy for the (now revoked!) decision to WONTFIX but I suggested that since meaningful updates occured more than a year ago, and that we did fix bug 45699 that the lion's share of the issues with per-profile component installation were addressed (e.g. plugins such as Flash, etc.). I wasn't as exposed to what dveditz mentions in Comment 10 about interest in XUL apps. working in a per-profile manner, and I apologize for the oversight -- it won't happen again. Can someone educate me by giving an example of such an app. that relies on XPCOM components working in a per-profile way?
Comment 20•22 years ago
|
||
I think that ekrock's bug was meant a per user login β not per profile. There is nothing we can do about per profile component. See comment 5
Comment 21•22 years ago
|
||
Chatzilla, or any of the mozdev packages that rely on the jslib.mozdev.org project. There is much interest in being able to install these in the user's space on machines where the main install is read-only. This currently doesn't work, but there are patches in progress to make a pure-chrome package work. However several of the interesting ones also have to install xpcom components to work. When the folks working on chrome get done they're going to run into this roadblock next.
Updated•22 years ago
|
Whiteboard: [t2]
Comment 22•22 years ago
|
||
xpcom already provides support such that an application can register all components in a giving directory. my thinking on this is that these user components should not be persistent -- they should be automatically "found" when the application starts up. So, mozilla, or any other gecko application, can autoregister (and at shutdown unregister) all components in the user's directory. Futhermore, if the application wanted these user components to be persistent, the application could do what I suggested above (and register the user's components directory) but do not unregister the components at shutdown. With the 1.4 release (actually 1.4a release iirc), you can specify where the compreg.dat and xpti.dat files live. In order to persist the user components, these two dat files can be stored under the user's directory instead of in the applications directory. In this way, user's can specify exactly what components should be used by the given mozilla. (although note that the application must provide some kind of version information in the path to these files or different versions of the application may clobber each other.) This, of course, isn't as nice as xpcom internally handling another 'user' components directory.
Component: XPCOM Registry → Browser-General
Comment 23•21 years ago
|
||
Any more developement on this bug other than all the talks? Now people can install extension jar file to profile chrom, how hard is it to install xpcom components? There are extensions using their own xpcom components, e.g. http://enigmail.mozdev.org/ . And I am also thinking to use extension to accelerate my extension. Javascript is just too damn slow for many things. At least the javascript engine used in mozilla is too slow (transform 1MB of text using a map. How much effort has ever been put into speedup the javascript engine which mozilla is using? I mean compare to perl, python, and alikes). Since my extension can be installed in user profile, it is very unnatural to ask people to install a componenet, whose sole purpose is to accel an extension, into system directory. Users might not have the authority to do system wide installation. If mozilla trys to be a platform, installing mozilla based software into user's home directory is neccessary. You aren't expect all the mozilla based apps are writen in javascript, are you? OK, maybe you are...
Updated•20 years ago
|
Product: Browser → Seamonkey
What's blocking what? Installation of components by extensions into Firefox profiles works, I don't know why this isn't FIXED. If there's something keeping you from installing adblock plus, it's not bug 45701.
Updated•19 years ago
|
Assignee: dougt → general
Status: REOPENED → NEW
QA Contact: dougt → general
Summary: user profile directory should have a components subdirectory to hold locally-installed XPCOM components → [seamonkey] user profile directory should have a components subdirectory to hold locally-installed XPCOM components
Comment 27•18 years ago
|
||
> Um, this is a seamonkey bug now.
Since SuiteRunner has the toolkit per profile components functionality, I fail to see why this bug can't be resolved as FIXED or WORKSFORME.
Comment 28•18 years ago
|
||
But SeaMonkey != SuiteRunner. Currently, you can't download SeaMonkey and have this work. This bug can't be resolved into toolkit is in place in SeaMonkey...
Comment 29•18 years ago
|
||
Sure it can!
Status: NEW → RESOLVED
Closed: 22 years ago → 18 years ago
Resolution: --- → WONTFIX
Comment 30•18 years ago
|
||
it doesn't work here either.. "AdBlock's Component failed to install" Also, the AdBlock FAQ mentions "the extension installation system from Firefox [being] ported over to SeaMonkey 1.5" will fix this bug. Is this correct? @see http://adblockplus.org/en/faq_install#seamonkey_profile
Comment 31•18 years ago
|
||
This bug was supposed to have been resolved as FIXED or WORKSFORME. Instead it was resolved as WONTFIX, which is wrong. I should also mention that I don't agree that it should have been resolved in any way. This only works in SuiteRunner - it doesn't work in the normal SeaMonkey builds, which is what this bug was targetted against. In my mind, this needs to be reopened (or at least re-resolved properly) and then set to be dependent on bug 328887 (or whatever other bug is appropriate for the introduction of the right toolkit component into SeaMonkey and getting this working.
Updated•18 years ago
|
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Updated•18 years ago
|
Depends on: suiterunner
Comment 32•18 years ago
|
||
This bug, which is about adding a profile/components subdirectory, will not be fixed. The reason this bug was filed (giving profile-installed XPIs a way to install components) will be fixed by switching to the toolkit EM.
Status: REOPENED → RESOLVED
Closed: 18 years ago → 18 years ago
Resolution: --- → WONTFIX
Comment 33•18 years ago
|
||
That's not a reason to resolve this bug as WONTFIX. Instead, find the bug that's open for "switching to the toolkit EM", and mark that bug as a pre-requisite for this bug. Then, when *that* bug is fixed, you can resolve this bug as fixed.
Comment 34•18 years ago
|
||
Yes. The action of closing this bug as WONTFIX contradicts what was discussed in comment 27. It also makes no sense in terms of how to properly handle this.
This bug is over. Stop. Take it to livejournal if you want to express yourself.
Comment 36•18 years ago
|
||
Jason: Please leave this bug here alone. The toolkit EM will fix this problem, any further work on this in xpfe land would be wasted time :). If you really feel the need for a seperate bug, open a new bug and mark it dependent on the "turn on MOZ_XUL_APP for SeaMonkey" bug.
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•