Closed Bug 790905 Opened 7 years ago Closed 7 years ago

Processing the mozilla.cfg file fails if the file contains JavaScript: "Failed to read the configuration file"

Categories

(Core :: XPConnect, defect)

18 Branch
x86
All
defect
Not set

Tracking

()

RESOLVED FIXED
mozilla18
Tracking Status
firefox18 + fixed

People

(Reporter: bugdickvl, Unassigned)

References

Details

(Keywords: regression)

Attachments

(4 files)

I use a mozilla.cfg file to add some information about the current profile to the prefs.js file for backup purposes and set some default prefs.

That is done by adding some JavaScript to the mozilla.cfg file to get the profile location and the user account name.

//
const {classes:Cc,interfaces:Ci} = Components;
envUN = Cc["@mozilla.org/process/environment;1"].getService(Ci.nsIEnvironment).get("USERNAME");
profD = Cc["@mozilla.org/file/directory_service;1"].getService(Ci.nsIProperties).get("ProfD", Ci.nsIFile).path;

pref("profile-info.username", envUN);
pref("profile-info.profD", profD);

pref("browser.startup.homepage", "about:about");
pref("browser.newtab.url", "about:blank");

I get a "Failed to read the configuration file. Please contact your system administrator." error and Firefox doesn't start.
It works if I comment out the first lines and only leave the last two.

This still worked in the  20120911030553 (96287ad60bef) build.
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2012-09-10-03-05-24-mozilla-central/
No longer works in the 20120911140351 (fdfaef738a00) build.
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2012-09-11-14-03-51-mozilla-central/

Regression range (it is a big one 2039 entries, so I haven't checked it):
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=96287ad60bef&tochange=fdfaef738a00
Regression window(m-c)
Good:
http://hg.mozilla.org/mozilla-central/rev/96287ad60bef
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/18.0 Firefox/18.0 ID:20120910183953
Bad:
http://hg.mozilla.org/mozilla-central/rev/d042ad078f43
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/18.0 Firefox/18.0 ID:20120911065552
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=96287ad60bef&tochange=d042ad078f43


Regression window(m-i)
Good:
http://hg.mozilla.org/integration/mozilla-inbound/rev/c8e5053af5ad
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/18.0 Firefox/18.0 ID:20120911004454
Bad:
http://hg.mozilla.org/integration/mozilla-inbound/rev/4f5b4f0ecf01
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/18.0 Firefox/18.0 ID:20120911010554
Pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=c8e5053af5ad&tochange=4f5b4f0ecf01
Blocks: 788914
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression
Component: Preferences → XPConnect
Product: Firefox → Core
Version: unspecified → 18 Branch
In local build,
Last good:382dce79a998
First bad: 1cef36c730eb
Hm, just setting general.config.obscure_value and general.config.filename doesn't seem to cause anything to happen. According to gdb, nsReadConfig::Init is never called (so the observer doesn't get registered). Do I need an extension or something to make this stuff work?
Attached file local-settings.js
No need add-on.

STR
1. Install Firfox to "Installation directory"
2. Copy mozilla.cfg to Installation directory/mozilla.cfg
   Copy local-settings.js to Installation directory/defaults/pref/local-settings.js
3. Start Firefox
Looks like the fix in bug 776490 wasn't quite right, but continued to work because of dynamic UniversalXPConnect checks, which are now gone. Patch coming up.
Blocks: 776490
This would have caught this bug.
Attachment #661205 - Flags: review?(luke)
defaultPref has been broken all along as well. Any chance this will fix that?

https://bugzilla.mozilla.org/show_bug.cgi?id=786875

Also, this will obviously have to be backported to at least 17.
(In reply to Michael Kaply (mkaply) from comment #8)
> defaultPref has been broken all along as well. Any chance this will fix that?

I'm really not sure. It's sort of an accident that the patch in bug 776490 worked, so it might not have covered all the cases.

> Also, this will obviously have to be backported to at least 17.

Well, I believe this only broke in 18, right? Though I'm fine to backport this for correctness' sake (especially if it fixes defaultPref).
Comment on attachment 661204 [details] [diff] [review]
Make the compartment principal of autoconfig_glob match the principal passed to JS::Evaluate. v1

r=me
Attachment #661204 - Flags: review?(bzbarsky) → review+
Comment on attachment 661205 [details] [diff] [review]
Replace no-op principal check with something real. v1

Can we just remove options.principals then?  It seems like it only exists to be gotten wrong.
(In reply to Luke Wagner [:luke] from comment #11)
> Comment on attachment 661205 [details] [diff] [review]
> Replace no-op principal check with something real. v1
> 
> Can we just remove options.principals then?  It seems like it only exists to
> be gotten wrong.

Eventually yes - I plan to gut a bunch of obsolete security stuff from the js-engine. But at the moment that's more surgery than I'd like to do right now, and I'd like to just land this to ensure that, at the very least, the consumers aren't getting the wrong thing here.
Comment on attachment 661205 [details] [diff] [review]
Replace no-op principal check with something real. v1

Excellent.
Attachment #661205 - Flags: review?(luke) → review+
Looks green, modulo one make-check jsapi-test that I fixed. Luke, I took the liberty of carrying over your review on that one: https://hg.mozilla.org/integration/mozilla-inbound/rev/acec40170961#l1.42 - I hope that's ok?

Pushed to inbound:
remote:   https://hg.mozilla.org/integration/mozilla-inbound/rev/ef528ae38f04
remote:   https://hg.mozilla.org/integration/mozilla-inbound/rev/acec40170961
https://hg.mozilla.org/mozilla-central/rev/ef528ae38f04
https://hg.mozilla.org/mozilla-central/rev/acec40170961
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla18
Fine by me.

So are JS_(Get|Set)FrameAnnotation going away now?  If so, don't forget to zap StackFrame::annotation_ and HAS_ANNOTATION or file a bug on me to do so.
This will need to make Firefox 17 as well so it is in the ESR
Can we get a try build so that mkaply can help us confirm this is fixed.
(In reply to Michael Kaply (mkaply) from comment #18)
> This will need to make Firefox 17 as well so it is in the ESR

Is it actually broken on 17? I thought that the dynamic UniversalXPConnect checks were saving us there. Anyhow, happy to backport it just to be safe.
(In reply to Michael Kaply (mkaply) from comment #18)
> This will need to make Firefox 17 as well so it is in the ESR

mkaply - are you definitely hitting this bug on FF17? We can hold on a try build until that's confirmed.
It looks like we are good on Firefox 17.
You need to log in before you can comment on or make changes to this bug.