Viewer creates a file called 'default_prefs.js' in the application directory

VERIFIED WONTFIX

Status

SeaMonkey
Preferences
P3
normal
VERIFIED WONTFIX
19 years ago
14 years ago

People

(Reporter: Simon Fraser, Assigned: Brian Nesse (gone))

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

19 years ago
When I run mozilla, at some point it creates a file called 'default_prefs.js' in
the appliction directory. Such a file at this level is unsightly; it should
either not be there at all, or is should be placed in a subfolder (like defaults/
prefs).

Updated

19 years ago
Status: NEW → ASSIGNED
Target Milestone: M13

Updated

19 years ago
Target Milestone: M13 → M14
QA Contact: paulmac → sairuh
spam: in my testing realm, so reassigning qa contact to me, en masse.

Comment 2

19 years ago
Changing tfv to M15
Target Milestone: M14 → M15

Comment 3

19 years ago
Moving all libPref component bugs to new Preferences: Backend component.  
libPref component will be deleted.
Component: libPref → Preferences: Backend

Updated

18 years ago
Target Milestone: M15 → M17

Updated

18 years ago
Target Milestone: M17 → M18

Comment 4

18 years ago
prefs to mcafee
Status: ASSIGNED → NEW
Target Milestone: M18 → ---

Comment 5

18 years ago
argh... didn't work the last time. pardon the spam. ->mcafee
Assignee: neeti → mcafee
Component: Preferences: Backend → Preferences

Comment 6

18 years ago
dveditz
Assignee: mcafee → dveditz
(Reporter)

Comment 7

18 years ago
It's actually viewer that creates this file, probably because it knows nothing 
about profiles.
Summary: Mozilla creates a file called 'default_prefs.js' in the application directory → Viewer creates a file called 'default_prefs.js' in the application directory

Comment 8

18 years ago
It seems that when the prefs.js file can not be created
Mozilla won't start. I'm seeing this problem on Solaris
and zh, zh.GBK locales.

It's interesting that when the locale is zh or zh.GBK,
Mozilla seems to try to create the file. But when fails,
Mozilla won't start.

Updated

18 years ago
Blocks: 60916

Comment 9

18 years ago
It seems that default_prefs.js will be created when creating user's
profile directory fails. In zh and zh.GBK, the converters have problems
so the profile directory could not be created.

http://bugzilla.mozilla.org/show_bug.cgi?id=60823

It's converter bugs. This bug itself does not block the exact
problem on Solaris. So I'll remove 60916 from block field.
No longer blocks: 60916
I think Brian owns prefs now. I know I don't
Assignee: dveditz → bnesse
(Assignee)

Comment 11

17 years ago
The code that causes this is in useDefaultPrefFile() a shortened version is below:

{
// Anything which calls NS_InitXPCOM will have this
rv = NS_GetSpecialDirectory(NS_APP_PREFS_50_FILE, getter_AddRefs(aFile));

if (!aFile) {
  // We know we have XPCOM directory services, but we might not have a provider
  // which knows about NS_APP_PREFS_50_FILE. Put the file in
  // NS_XPCOM_CURRENT_PROCESS_DIR.
  rv = NS_GetSpecialDirectory(NS_XPCOM_CURRENT_PROCESS_DIR,
                              getter_AddRefs(aFile));
  if (NS_FAILED(rv)) return rv;
  rv = aFile->Append("default_prefs.js");
  if (NS_FAILED(rv)) return rv;
}

It looks to me like some kind of a fallback position for embedding, but that's
just a guess.

It does strike me as odd that a file is created though. As far as I can tell
nsIFile::Append() shouldn't cause a file to be created.

Comment 12

17 years ago
Changing platform
Hardware: All → Macintosh

Updated

17 years ago
OS: Mac System 8.5 → All
Hardware: Macintosh → All
(Assignee)

Comment 13

17 years ago
This is working as it was designed to. After failing to find the preferred
directory, the code falls back to a known location (the application directory.)
After reviewing the list of potential fallback candidates it seems like
NS_XPCOM_CURRENT_PROCESS_DIR is a pretty reasonable solution to me.
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → WONTFIX
okay, v.
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.