Bug 442406 - Cannot read MCD configuration file
Summary: Cannot read MCD configuration file
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Fedora
Classification: Fedora
Component: xulrunner
Version: rawhide
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Gecko Maintainer
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 471430 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-04-14 17:58 UTC by Orion Poplawski
Modified: 2018-04-11 07:31 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-04-15 15:52:51 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
Add extra PR_LOGing to MCD (6.02 KB, patch)
2008-04-14 21:33 UTC, Christopher Aillon
no flags Details | Diff


Links
System ID Private Priority Status Summary Last Updated
Mozilla Foundation 427927 0 -- VERIFIED AutoConfig doesn't work with Trunk / Firefox 3 2020-02-21 08:57:40 UTC
Mozilla Foundation 429141 0 -- RESOLVED MCD looks in app directory for *.js files; they are installed in gecko directory when building --with-libxul-sdk 2020-02-21 08:57:40 UTC

Description Orion Poplawski 2008-04-14 17:58:06 UTC
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

Comment 1 Christopher Aillon 2008-04-14 18:59:37 UTC
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.

Comment 2 Orion Poplawski 2008-04-14 19:24:49 UTC
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.

Comment 3 Christopher Aillon 2008-04-14 21:32:00 UTC
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.

Comment 4 Christopher Aillon 2008-04-14 21:33:45 UTC
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?

Comment 5 Orion Poplawski 2008-04-14 22:20:04 UTC
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.

Comment 6 Christopher Aillon 2008-04-15 04:02:52 UTC
Curious.  That likely means that it can't open() prefcalls.js.  strace might
shed some light.

Comment 7 Orion Poplawski 2008-04-15 14:29:19 UTC
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.


Comment 8 Christopher Aillon 2008-04-15 14:45:39 UTC
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?

Comment 9 Orion Poplawski 2008-04-15 15:01:14 UTC
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.


Comment 10 Christopher Aillon 2008-04-15 15:52:51 UTC
This specific problem of looking in the wrong directory has been forwarded
upstream at https://bugzilla.mozilla.org/show_bug.cgi?id=429141

Comment 11 Orion Poplawski 2008-04-23 17:18:19 UTC
Looks like upstream 427927 has been fixed.  Hopefully this can make it into F9
as well.

Comment 12 Matěj Cepl 2008-11-16 01:12:39 UTC
*** Bug 471430 has been marked as a duplicate of this bug. ***


Note You need to log in before you can comment on or make changes to this bug.