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

VERIFIED WONTFIX

Status

P3
normal
VERIFIED WONTFIX
18 years ago
11 years ago

People

(Reporter: ekrock, Unassigned)

Tracking

({helpwanted, topembed-})

Trunk
Future
helpwanted, topembed-
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [t2])

(Reporter)

Description

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

Updated

18 years ago
Blocks: 45703
(Reporter)

Comment 1

18 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

Comment 2

18 years ago
reassigning to racham
Assignee: putterman → racham

Comment 3

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

Comment 4

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

Comment 6

17 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.

Comment 7

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

Comment 8

17 years ago
Similar to bug 45699.

Updated

17 years ago
Keywords: topembed

Updated

17 years ago
Keywords: mozilla1.0+

Updated

17 years ago
Keywords: topembed → topembed-

Updated

17 years ago
Keywords: mozilla1.0+ → mozilla1.0-

Comment 9

16 years ago
Per discussion w/arun. wont fix
Status: NEW → RESOLVED
Last Resolved: 16 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 → ---

Comment 11

16 years ago
the decision was per the edt, not just Arun. Reclosing
Status: REOPENED → RESOLVED
Last Resolved: 16 years ago16 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 → ---

Comment 13

16 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 14

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

Comment 16

16 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.
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

16 years ago
we could have something like a component registry in that directory.  However I
do not think it is required.

Comment 19

16 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

16 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
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

16 years ago
Whiteboard: [t2]

Comment 22

16 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

15 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...
Product: Browser → Seamonkey

Comment 24

13 years ago
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.

Comment 26

13 years ago
Um, this is a seamonkey bug now.

Updated

13 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

12 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

12 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

12 years ago
Sure it can!
Status: NEW → RESOLVED
Last Resolved: 16 years ago12 years ago
Resolution: --- → WONTFIX

Comment 30

12 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

12 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

12 years ago
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---

Updated

12 years ago
Depends on: 328887

Comment 32

12 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
Last Resolved: 12 years ago12 years ago
Resolution: --- → WONTFIX

Comment 33

12 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

12 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.
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

Comment 37

12 years ago
Filed bug 378913 and set the appropriate dependency.
You need to log in before you can comment on or make changes to this bug.