71465 - nsDirectoryService should support "Essential Files"

Status: RESOLVED WONTFIX

(Core :: XPCOM, defect, P2)

Description

[Brian Nesse (gone)]

There are currently a couple of places in the codebase with code similar to:
rv = NE_GetSpecialDirectory(NS_XPCOM_CURRENT_PROCESS_DIR, aFile);
#ifdef XP_MAC
aFile->Append("Essential Files");
#endif

This is a hack and is totally non-localizable.

One potential method for fixing this would be to add a Mac specific property to 
nsDirectoryService which would return a pointer to the appropriate place, giving 
us code more like:
#ifdef XP_MAC
rv = NE_GetSpecialDirectory(NS_XPCOM_ESSENTIAL_FILES_DIR, aFile);
#else
rv = NE_GetSpecialDirectory(NS_XPCOM_CURRENT_PROCESS_DIR, aFile);
#endif

Comment 1

[Steve Dagley]

Adding Conrad to the cc: list

Comment 2

[Conrad Carlen (not reading bugmail)]

I agree. And it's easy enough. It should be XP so that the #ifdef is not needed.
Essentially, that dir is the "DLLs linked by the OS" dir. On other platforms, it
is the same as the bin dir. BTW - what code is looking for that location? Should
it be in the first place?

Comment 3

[Brian Nesse (gone)]

Yeah, an XP define would be even better if it did the right thing. The 
preferences code is looking there for preferences file(s), and the 
"ScriptSecurityManager" looks like it is looking for certificates there. The 
installer also references the directory, but it doesn't seem to be doing it in 
the same way...

Comment 4

[Conrad Carlen (not reading bugmail)]

> The preferences code is looking there for preferences file(s)
Is this right? Why would it be looking there? I'll have to check this out
> the "ScriptSecurityManager" looks like it is looking for certificates there.
Hmm, I'll have to look at this. It seems wrong. It seems that these files should
be on a per user basis in NS_APP_USER_PROFILE_50_DIR, and if these files are
indeed global to all users they should be in NS_APP_APPLICATION_REGISTRY_DIR
> The installer also references the directory
This seems like about the only thing that should be looking there.

Comment 5

[Brian Nesse (gone)]

>> The preferences code is looking there for preferences file(s)
> Is this right? Why would it be looking there? I'll have to check this out
Actually it is looking for the "netscape.cfg" or "Mozilla.cfg" file here, not 
just any old prefs file.

Comment 6

[Marek Z. Jeziorek]

Setting target milestone to 0.9.2 (check it in anytime, even before, when the
tree is open for). Per PDT triage.

Comment 7

[Jussi-Pekka Mantere]

Moving to P2, 0.9.3.

Comment 8

[Cindy Roberts]

Marking nsbranch- as it was decided in the August bug triage that we wouldn't
have enough time in eMojo to fix this.  Let's revisit for MachV.

Comment 9

[elaineking]

removed keyword nsbranch since it now has nsbranch-, per pdt mtg.

Comment 10

[Michele Carlson]

cc. yxia 

Comment 11

[Ying-Lin Xia]

Is there any reason to localize this folder name? If so, we may have more this 
kind of stuff, like:
    #define SEARCH_DIR_NAME "Search Plugins"

Comment 12

[selmer (gone)]

No relavent activity in this bug since it was targeted at 096.  Resetting target
milestone, please update it when you get back to this bug.

Comment 13

[Ying-Lin Xia]

I just wondering if it's valid l12y bug or not. Our l10n group is reviewing all 
l12y bugs.

Comment 14

[Steve Dagley]

Ying-Lin, Um, what does l12y mean?  And any decision on if this is a l12y issue?  
And is the "Essential Files" folder name ever localized?  I'm guessing it's not 
since we have it hardcoded (as well as the "Components" folder name) 

Comment 15

[Ying-Lin Xia]

l12y=localizability, for this folder name, we never localize it before, and I 
don't see any reason to localize this folder name from localization point.

Comment 16

[Steve Dagley]

Doh!  I guessed that but mistakenly counted the l and y coming up with 14 
characters.  Thanks for the word on the non-l10n for that folder.

Comment 17

[Peter Trudelle]

nsbeta1-, per ADT triage team

Comment 18

[Steve Dagley]

Since this directory is never localized moving out past 1.0

Comment 19

[Steve Dagley]

Putting on Mozilla1.2 radar since I was wandering around in the
nsDirectoryService code while looking at a Chimera bug and it reminded me I had
this bug in my future list

Comment 20

[Brian Nesse (gone)]

With OS 9 going away, and the OS X build being packaged, I'm wondering if we
shouldn't just eliminate "Essential Files" and let the OS X build be the same as
Windows/Linux.

Comment 21

[Conrad Carlen (not reading bugmail)]

> With OS 9 going away, and the OS X build being packaged

I like that idea. The additional problem with "Essential Files" is that it
requires an alias to the "Essential Files" dir be present in the 'cfrg'
resource. It's another one of those annoying little details an app has to deal
with when embedding us. If shared libs are in the same dir as the app, that
wouldn't be needed :-)

Comment 22

[Steve Dagley]

WONTFIX per Brian & Conrad's feedback

Comment 23

[Brian Nesse (gone)]

See! Proof that if you wait long enough any bug will work itself out. :)

Me thinks that a new bug may be in order... "Remove support for Essential Files
folder from non-Carbon builds"

Comment 24

[Brian Nesse (gone)]

er, make that "from carbon builds"...