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
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 last).
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?
Status: NEW → ASSIGNED
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!
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!
Status: ASSIGNED → NEW
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.
dan, noble, but I need to clear my bug list. marking as dup. *** This bug has been marked as a duplicate of 14923 ***
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.