Description of problem: Previously I could add: pref("general.config.filename", "firefox.cfg"); to /usr/lib/firefox-<ver>/greprefs/all.js and it would read /usr/lib/firefox-<ver>/firefox.cfg. Now with xulrunner, I added: pref("general.config.filename", "mozilla.cfg"); to /usr/lib/xulrunner-1.9pre/greprefs/all.js and put mozilla.cfg in both /usr/lib/xulrunner-1.9pre and /usr/lib/firefox-3.0b5 to no avail. I get: "Failed to read the configuration file. Please contact your system administrator." running firefox under strace -f I don't see any attempts to find a file named "mozilla.cfg" anywhere. Version-Release number of selected component (if applicable): xulrunner-1.9-0.53.beta5.fc9.i386
Does about:config list the correct value for your pref? You can debug further with: export NSPR_LOG_FILE=mcd.log export NSPR_LOG_MODULES=MCD:5 prior to starting the browser. In either case, there are zero customizations we are doing here, and an upstream bug should be filed if this turns out to be a bug.
Can't do about:config as browser does not start. mcd.log: -1207834928[8ce9a00]: general.config.filename = mozilla.cfg Isn't it something of a customization that we run firexfox as a xulrunner app? This seems related: https://bugzilla.mozilla.org/show_bug.cgi?id=427927 but not the same symptoms - no error dialogue box. If I download firefox for linux from mozilla.com and do the customization, I don't get the error dialogue. about:config show the proper value for general.config.filename. But the customization doesn't work, like the above bug indicates. But this issue seems to be a Fedora issue.
I'm 100% confident that this is not a Fedora specific bug. In fact, the fact that even the binaries distributed by upstream won't load the files makes it seem that MCD is completely busted upstream and we're just hitting a slightly different symptom of the same problem. But we can try to debug it further before we send upstream... The error message you are seeing at startup is coming from http://lxr.mozilla.org/mozilla/source/extensions/pref/autoconfig/src/nsReadConfig.cpp#141 readConfigFile() is returning an failure code for some reason. Think you could use gdb to step inside readConfigFile() to help figure out what specifically is failing? It is obviously somewhere after http://lxr.mozilla.org/mozilla/source/extensions/pref/autoconfig/src/nsReadConfig.cpp#179 since that is getting PR_LOG'ed for you. I'll also attach a patch you can add locally to your xulrunner spec and rebuild with which will add extra PR_LOG calls to help pinpoint where it's failing.
Created attachment 302395 [details] Add extra PR_LOGing to MCD This will put more info in the log which should help figure out exactly what's failing. Can you create a build with this and see what additional output you can get from the log?
Running through gdb I see that it is failing evaluating prefcalls.js in NS_NewLocalFileInputStream() at rv = in->Init(file, ioFlags, perm, bahaviorFlags); gdb is not working too well though, get lots of "Could not find the frame base for" messages. I'll try to build with your patch.
Curious. That likely means that it can't open() prefcalls.js. strace might shed some light.
It's looking for /usr/lib/firefox-3.0b5/defaults/autoconfig/prefcalls.js, but it's at /usr/lib/xulrunner-1.9pre/defaults/autoconfig/prefcalls.js.
Lovely. And if you create links to where it expects it (both prefcalls.js and platforms.js might need it) and place your file in the same location, does it work?
I put a link to ../../xulrunner-1.9pre/defaults/autoconfig in /usr/lib/firefox-3.0b5/defaults and it comes up. Now just the upstream bug to deal with. Thanks.
This specific problem of looking in the wrong directory has been forwarded upstream at https://bugzilla.mozilla.org/show_bug.cgi?id=429141
Looks like upstream 427927 has been fixed. Hopefully this can make it into F9 as well.
*** Bug 471430 has been marked as a duplicate of this bug. ***