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).

spam: in my testing realm, so reassigning qa contact to me, en masse.

Changing tfv to M15

Moving all libPref component bugs to new Preferences: Backend component. libPref component will be deleted.

prefs to mcafee

argh... didn't work the last time. pardon the spam. ->mcafee

dveditz

It's actually viewer that creates this file, probably because it knows nothing about profiles.

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.

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.

I think Brian owns prefs now. I know I don't

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.

Changing platform

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.

okay, v.