(This bug imported from BugSplat, Netscape's internal bugsystem. It was known there as bug #87812 http://scopus.netscape.com/bugsplat/show_bug.cgi?id=87812 Imported into Bugzilla on 02/11/99 19:39) Looks like the global mailcap and mime-type files are hardcoded to /usr/local/lib/netscape/* in libpref, we should change this to also look in $MOZILLA_HOME.

How 'bout this one, chris? I don't know how prefs r working in new world.

slamm/don, who's doing prefs on Unix?

per leger, assigning QA contacts to all open bugs without QA contacts according to list at http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser

Re-assigned to hshaw@netscape.com and changed component to libPref. Hubie, this looks like a libpref issue.

We're about to switch to MOZILLA_FIVE_HOME and .mozilla instead of MOZILLA_HOME and .netscape: http://bugzilla.mozilla.org/show_bug.cgi?id=3554

It is not hard-coded in the pref code. A default is provided in mozilla/modules/libpref/src/unix/unix.js The consumer is free to change the default value without my intervention. They should inform the Doc writer for our preferences, Tina Ornduff x4756 Reassigning to Don.

What happens if the default is not found? This is requiring the user to figure this out. I believe this was a user request to also search $MOZILLA_FIVE_HOME for these files.

I was not able to locate specific code in prefs which reads in mailcap and mime-type files. Though I could be wrong, I believe the files are read in outside of prefs. I couldn't locate the code in prefs or profiles which did the reading. I was trying to convey the component which does the reading was not prefs, not that the default pref should satisfy this bug.

This is not a libpref bug. The problem is a casual usage of these two particular prefs, and arguably this belongs to the apprunner folks.

Re-assigned to slamm@netscape.com, set target milestone to M7, and chnaged priority to P5. Steve, can you _eventually_ make some sense of this bug?

This is not a big deal. Let's move this out to M11 for now.

Since mcafee has such a long history with this bug, I thought he might like to own it again now that he is back in our group.

M15.

Move to M16 for now ...

qa to shrir

http://lxr.mozilla.org/seamonkey/source/modules/libpref/src/unix/unix.js#72 hrm, Component: Tracking? i've never met that. So this is futured, the relevant lines would seem to affect Linux/Unix. Changing OS, adding helpwanted per future. Does this really deserve P5? If we want people to use $MOZILLA_FIVE_HOME I think we should consider having it supported by nsbeta3.

nav triage team: nsbeta3-, need info We need an end user scenario why this would be a problem. Not seeing a frequent scenario, so marking minus. If you disagree, give the end user reason and remove the -.

Is bug 52441 a dup of this?

52441 is a cleaner summary of this bug and is assigned to the right person I think, marking dup. *** This bug has been marked as a duplicate of 52441 ***

verif

I disagree that this bug is a duplicate of bug #52441. I believe there two separate problems: 1) Mozilla does not read the mailcap and mime-types files that unix.js points to. 2) unix.js points to the wrong directory. bug #52441 describes problem (1). This bug describes problem (2) and would become relevant as soon as bug #52441 is fixed. BTW, I believe that the correct location to look for the global files would be /etc since these files are normallly in /etc. And since they are normally _not_ distributed with Mozilla or Netscape, it's meaningless to look in either /usr/local/lib/netscape/ or $MOZ_FIVE_HOME