Closed
Bug 856257
Opened 12 years ago
Closed 12 years ago
Autoconfiguration via mozilla.cfg no longer works in Nightly: "Failed to read the configuration file. Please contact your system administrator."
Categories
(Core :: XPConnect, defect)
Tracking
()
RESOLVED
FIXED
mozilla23
Tracking | Status | |
---|---|---|
firefox21 | --- | unaffected |
firefox22 | + | fixed |
firefox23 | --- | fixed |
People
(Reporter: bugdickvl, Assigned: bholley)
References
Details
(Keywords: regression)
Attachments
(2 files, 2 obsolete files)
(deleted),
patch
|
bholley
:
review+
|
Details | Diff | Splinter Review |
(deleted),
patch
|
bholley
:
review+
akeybl
:
approval-mozilla-aurora+
|
Details | Diff | Splinter Review |
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•12 years ago
|
||
(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•12 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
Comment 3•12 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•12 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•12 years ago
|
||
Assignee | ||
Comment 6•12 years ago
|
||
Assignee | ||
Comment 7•12 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•12 years ago
|
Component: Preferences → XPConnect
Product: Firefox → Core
Comment 8•12 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
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•12 years ago
|
Attachment #731536 -
Flags: review?(mrbkap)
Assignee | ||
Updated•12 years ago
|
Attachment #731537 -
Flags: review?(mrbkap)
Attachment #731537 -
Flags: feedback?(stransky)
Assignee | ||
Comment 10•12 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•12 years ago
|
Comment 11•12 years ago
|
||
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 12•12 years ago
|
||
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•12 years ago
|
||
Attachment #731536 -
Attachment is obsolete: true
Attachment #732384 -
Flags: review+
Assignee | ||
Comment 14•12 years ago
|
||
Attachment #731537 -
Attachment is obsolete: true
Attachment #731537 -
Flags: feedback?(stransky)
Attachment #732385 -
Flags: review+
Assignee | ||
Comment 15•12 years ago
|
||
Assignee | ||
Comment 16•12 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?
Comment 17•12 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/3e77cc47227d
https://hg.mozilla.org/mozilla-central/rev/513b51bb7909
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla23
Updated•12 years ago
|
Attachment #732385 -
Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Comment 18•12 years ago
|
||
https://hg.mozilla.org/releases/mozilla-aurora/rev/8e7e98b2b3ee
https://hg.mozilla.org/releases/mozilla-aurora/rev/bdc9550d4a12
status-firefox23:
--- → fixed
You need to log in
before you can comment on or make changes to this bug.
Description
•