Autoconfiguration via mozilla.cfg no longer works in Nightly: "Failed to read the configuration file. Please contact your system administrator."

RESOLVED FIXED in Firefox 22

Status

()

Core
XPConnect
--
major
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: dickvl, Assigned: bholley)

Tracking

({regression})

22 Branch
mozilla23
x86
All
regression
Points:
---

Firefox Tracking Flags

(firefox21 unaffected, firefox22+ fixed, firefox23 fixed)

Details

Attachments

(2 attachments, 2 obsolete attachments)

(Reporter)

Description

5 years ago
I use a mozilla.cfg file to set some prefs to a specific value for all profiles.

When starting the Nightly 22.0a1 build I get this error message:
"Failed to read the configuration file. Please contact your system administrator."

This build works:
https://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2013-03-28-03-10-13-mozilla-central/
SourceStamp=962f5293f87f

This build gives the error message:
https://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2013-03-29-03-09-04-mozilla-central/
SourceStamp=8693d1d4c86d

http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=962f5293f87f&tochange=8693d1d4c86d

STR:
1. local settings.js with this content in Nightly /defaults/pref directory
pref("general.config.filename", "mozilla.cfg");
pref("general.config.obscure_value", 0);

2. mozilla.cfg with this content
// 
pref("browser.startup.homepage", "about:about");
pref("browser.newtab.url", "about:blank");

See also:
http://kb.mozillazine.org/Locking_preferences
(In reply to dickvl from comment #0)
> http://hg.mozilla.org/mozilla-central/
> pushloghtml?fromchange=962f5293f87f&tochange=8693d1d4c86d

I see nothing obvious at first glance. A narrower range would be useful.
Keywords: regressionwindow-wanted

Comment 2

5 years ago
Regression window(m-i)
Good:
http://hg.mozilla.org/integration/mozilla-inbound/rev/adb4ae9d355a
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:22.0) Gecko/20130327 Firefox/22.0 ID:20130327182706
Bad:
http://hg.mozilla.org/integration/mozilla-inbound/rev/6422928d26e4
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:22.0) Gecko/20130327 Firefox/22.0 ID:20130327182807
Pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=adb4ae9d355a&tochange=6422928d26e4
Status: UNCONFIRMED → NEW
tracking-firefox22: --- → ?
Ever confirmed: true

Updated

5 years ago
Blocks: 790732

Comment 3

5 years ago
Last Good: d5dfcbbcd176+a39cf8abc9c2
First Bad: a2998da65e3a+a39cf8abc9c2

Triggered by:
a2998da65e3a	Bobby Holley — Bug 790732 - Stop attaching Components in InitClasses. r=mrbkap This method is larely deprecated. The only two consumers are JSD and the setup for the safe JSContext, neither of which use system principal and thus neither of which should have |Components|.
Keywords: regressionwindow-wanted → regression
(Assignee)

Comment 4

5 years ago
Yeah, this stuff needs to stop doing stuff the old way. I'll write a patch.
Assignee: nobody → bobbyholley+bmo
(Assignee)

Comment 5

5 years ago
Created attachment 731536 [details] [diff] [review]
Part 1 - Clean up nsXPConnect sandbox API a bit. v1
(Assignee)

Comment 6

5 years ago
Created attachment 731537 [details] [diff] [review]
Part 2 - Use a sandbox in nsJSConfigTriggers. v1
(Assignee)

Comment 7

5 years ago
Pushed these to try here: https://tbpl.mozilla.org/?tree=Try&rev=73f1c12fd675

dickvl: If the try builds are successful, they should appear here: http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/bobbyholley@gmail.com-73f1c12fd675/

Can you give them a spin and see if they work well for you? We don't have a ton of test coverage for this stuff, unfortunately.

Updated

5 years ago
Component: Preferences → XPConnect
Product: Firefox → Core

Comment 8

5 years ago
(In reply to Bobby Holley (:bholley) from comment #7)
> Pushed these to try here: https://tbpl.mozilla.org/?tree=Try&rev=73f1c12fd675
> 
> dickvl: If the try builds are successful, they should appear here:
> http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/bobbyholley@gmail.
> com-73f1c12fd675/
> 
> Can you give them a spin and see if they work well for you? We don't have a
> ton of test coverage for this stuff, unfortunately.

The try server works as expected.

http://hg.mozilla.org/try/rev/73f1c12fd675
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:22.0) Gecko/20130330 Firefox/22.0 ID:20130330125338
(Reporter)

Comment 9

5 years ago
Works for me as well with the try build on Linux (32 bit).

firefox-22.0a1.en-US.linux-i686.tar.bz2.
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/bobbyholley@gmail.com-73f1c12fd675/try-linux/
(Assignee)

Updated

5 years ago
Attachment #731536 - Flags: review?(mrbkap)
(Assignee)

Updated

5 years ago
Attachment #731537 - Flags: review?(mrbkap)
Attachment #731537 - Flags: feedback?(stransky)
(Assignee)

Comment 10

5 years ago
This removes one of the last uses of InitClasses, which brings us closer to removing it (still waiting on jsd to go away).

Updated

5 years ago
status-firefox21: --- → unaffected
status-firefox22: --- → affected
tracking-firefox22: ? → +
Comment on attachment 731536 [details] [diff] [review]
Part 1 - Clean up nsXPConnect sandbox API a bit. v1

Review of attachment 731536 [details] [diff] [review]:
-----------------------------------------------------------------

::: js/xpconnect/src/nsXPConnect.cpp
@@ +1665,5 @@
>  {
>      if (!sandbox)
>          return NS_ERROR_INVALID_ARG;
>  
> +    return xpc_EvalInSandbox(cx, sandbox, source, filename ? filename : "XPConnect-evaluated sandbox script",

Is it worth it to make the default filename something like: x-bogus://XPConnect...?
Attachment #731536 - Flags: review?(mrbkap) → review+
Comment on attachment 731537 [details] [diff] [review]
Part 2 - Use a sandbox in nsJSConfigTriggers. v1

Review of attachment 731537 [details] [diff] [review]:
-----------------------------------------------------------------

Some of the incantations for creating and using a sandbox from C++ are a little odd (having to unwrap the sandbox object is, in particular, pretty opaque) but this is unspeakably better than the manual JSAPI goop that was here before (to be clear: it makes sense that it was written that way to begin with, it's just nice to see it be replaced with a newer and cleaner API).

::: extensions/pref/autoconfig/src/nsJSConfigTriggers.cpp
@@ -127,5 @@
> -    JS_SetErrorReporter(autoconfig_cx, autoConfigErrorReporter);
> -
> -    // Create a new Security Manger and set it for the new JS context
> -    nsCOMPtr<nsIXPCSecurityManager> secman =
> -        static_cast<nsIXPCSecurityManager*>(new AutoConfigSecMan());

Now that this is going away, can the entirety of the AutoConfigSecMan go away?
Attachment #731537 - Flags: review?(mrbkap) → review+
(Assignee)

Comment 13

5 years ago
Created attachment 732384 [details] [diff] [review]
Part 1 - Clean up nsXPConnect sandbox API a bit. v2 r=mrbkap
Attachment #731536 - Attachment is obsolete: true
Attachment #732384 - Flags: review+
(Assignee)

Comment 14

5 years ago
Created attachment 732385 [details] [diff] [review]
Part 2 - Use a sandbox in nsJSConfigTriggers. v2 r=mrbkap
Attachment #731537 - Attachment is obsolete: true
Attachment #731537 - Flags: feedback?(stransky)
Attachment #732385 - Flags: review+
(Assignee)

Comment 16

5 years ago
Comment on attachment 732385 [details] [diff] [review]
Part 2 - Use a sandbox in nsJSConfigTriggers. v2 r=mrbkap

This approval request applies to both patches.

[Approval Request Comment]
Bug caused by (feature/regressing bug #): bug 790732
User impact if declined: autoconfig scripts (an enterprise feature) stop working
Testing completed (on m-c, etc.): just landed to m-i
Risk to taking this patch (and alternatives if risky): not risky
String or IDL/UUID changes made by this patch: Nothing l10n-sensitive.
Attachment #732385 - Flags: approval-mozilla-aurora?
https://hg.mozilla.org/mozilla-central/rev/3e77cc47227d
https://hg.mozilla.org/mozilla-central/rev/513b51bb7909
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla23

Updated

5 years ago
Attachment #732385 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
You need to log in before you can comment on or make changes to this bug.