Closed
Bug 790905
Opened 13 years ago
Closed 13 years ago
Processing the mozilla.cfg file fails if the file contains JavaScript: "Failed to read the configuration file"
Categories
(Core :: XPConnect, defect)
Tracking
()
RESOLVED
FIXED
mozilla18
People
(Reporter: bugdickvl, Unassigned)
References
Details
(Keywords: regression)
Attachments
(4 files)
754 bytes,
text/plain
|
Details | |
89 bytes,
application/x-javascript
|
Details | |
1.48 KB,
patch
|
bzbarsky
:
review+
|
Details | Diff | Splinter Review |
3.36 KB,
patch
|
luke
:
review+
|
Details | Diff | Splinter Review |
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
![]() |
||
Comment 1•13 years ago
|
||
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
![]() |
||
Updated•13 years ago
|
![]() |
||
Updated•13 years ago
|
tracking-firefox18:
--- → ?
Component: Preferences → XPConnect
Product: Firefox → Core
Version: unspecified → 18 Branch
![]() |
||
Comment 2•13 years ago
|
||
In local build,
Last good:382dce79a998
First bad: 1cef36c730eb
Comment 3•13 years ago
|
||
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?
![]() |
||
Comment 4•13 years ago
|
||
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
Comment 5•13 years ago
|
||
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
Comment 6•13 years ago
|
||
Attachment #661204 -
Flags: review?(bzbarsky)
Comment 8•13 years ago
|
||
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.
Comment 9•13 years ago
|
||
(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 10•13 years ago
|
||
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 11•13 years ago
|
||
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.
Comment 12•13 years ago
|
||
(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 13•13 years ago
|
||
Comment on attachment 661205 [details] [diff] [review]
Replace no-op principal check with something real. v1
Excellent.
Attachment #661205 -
Flags: review?(luke) → review+
Comment 14•13 years ago
|
||
Comment 15•13 years ago
|
||
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
Comment 16•13 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/ef528ae38f04
https://hg.mozilla.org/mozilla-central/rev/acec40170961
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla18
![]() |
||
Comment 17•13 years ago
|
||
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.
Updated•13 years ago
|
Comment 18•13 years ago
|
||
This will need to make Firefox 17 as well so it is in the ESR
Comment 19•13 years ago
|
||
Can we get a try build so that mkaply can help us confirm this is fixed.
tracking-firefox17:
--- → ?
Comment 20•13 years ago
|
||
(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.
Comment 21•13 years ago
|
||
(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.
Updated•13 years ago
|
status-firefox18:
--- → fixed
You need to log in
before you can comment on or make changes to this bug.
Description
•