Closed Bug 45701 Opened 24 years ago Closed 17 years ago

[seamonkey] user profile directory should have a components subdirectory to hold locally-installed XPCOM components

Categories

(SeaMonkey :: General, defect, P3)

Product:
SeaMonkey
Component:
General
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED WONTFIX
Milestone:
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.
Blocks: 45703
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
reassigning to racham
Assignee: putterman → racham
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
Blocks: 14923
If XPCOM is really intended to be more than just a Mozilla thing, shouldn't this
directory be *outside* the user profile directory?
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
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.
Keywords: mozilla1.1
OS: Windows NT → All
Hardware: PC → All
Similar to bug 45699.
Keywords: topembed
Keywords: mozilla1.0+
Keywords: topembed → topembed-
Keywords: mozilla1.0+ → mozilla1.0-
Per discussion w/arun. wont fix
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → WONTFIX
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 → ---
the decision was per the edt, not just Arun. Reclosing
Status: REOPENED → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → WONTFIX
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 → ---
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.


oh I just love those command decisions
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
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.
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.
we could have something like a component registry in that directory.  However I
do not think it is required.
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?
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

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.
Whiteboard: [t2]
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
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...
Product: Browser → Seamonkey
Note this bug is blocking the installation of adblock plus.
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.
Um, this is a seamonkey bug now.
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
> 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.
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...
Sure it can!
Status: NEW → RESOLVED
Closed: 22 years ago → 17 years ago
Resolution: --- → WONTFIX
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
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.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Depends on: suiterunner
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: 17 years ago → 17 years ago
Resolution: --- → WONTFIX
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.

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.
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
Filed bug 378913 and set the appropriate dependency.
You need to log in before you can comment on or make changes to this bug.