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

Status: RESOLVED FIXED

(Core :: XPConnect, defect)

Description

[dickvl]

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

Comment 1

[Dão Gottwald [:dao]]

(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.

Comment 2

[Alice0775 White]

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

Comment 3

[Alice0775 White]

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|.

Comment 4

[Bobby Holley (:bholley)]

Yeah, this stuff needs to stop doing stuff the old way. I'll write a patch.

Comment 5

[Bobby Holley (:bholley)]

Attachment: Part 1 - Clean up nsXPConnect sandbox API a bit. v1

Comment 6

[Bobby Holley (:bholley)]

Attachment: Part 2 - Use a sandbox in nsJSConfigTriggers. v1

Comment 7

[Bobby Holley (:bholley)]

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/[e-mail]-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.

Comment 8

[Alice0775 White]

(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

Comment 9

[dickvl]

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/[e-mail]-73f1c12fd675/try-linux/

Comment 10

[Bobby Holley (:bholley)]

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

Comment 11

[Blake Kaplan (:mrbkap) (inactive)]

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...?

Comment 12

[Blake Kaplan (:mrbkap) (inactive)]

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?

Comment 13

[Bobby Holley (:bholley)]

Attachment: Part 1 - Clean up nsXPConnect sandbox API a bit. v2 r=mrbkap

Comment 14

[Bobby Holley (:bholley)]

Attachment: Part 2 - Use a sandbox in nsJSConfigTriggers. v2 r=mrbkap

Comment 15

[Bobby Holley (:bholley)]

remote:   https://hg.mozilla.org/integration/mozilla-inbound/rev/3e77cc47227d
remote:   https://hg.mozilla.org/integration/mozilla-inbound/rev/513b51bb7909

Comment 16

[Bobby Holley (:bholley)]

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.

Comment 17

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/3e77cc47227d
https://hg.mozilla.org/mozilla-central/rev/513b51bb7909

Comment 18

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/8e7e98b2b3ee
https://hg.mozilla.org/releases/mozilla-aurora/rev/bdc9550d4a12