Closed Bug 83687 Opened 24 years ago Closed 24 years ago

Current Proccess directory is always ignored if |bindir| is passed to InitXPCOM

Categories

(Core :: XPCOM, defect)

defect
Not set
blocker

Tracking

()

RESOLVED FIXED
mozilla0.9.2

People

(Reporter: dougt, Assigned: ccarlen)

References

Details

The problem is that the two strings which we key on are identical: http://lxr.mozilla.org/seamonkey/source/xpcom/io/nsDirectoryServiceDefs.h#40 http://lxr.mozilla.org/seamonkey/source/xpcom/io/nsDirectoryServiceDefs.h#47 One of these defines needs to be renamed.
cvs server: Diffing . Index: nsDirectoryServiceDefs.h =================================================================== RCS file: /cvsroot/mozilla/xpcom/io/nsDirectoryServiceDefs.h,v retrieving revision 1.8 diff -u -r1.8 nsDirectoryServiceDefs.h --- nsDirectoryServiceDefs.h 2001/01/29 23:35:54 1.8 +++ nsDirectoryServiceDefs.h 2001/06/01 18:34:14 @@ -37,7 +37,7 @@ #define NS_XPCOM_INIT_CURRENT_PROCESS_DIR "MozBinD" // Can be used to set NS_XPCOM_CURRENT_PROCESS_DIR // CANNOT be used to GET a location -#define NS_XPCOM_CURRENT_PROCESS_DIR "CurProcD" +#define NS_XPCOM_CURRENT_PROCESS_DIR "XCurProcD" #define NS_XPCOM_COMPONENT_REGISTRY_FILE "ComRegF" #define NS_XPCOM_COMPONENT_DIR "ComsD"
Accepting.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.2
The can be a problem is when an embedding app specifies a dir as the bin dir and this dir is not the same as the current process dir. This has gone unnoticed because, for mozilla and every known embedding app, the two dirs have been the same thing. This will cause no change for mozilla so I'd like to get it in. Adding valeski for r= and jband for sr=.
This patch is essential if you want to use the mozilla RPMs and redefine where chrome or defaults live.
r=valeski
sr=jband I'll get on board. But I'm unsure where one would make use of this distinction. Without some embedding that actaully does this, it seems to me that we're likely to end up with callers that use NS_XPCOM_CURRENT_PROCESS_DIR where they should have used NS_OS_CURRENT_PROCESS_DIR. I'm speculating that we *may* have some components that won't even work right in an environment where the dir retrieved using NS_XPCOM_CURRENT_PROCESS_DIR != the one retrieved using NS_OS_CURRENT_PROCESS_DIR.
Blocks: 83989
a= asa@mozilla.org for checkin to the trunk. (on behalf of drivers)
Fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.