595522 - Omnijar breaks prefs initialized via mozilla.cfg

Status: RESOLVED FIXED

(Core :: Preferences: Backend, defect)

Description

[dickvl]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.9) Gecko/20100824 Firefox/3.6.9
Build Identifier: Mozilla/5.0 (X11; Linux i686; rv:2.0b6pre) Gecko/20100911 Firefox/4.0b6pre

It is no longer possible to use a file local-settings.js in the defaults/pref directory to initialize prefs via mozilla.cfg configuration file in the program directory now that all files and directories have been moved to the omni.jar archive file.

In the past the recommended method was to place a file local-setting.js in the greprefs directory or the defaults/pref to have a solution that survived an update. Before that instruction were to modify all.js, which needed to be repeated after each update.
See http://kb.mozillazine.org/Locking_preferences

Now that first the content of greprefs was moved to the file greprefs.js that only left placing local-settings.js in the defaults/pref directory.
Now that the content of the defaults directory also have been moved to omni.jar it looks that defaults/pref is no longer scanned for a file to specify that mozilla.cfg needs to be read.
So we need new instructions on how to specify that mozilla.cfg needs to be processed for locking and initializing prefs.
The defaults/pref directory is still there with only the channel-prefs.js file.

Modifying greprefs.js in omni.jar (of course not a recommended method) by adding pref("general.config.filename", "mozilla.cfg"); gives "Failed to read the configuration file. Please contact your system administrator.". So that is not working either.

Initializing a new profile via user.js via defaults/profile/user.js still seems to be working (I see user.js in the new profile). But that is only for new profiles and easy to bypass.

Maybe do something similar to the use of override.ini (why the need to use a pref to specify mozilla.cfg?)
http://mxr.mozilla.org/mozilla-central/source/toolkit/xre/nsAppRunner.cpp#2791

A possibility would be to scan for the presence of mozilla.cfg (brandname) and automatically process if found.

This has regressed before (Bug 576430) so we need a reftest for mozilla.cfg to prevent future regressions.

Reproducible: Always

Comment 1

[Michael Wu [:mwu]]

I'm not familiar with the use case here but a possible workaround is to edit defaults/prefs/channel-prefs.js. This is a special pref file which is never changed on updates and is hard coded to be read even with omnijar on.

Comment 2

[dickvl]

Modifying defaults/prefs/channel-prefs.js gives the same "Failed to read the configuration file. Please contact your system administrator." that I posted above , so there is something wrong with either the file name or the general.config.filename isn't processed correctly. Modifying files in this way will always give problems with updating and should be avoided IMO.

I'm on Linux and I don't know how to check which file Firefox is looking for.
On Window it can probably be done with an utility like Filemon from MS Sysinternals.

http://kb.mozillazine.org/Locking_preferences
https://developer.mozilla.org/en/Automatic_Mozilla_Configurator
https://developer.mozilla.org/en/Automatic_Mozilla_Configurator/Locked_config_settings

Comment 3

[Michael Wu [:mwu]]

(In reply to comment #2)
> Modifying defaults/prefs/channel-prefs.js gives the same "Failed to read the
> configuration file. Please contact your system administrator." that I posted
> above , so there is something wrong with either the file name or the
> general.config.filename isn't processed correctly. Modifying files in this way
> will always give problems with updating and should be avoided IMO.
> 
The updater explicitly avoids touching this particular file and has done so for some time now. (Since firefox 1.5? I don't remember) Of course, it's another question whether a linux package manager would do the same.

> I'm on Linux and I don't know how to check which file Firefox is looking for.
> On Window it can probably be done with an utility like Filemon from MS
> Sysinternals.
> 
It's ok. I wrote the code so no need to reverse engineer the answer. Just had a typo in the path. It's defaults/pref/channel-prefs.js in the app directory. For some reason, my distro has it in defaults/preferences/channel-prefs.js but that's probably just because it's an old version of Firefox. Either way, the file should be there normally.

This is interesting though. I suspect it's more than just general.config.filename not being read correctly. You may also need to extract defaults/autoconfig from the omnijar to the gre/app dir to get this to work.

Comment 4

[Robert Strong (they/them - no direct email)]

So, I believe the possible solutions are as follows:

1. use channel-prefs.js - though this worked for me I am concerned about the app update channel getting screwed up and thereby preventing app updates. This will get over written on a pave over install so I highly suspect that some sysadmins won't like this approach.

2. add back the enumeration of just one directory for pref files.

3. add a check for a specific pref file similar to what is done for channel-prefs.js

If 1 isn't acceptable then we'll need this for Firefox 4.0 / Gecko 2.0 so requesting blocking.

Comment 5

[dickvl]

What is with the problem that I get an error alert (Failed to read the
configuration file) if I specify mozilla.cfg via a pref in channel-prefs.js ?

Do I need to file another bug report about that?

There was a similar error that was fixed (2010-08-12) a week before the omnijar change landed (2010-08-18).

See bug 576430

Should that bug be reopened or a new bug filed?

Comment 6

[Robert Strong (they/them - no direct email)]

I tested using channel-prefs.js before making comment #4 and it worked fine. The file used to generate the mozilla.cfg must have a comment at the top and the following worked for me
//
lockPref("network.proxy.type", 2);


I used byteshift 13 using the online configurator ( http://tinyurl.com/2dd74vr ), placed the resultant mozilla.cfg in my install dir, and added pref("general.config.filename", "mozilla.cfg"); to channel-prefs.js

Comment 7

[dickvl]

I can't get it to work with the current nightly build.
The files work fine with the 2010-08-17 build, so I don't know what goes wrong for me.

Mozilla/5.0 (X11; Linux i686; rv:2.0b7pre) Gecko/20100924 Firefox/4.0b7pre

Comment 8

[Robert Strong (they/them - no direct email)]

It works with a local build before packaging so this is quite likely due to omnijar.

Comment 9

[dickvl]

So what would be the line of action for the issue with the "Failed to read" alert ?

1. leave it in this bug
2. file a new bug and leave this bug for specifying general.config.filename
3. reopen bug 576430 - I don't know if it is the same bug, but that bug dealt with the same error message

Comment 10

[Johnathan Nightingale [:johnath]]

My attempt at a better summary, feel free to edit if I've oversimplified. I agree we need a solution to this.

Comment 11

[James Pearson]

I get the same "Failed to read the configuration file. Please contact your system administrator." with the latest beta when tying to use a general.config.filename cfg file.

Running a debug version of the latest Mercurial source, I get:

Assertion failure: cx->compartment != cx->runtime->defaultCompartment, at mozilla-central/js/src/jsapi.cpp:2953

It is failing in JS_NewGlobalObject() called at line 163 in extensions/pref/autoconfig/src/nsJSConfigTriggers.cpp

After having a look in the rest of the code for similar calls, it looks like in other places this has been replaced by JS_NewCompartmentAndGlobalObject() - and again by copying what has been done elsewhere, I've come up with the following patch - that appears to work:

--- ./extensions/pref/autoconfig/src/nsJSConfigTriggers.cpp.dist        2010-12-16 15:35:10.419393000 +0000
+++ ./extensions/pref/autoconfig/src/nsJSConfigTriggers.cpp     2010-12-16 22:12:45.852069353 +0000
@@ -160,13 +160,17 @@ nsresult CentralizedAdminPrefManagerInit
         static_cast<nsIXPCSecurityManager*>(new AutoConfigSecMan());
     xpc->SetSecurityManagerForJSContext(autoconfig_cx, secman, 0);
 
-    autoconfig_glob = JS_NewGlobalObject(autoconfig_cx, &global_class);
+    autoconfig_glob = JS_NewCompartmentAndGlobalObject(autoconfig_cx, &global_class, NULL);
+
     if (autoconfig_glob) {
-        if (JS_InitStandardClasses(autoconfig_cx, autoconfig_glob)) {
-            // XPCONNECT enable this JS context
-            rv = xpc->InitClasses(autoconfig_cx, autoconfig_glob);
-            if (NS_SUCCEEDED(rv)) 
-                return NS_OK;
+       JSAutoEnterCompartment ac;
+       if (ac.enter(autoconfig_cx, autoconfig_glob)) {
+           if (JS_InitStandardClasses(autoconfig_cx, autoconfig_glob)) {
+               // XPCONNECT enable this JS context
+               rv = xpc->InitClasses(autoconfig_cx, autoconfig_glob);
+               if (NS_SUCCEEDED(rv)) 
+                   return NS_OK;
+           }
         }
     }

If this patch is OK, please let me know to whom I should make the review request?

It appears the when code changes to with JS_NewGlobalObject() are made elsewhere, the code in extensions/pref/autoconfig/src/nsJSConfigTriggers.cpp is missed - as this is what appeared to also happen in bug 576430 ???

Comment 12

[James Pearson]

Attachment: Fix "general.config.filename" autoconfiguration failure

Comment 13

[dickvl]

There are two typos in comments (Manger and failue) in that file just above and below that range.
Maybe fix these as well.

http://mxr.mozilla.org/mozilla-central/source/extensions/pref/autoconfig/src/nsJSConfigTriggers.cpp

158     // Create a new Security Manger and set it for the new JS context
173     // failue exit... clean up the JS context

Comment 14

[James Pearson]

I've just come across bug 590325 which appears to fix this issue with a similar patch - however, I'm not sure where that patch got checked in to - as it doesn't appear to be in the firefox source ???

Comment 15

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

That patch got checked into tracemonkey and eventually merged to the mozilla-central tree.

So, is this fixed?

Comment 16

[James Pearson]

I can't see that the patch from bug 590325 has been applied to the mozilla-central source.

I've followed the download instructions at <https://developer.mozilla.org/En/Simple_Firefox_build> - but the file mozilla-central/source/extensions/pref/autoconfig/src/nsJSConfigTriggers.cpp doesn't have that patch applied.

Should I be looking somewhere else?

Comment 17

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

No, you're right, I just assumed that because the bug says it was in the tree it was in the tree ;-)

Comment 18

[Jason Orendorff [:jorendorff]]

Comment on attachment 499297 [details] [diff] [review]
Fix "general.config.filename" autoconfiguration failure

I don't know enough about autoconfig to be able to review this properly. But here are the questions I'd ask.

  - Do we really want a new compartment for autoconfig code? In particular,
    is a new compartment better than using the chrome compartment?
    Assuming the answer is yes, then:

  - We're sure this only gets called once, right?

  - Should this compartment have principals? It could matter if code in
    this compartment uses XPConnect or interacts with objects in other
    compartments.

Removing the review flag. As far as the JSAPI is concerned, everything is correct.

Comment 19

[Jason Orendorff [:jorendorff]]

Actually: It seems to me it would be better to call

  JS_SetGlobalObject(autoconfig_cx, autoconfig_global)

before JS_InitStandardClasses, rather than use a JSAutoEnterCompartment object.

(Ideally even JS_SetGlobalObject shouldn't be necessary, but it seems we have a rogue assertion in JS_InitStandardClasses, sigh.)

Comment 20

[James Pearson]

Do you mean something like this?

--- ./extensions/pref/autoconfig/src/nsJSConfigTriggers.cpp.dist        2010-12-16 15:35:10.419393000 +0000
+++ ./extensions/pref/autoconfig/src/nsJSConfigTriggers.cpp     2011-01-11 15:00:19.902052386 +0000
@@ -160,8 +160,9 @@ nsresult CentralizedAdminPrefManagerInit
         static_cast<nsIXPCSecurityManager*>(new AutoConfigSecMan());
     xpc->SetSecurityManagerForJSContext(autoconfig_cx, secman, 0);
 
-    autoconfig_glob = JS_NewGlobalObject(autoconfig_cx, &global_class);
+    autoconfig_glob = JS_NewCompartmentAndGlobalObject(autoconfig_cx, &global_class, NULL);
     if (autoconfig_glob) {
+        JS_SetGlobalObject(autoconfig_cx, autoconfig_glob);
         if (JS_InitStandardClasses(autoconfig_cx, autoconfig_glob)) {
             // XPCONNECT enable this JS context
             rv = xpc->InitClasses(autoconfig_cx, autoconfig_glob);

This works for me when I have a "general.config.filename" cfg file defined

However, there is still some confusion about the patch in bug 590325 that also fixes this issue that appears to have been merged but has gone 'missing' ?

Comment 21

[Tom Schmidt]

I also used the global preference feature on Linux and Solaris Firefox. This method worked up through the 3.6.X releases, but is broken in Firefox 4.0b9.  FF 4.0b9 ignores my global preferences, which I configured like this in earlier 3.X releases:

defaults/pref/local.js (or greprefs/local.js):
  // Load customized config file to set global preferences
  pref("general.config.obscure_value", 0);
  pref("general.config.filename", "local_prefs.cfg");

local_prefs.cfg:
  // Don't show the Firefox has been upgraded page
  lockPref("browser.startup.homepage_override.mstone", "ignore");
  // Use proxy configuration
  defaultPref("network.proxy.autoconfig_url", "http://htmlprod/pac/proxy.pac");
  defaultPref("network.proxy.type", 2);
  // Don't check for the default browser
  defaultPref("browser.shell.checkDefaultBrowser", false);
  // Disable automatic updates
  lockPref("app.update.enabled", false);


It is not desirable to have to merge global site preferences like this into a jar file, as we have Firefox installed on an NFS filesystem for multiple *NIX machines to access.

Comment 22

[James Pearson]

Looks like this is in the process of being fixed in bug 590325 - a new patch has been checked into the tracemonkey tree and I guess this will make it into the mozilla-central source at some point ???

Comment 23

[Michael Wu [:mwu]]

(In reply to comment #22)
> Looks like this is in the process of being fixed in bug 590325 - a new patch
> has been checked into the tracemonkey tree and I guess this will make it into
> the mozilla-central source at some point ???

Yup, tracemonkey merges with mozilla-central regularly. Tracemonkey does get builds like mozilla-central however, so you can grab a tracemonkey build from ftp and see if your problem is fixed.

Comment 24

[Michael Wu [:mwu]]

There's an additional problem with using mozilla.cfg/general.config.filename and that is that not all js files in defaults/pref are read on default builds. Bug 620931 has a patch to make omnijar builds read all preferences in defaults/pref instead of just channel-prefs.js so the previous way of configuring general.config.filename will keep working. (assuming that the patch lands)

Can someone confirm that this feature works on tracemonkey builds with the general.config.filename pref set in channel-prefs.js? If so, the fix in bug 620931 should be the last thing we need to resolve this bug.

Comment 25

[James Pearson]

The patch from bug 590325 is in now in the mozilla-central tree and now works for me if I create a custom .js file in defaults/pref/ or defaults/preferences/ that defines the general.config.filename cfg file

This is using a debug or release build of the mozilla-central source - not sure if this the same for a 'default' build?

Comment 26

[James Pearson]

However, if I make a package (using "make package") and install that and have my custom .js file in defaults/preferences/, I get "Failed to read the configuration file. Please contact your system administrator."

Is this what bug 620931 is about?

Comment 27

[Michael Wu [:mwu]]

(In reply to comment #26)
> However, if I make a package (using "make package") and install that and have
> my custom .js file in defaults/preferences/, I get "Failed to read the
> configuration file. Please contact your system administrator."
> 
Yeah, I mean the packaged build. Packaging a build changes a bunch of things.

> Is this what bug 620931 is about?

Yeah, sort of. Does it work if you put general.config.filename into channel-prefs.js? (if it doesn't we have another bug to fix)

Comment 28

[James Pearson]

Using a packaged build, it works OK if I copy in the defaults/autoconfig/{platform.js,prefcalls.js} files from the debug/release build to defaults/autoconfig and have my custom .js file in defaults/preferences

i.e. my defaults directory looks like:

defaults/
defaults/preferences
defaults/preferences/custom.js
defaults/pref
defaults/pref/channel-prefs.js
defaults/autoconfig
defaults/autoconfig/platform.js
defaults/autoconfig/prefcalls.js

It also works if I add the contents of my custom.js to channel-prefs.js - but it doesn't work if my custom.js is in defaults/pref/ - it has to be in defaults/preferences/

Comment 29

[Dimas]

The definitive procedure will be documented? The IT administrators like me are following these bugs to know how to keep massive Firefox installations working with centralized config file in FF4. Thx.

Comment 30

[James Pearson]

This is just a workaround ... it obviously needs to be fixed properly.

The platform.js and prefcalls.js files are in the shipped omni.jar, but it looks like the autoconfig code doesn't know how to use these ???

Comment 31

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

(In reply to comment #29)
> The definitive procedure will be documented? The IT administrators like me are
> following these bugs to know how to keep massive Firefox installations working
> with centralized config file in FF4. Thx.

The plan is to put it back the way it was in 3.6, which is why this is a hardblocker.  Whether *that* is documented somewhere I do not know, but it should be.  If it's not, file another bug in Mozilla Developer Network::Documentation Requests.

Comment 32

[Michael Wu [:mwu]]

Attachment: Read defaults/autoconfig/* from omnijar as appropriate

James, can you try this patch? I'd like to know if this patch fixes the need to copy the files in defaults/autoconfig.

Comment 33

[James Pearson]

Yes, that works - as long as my custom.js file is in defaults/preferences/

Should defaults/preferences/ be the correct location to read this file from? i.e. should firefox ship with an empty defaults/preferences/ directory?

Comment 34

[Michael Wu [:mwu]]

Attachment: Read defaults/autoconfig/* from omnijar as appropriate, v2

This makes the autoconfig code read from resource://gre/defaults/autoconfig/ when necessary. The passing of uris as the filename seems slightly sketchy to me, but it always did that so I don't think I'm making it any worse.

Comment 35

[Michael Wu [:mwu]]

(In reply to comment #33)
> Yes, that works - as long as my custom.js file is in defaults/preferences/
> 
> Should defaults/preferences/ be the correct location to read this file from?
> i.e. should firefox ship with an empty defaults/preferences/ directory?

I'll investigate that next, though I suspect defaults/pref should be the right place.

Comment 36

[Don Kleppinger]

I logged Bug 630278 Setting autoadmin.global_config_url does not cause .cfg file to be loaded from server.  Not sure if this is related.

Comment 37

[Jez]

CCing self.

Comment 38

[Don Kleppinger]

To temporarily work around this I am putting the content of my mozilla.cfg file into channel-prefs.js.  The problem I am having is that there seems to be javascript security that prevent using any variable or calculation to create a string.
i.e.this works 
pref("extensions.test.version", "6.0");

but this doesn't 
var testVersion = "6.0";
pref("extensions.test.version", testVersion);

We have a custom .cfg that we currently use with FF3.6 that contains a bunch of javascript.   When this bug gets fixed will I have the same issue with using javascript within the mozilla.cfg file on FF4?

Comment 39

[Dave Townsend [:mossop]]

The preferences files are not run as JS, they just look like it.

Comment 40

[Don Kleppinger]

But the Mozilla.cfg file (or file defined by general.config.filename) will continue to be run a JS, as it was in 3.6?

Comment 41

[Michael Wu [:mwu]]

(In reply to comment #40)
> But the Mozilla.cfg file (or file defined by general.config.filename) will
> continue to be run a JS, as it was in 3.6?

Yes, mozilla.cfg/general.config.filename is run as JS in 4.0 too.

Comment 42

[Jez]

Are you allowed to lockPref() in channel-prefs.js?  I'd always though pref locking was limited to mozilla.cfg?

Comment 43

[Mike Hommey [:glandium]]

(In reply to comment #42)
> Are you allowed to lockPref() in channel-prefs.js?  I'd always though pref
> locking was limited to mozilla.cfg?

You can't, unless bug 440908 is accepted.

Comment 44

[Jez]

Hmm.  So can you at least specify general.config.filename in channel-prefs.js?  :-)

Comment 45

[James Pearson]

(In reply to comment #44)
> Hmm.  So can you at least specify general.config.filename in channel-prefs.js? 
> :-)

Yes, it also works if you have the general.config.filename settings in any .js file in the defaults/preferences/ directory

Comment 46

[Benjamin Smedberg]

Comment on attachment 507565 [details] [diff] [review]
Read defaults/autoconfig/* from omnijar as appropriate, v2

I'm a bit confused about the conversation in this bug. We don't expect configs to be placed inside the omnijar ever, do we? That doesn't make much sense. The config files should always be outside the omnijar. But I can't really tell from this patch what is actually being implemented.

The "location" munging you're doing makes me cringe a little bit. Can we just put the filename in, and not pretend it's a URI? If you really wanted to construct a URI, you should use NS_GetURISpecFromFile. The location is just used for JS error messages, I'm pretty certain.

We really really need a test for this. A mozmill or litmus test.

Comment 47

[Mike Hommey [:glandium]]

(In reply to comment #46)
> Comment on attachment 507565 [details] [diff] [review]
> Read defaults/autoconfig/* from omnijar as appropriate, v2
> 
> I'm a bit confused about the conversation in this bug. We don't expect configs
> to be placed inside the omnijar ever, do we? That doesn't make much sense. The
> config files should always be outside the omnijar. But I can't really tell from
> this patch what is actually being implemented.

All preferences except channel-prefs.js are in omnijar today.

> The "location" munging you're doing makes me cringe a little bit. Can we just
> put the filename in, and not pretend it's a URI? If you really wanted to
> construct a URI, you should use NS_GetURISpecFromFile. The location is just
> used for JS error messages, I'm pretty certain.

I don't understand what you're talking about here.

Comment 48

[Tom Schmidt]

I tried the Solaris 10 4.0b10 build with a custom .js file in defaults/preferences directory.  Firefox core dumps if a .js file exists in defaults/preferences.  It also core dumps if I add these lines to the defaults/pref/channel-prefs.js file:

// Load customized config file to set global preferences
pref("general.config.obscure_value", 0);
pref("general.config.filename", "local_prefs.cfg");

This same procedure worked with Firefox 3.6.X and earlier on Solaris, but does not work on Firefox 4.0b9 or 4.0b10.  It does not appear to be fixed yet as claimed above.  See my Comment 21 above for more details on why we need to have this functionality.

Comment 49

[Mike Hommey [:glandium]]

(In reply to comment #47)
(...)
> All preferences except channel-prefs.js are in omnijar today.
(...)
> I don't understand what you're talking about here.

Forget it, I thought it was another bug.

Comment 50

[Jez]

(In reply to comment #45)
> (In reply to comment #44)
> > Hmm.  So can you at least specify general.config.filename in channel-prefs.js? 
> > :-)
> 
> Yes, it also works if you have the general.config.filename settings in any .js
> file in the defaults/preferences/ directory

Looks like channel-prefs.js saves the day in terms of a temporary workaround, then.  I'll try to lock some prefs tonight and report on the result.

Comment 51

[Don Kleppinger]

It doesn't work for me on windows with Firefox/4.0b10.  Firefox crashes

Comment 52

[Michael Wu [:mwu]]

(In reply to comment #46)
> Comment on attachment 507565 [details] [diff] [review]
> Read defaults/autoconfig/* from omnijar as appropriate, v2
> 
> I'm a bit confused about the conversation in this bug. We don't expect configs
> to be placed inside the omnijar ever, do we? That doesn't make much sense. The
> config files should always be outside the omnijar. But I can't really tell from
> this patch what is actually being implemented.
> 
The configurations are outside of omnijar of course, but there are two js files which are loaded prior to loading the config files. These files act like libraries for the config files so they can set/lock prefs without having to know what xpcom is. These files are currently in the omnijar, and this patch makes it possible to read them.

There are two pathways in the code - one for loading the "library" js files, and another for loading the user configuration. isBinDir == true when loading the user configuration, isBinDir == false when loading the "library" files.

> The "location" munging you're doing makes me cringe a little bit. Can we just
> put the filename in, and not pretend it's a URI? If you really wanted to
> construct a URI, you should use NS_GetURISpecFromFile. The location is just
> used for JS error messages, I'm pretty certain.
> 
Alright. The previous code used a URI and I was just maintaining things as is. Just putting in the filename is fine with me.

Comment 53

[Jez]

(In reply to comment #50)
> (In reply to comment #45)
> > (In reply to comment #44)
> > > Hmm.  So can you at least specify general.config.filename in channel-prefs.js? 
> > > :-)
> > 
> > Yes, it also works if you have the general.config.filename settings in any .js
> > file in the defaults/preferences/ directory
> 
> Looks like channel-prefs.js saves the day in terms of a temporary workaround,
> then.  I'll try to lock some prefs tonight and report on the result.

Erm, no, it doesn't work, because if you do that you get the good old error message,
"Failed to read the configuration file. Please contact your system administrator."

So much for that workaround.

Comment 54

[James Pearson]

(In reply to comment #51)
> It doesn't work for me on windows with Firefox/4.0b10.  Firefox crashes

I get the same with 4.0b10 on Linux ...

If I run 'unzip -l omni.jar' on the omni.jar shipped with 4.0b10 on Linux, I get:

warning [omni.jar]:  3388343 extra bytes at beginning or within zipfile
  (attempting to process anyway)

I don't get this warning with the latest nightly build - may be there is corruption with 4.0b10 ???


However, the latest nightly build works OK for me using the work around given in comment 28

You can extract the defaults/autoconfig files from omni.jar (from the nightly build) on Linux by doing:

unzip omni.jar 'defaults/autoconfig/*'

Comment 55

[Don Kleppinger]

I tried that and it adds the general.config.filename preference and will start if that .cfg file exists but it doesn't appear to run the.cfg file. No preferences from that file get set.

Comment 56

[Michael Wu [:mwu]]

http://hg.mozilla.org/mozilla-central/rev/5212ab4ae808

Comment 57

[Jez]

(In reply to comment #56)
> http://hg.mozilla.org/mozilla-central/rev/5212ab4ae808

Can't quite understand the effect of the code changes.  Does this now let us have a mozilla.cfg file in the same dir as firefox.exe, as we could before?

Comment 58

[Michael Wu [:mwu]]

(In reply to comment #57)
> (In reply to comment #56)
> > http://hg.mozilla.org/mozilla-central/rev/5212ab4ae808
> 
> Can't quite understand the effect of the code changes.  Does this now let us
> have a mozilla.cfg file in the same dir as firefox.exe, as we could before?

This fixed a bug that prevented the code from loading mozilla.cfg when general.config.filename is set.

Comment 59

[Michael Wu [:mwu]]

Attachment: Enumerate all prefs in defaults/preferences

Alright, here's one option. This makes the defaults/pref directory get enumerated for pref files regardless of whether we're using omnijar. The other patch in bug 620931 also does this, so if we want to take that patch, this one can be dropped.

Comment 60

[Jez]

(In reply to comment #59)
> Created attachment 509297 [details] [diff] [review]
> Enumerate all prefs in defaults/preferences
> 
> Alright, here's one option. This makes the defaults/pref directory get
> enumerated for pref files regardless of whether we're using omnijar. The other
> patch in bug 620931 also does this, so if we want to take that patch, this one
> can be dropped.

But with the current nightly, you can (as a temporary workaround) just put them in channel-prefs.js, right?

Comment 61

[Don Kleppinger]

I need to be able to run javascript in the .cfg file (if then else logic).  The pref js files only let you have pref(...,...) statements. Bug 630278 is also critical for me which may have the same root cause.

Comment 62

[James Pearson]

(In reply to comment #61)
> I need to be able to run javascript in the .cfg file (if then else logic).

You can run javascript in the .cfg file - well it works for me.

This is what I've just done:

Downloaded the latest nightly build (for Linux 32 bit) via <http://nightly.mozilla.org/> - this is dated 2nd Feb, so does not have the patch applied from comment 56 - so we need a workaround ...

So, I extracted the files and at the top level of the install ran:

 unzip omni.jar 'defaults/autoconfig/*'

i.e. extracted the files defaults/autoconfig/prefcalls.js and defaults/autoconfig/platform.js

Then created a custom.cfg file at the top level that contains:

// first line is skipped
var me = getenv("USER");
if (me == "james-p") {
    pref("this.is.me", me);
} else {
    pref("something.else", true);
}

and then added to the file defaults/pref/channel-prefs.js:

pref("general.config.obscure_value", 0);
pref("general.config.filename", "custom.cfg");

Started firefox with a new profile, went to the "about:config" page and typed in 'this' as the filter and got:

 this.is.me             user set    string    james-p


Hopefully, the next nightly builds (3rd Feb) will have the patch applied from comment 56, so with subsequent nightly builds, the files in defaults/autoconfig/ will not be needed.

However, until the patch in attachment 509297 [details] [diff] [review] is applied (or the patch from bug 620931), the general.config.filename settings need to be in the channel-prefs.js file, or in a custom .js file under defaults/preferences/ (which does not exist by default)

Comment 63

[Don Kleppinger]

I didn't realized it ignored the first line and had a one line test file but it's working for me now.  Thanks

Comment 64

[James Pearson]

(In reply to comment #59)
> Created attachment 509297 [details] [diff] [review]
> Enumerate all prefs in defaults/preferences

Shouldn't that be 'Enumerate all prefs in defaults/pref' ?

The patch works for me when I put a custom .js file in defaults/pref/

Comment 65

[Don Kleppinger]

James, the patch seems to have fixed  Bug 630278 as well autoadmin.global_config_url now gets loaded on startup.


unzipping omni.jar 'defaults/autoconfig/*' still doesn't make 4.0b10 work

Can I pull something out of the daily build and add it to 4.0b10 to make it work?  Any idea when this will it to a beta release?

Comment 66

[James Pearson]

(In reply to comment #65)
> unzipping omni.jar 'defaults/autoconfig/*' still doesn't make 4.0b10 work
> 
> Can I pull something out of the daily build and add it to 4.0b10 to make it
> work?  Any idea when this will it to a beta release?

It looks like 4.0b10 was built from source dated 22 Jan - which was before the patch from bug 590325 was committed - so none of workarounds given here will work with 4.0b10 ...

Comment 68

[Mitchell Field [:Mitch]]

(In reply to comment #59)
> Created attachment 509297 [details] [diff] [review]
> Enumerate all prefs in defaults/preferences

Drive-by review comment here; drop the BeOS and VMS parts. Building for those platforms is unsupported.

Comment 69

[Michael Wu [:mwu]]

http://hg.mozilla.org/mozilla-central/rev/fb3786a7d988

Comment 70

[Tom Schmidt]

I just tried 4.0b11 for Solaris 10 SPARC.  It no longer core dumps like it did with 4.0b9 and 4.0b10 when I have a custom.js file in defaults/preferences, but it does not work either.  I now get the popup window stating "Failed to read the configuration file. Please contact your system administrator."  Using truss shows it open my defaults/preferences/custom.js file, but it never opens the custom.cfg file defined by the general.config.filename entry.

defaults/preferences/custom.js:
// global preferences set in customized config file
pref("general.config.obscure_value", 0);
pref("general.config.filename", "custom.cfg");

Why is this so hard to fix???

Comment 71

[Don Kleppinger]

I get the same results on windows.  Is the fix slated for beta 12?

Comment 72

[Michael Wu [:mwu]]

(In reply to comment #70)
> I just tried 4.0b11 for Solaris 10 SPARC.

4.0b11 does not have the fix. b12 will. This fix landed after branching for b11.

Comment 73

[James Pearson]

(In reply to comment #70)
>
> Why is this so hard to fix???

You should be able to get b11 to work by extracting the defaults/autoconfig files from omni.jar - see comment 62

Comment 74

[Don Kleppinger]

Sort of, it loads the config and retrieves the config file defined in  autoadmin.global_config_url from the server but after about 15-30 seconds or so the browser crashes.

Faulting module name: xul.dll, version: 2.0.0.4051, time stamp: 0x4d4b4ddb
Exception code: 0xc0000005
Fault offset: 0x001148d9

Comment 75

[Don Kleppinger]

I discovered the cause of the browser crash when I set autoadmin.global_config_url
It's caused by the fact that the config file at that url is starting a timer. I've opened bug 636873 for that.

Comment 76

[Dimas]

Before FF4 my all.js file with auto-configuration settings were in greprefs folder. With FF4b12 this is not working, but it does in the folder \defaults\pref. It's that change the expected behavior?

Sorry, I don't know where to write about it.

Comment 77

[James Pearson]

(In reply to comment #76)
> Before FF4 my all.js file with auto-configuration settings were in greprefs
> folder. With FF4b12 this is not working, but it does in the folder
> \defaults\pref. It's that change the expected behavior?

Having a custom .js file in defaults/pref also works with Firefox 3.x - the fixes in this bug make auto-configuration with Firefox 4.x work in a similar way to earlier versions.

As greprefs/all.js no longer exists, I guess that method is no longer supported.