Closed Bug 45703 Opened 19 years ago Closed 18 years ago

XPCOM initialization code should check user's profile's components directory for local XPCOM components


(Core :: XPCOM, defect, P3)

Windows NT





(Reporter: ekrock, Assigned: dougt)



(Keywords: helpwanted)

We need to we enable the local installation of XPCOM components (including new 
plug-ins) by users on Linux who are running a Mozilla-based browser from a 
shared server directory to which they do not have write access

Navigator 4 enabled this for plug-ins via a local plugins directory in the 
user's profile. Users running Nav4 from a shared server directory could install 
plug-ins locally in their profile's plugins directory, and plug-ins installed in 
the profile's directory took precedence over any conflicting plug-ins in the 
shared server directory.

There should be a local components directory in the user's profile (see bug 
45701), and the XPCOM initialization code should check this for XPCOM components 
(including XPCOM components that happen to be new plug-ins) and load them, with 
these local XPCOM components taking precedence over any shared ones installed on 
the server (i.e. the user's profile's components directory should be checked 
Depends on: 45701
This is related to the general effort, by me, to create a component search path, 
I think, which I wrote a description on, but I haven't posten on recently.

Is it required to only allow plugins in the local directory, or is this local 
directory a place where any components may be placed?
Given the view that plugins (using the new APIs) are Components. It would seem 
more orthogonal (and I suspect easier on the code ?) if a local per user 
directory was searched for all components.
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
Target Milestone: --- → Future
I currently intend to add support for component search path in nsbeta3, which 
solves a number of problems including this one.
Well, it will not be nsbeta3.
Edward: Welcome to xpcom!
Component: XPCOM Registry → XPCOM
QA Contact: leger → rayw
Target Milestone: Future → mozilla1.0
Once again... attempting to reassign from Ray to Edward.
Assignee: rayw → kandrot
reassign all kandrot xpcom bug.
Assignee: kandrot → dougt
Target Milestone: mozilla1.0 → ---
This is essentially a duplicate of 14923, but I'll mark it a blocker of that
tracking bug so as not to knock off all the people cc'd on this bug.
Blocks: 14923
dan, noble, but I need to clear my bug list.  marking as dup.  

*** This bug has been marked as a duplicate of 14923 ***
Closed: 18 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.