Current Beta 62.0b19 shows "Autoconfig is sandboxed by default" in Browser Console (bug 1479857)
I noticed that my mozilla.cfg stopped working with Beta updating to 62.0b19. I noticed two messages in the Browser console. The first about 'components' not being defined and the second about "Autoconfig is sandboxed by default" with a not working link to Enterprise Release Notes.
A search shows that this is about bug 1479857.
- bug 1479857 - Add a preference (default off) for autoconfig sanboxing for first release
What will be the consequences of this sandbox and autoconfig.js when it will no longer be possible to disable this sandbox via general.config.sandbox_enabled?
Will that make it impossible to add specific code to an autoconfig file like setting the new tab page via aboutNewTabService or add other code that calls Services?
การตอบกลับทั้งหมด (5)
> What will be the consequences of this sandbox and autoconfig.js when it will no longer be possible to disable this sandbox via general.config.sandbox_enabled?
You will only be able to set preferences via Autoconfig on rapid release Firefox. You will have full Autoconfig support on ESR.
> Will that make it impossible to add specific code to an autoconfig file like setting the new tab page via aboutNewTabService or add other code that calls Services?
Yes it will unless you are using the ESR, beta or nightly. If there are specific requirements you have around Autoconfig, let us know and we'll consider adding them as policies.
Thanks. Most important for me is to have a way to set the new tab page for all profiles without the need of using an extension. I use about:blank for the new tab page and about:about for the home page. I keep a lot of Firefox versions and profiles and having a way to set the new tab page globally makes this a lot easier.
var newTabURL = "about:blank"; aboutNewTabService = Cc["@mozilla.org/browser/aboutnewtab-service;1"].getService(Ci.nsIAboutNewTabService); aboutNewTabService.newTabURL = newTabURL;
I also add a pref to save the file path in prefs.js to see what profile I currently use and also for identifying a backup of prefs.js.
Cu.import("resource://gre/modules/Services.jsm"); var profD = Services.dirsvc.get("ProfD", Ci.nsIFile).path;
And I use try and catch blocks with a call to Cu.reportError() to check for errors and make things work in all Firefox versions I use.
catch(e){Components.utils.reportError(e);}
I'll investigate adding new tab to policies.
Can you provide a little more detail on the other change?
The other change about adding the path is not that important, but it helps me to avoid confusion in case I have multiple Firefox versions open via -no-remote for testing whether I can reproduce what a user reports in a question. With the code in mozilla.cfg I know this pref is always available in case I don't remember what Firefox version and what profile I started via the Profile Manager (most testing profiles have a xxxxxxxx.test-## name, so I can see both version and profile in one glance).
Will calls like getenv() still work? I assume they do if I inspect the prefcalls.js file.
displayError() gives an alert and there is not a function available to output a message to the browser console, so maybe consider to add a reportError() or consoleLog() function to prefcalls.js if this can work in the sandbox.
getenv will still work. And that's a good idea to add some new APIs for things.