Debugging Firefox AutoConfig Problems

I get a lot of questions about debugging AutoConfig issues, so I thought I would document what I do to try to track them down.

If Firefox starts, go to about:config and search for general.config. Make sure there are values for general.config.filename and general.config.obscure_value. If they are not there, your defaults/prefs/autoconfig.js file is not being read. The most common reason this happens is permissions or you’ve placed it in the wrong directory.

If both the general.config values are present, the next step is to check if your cfg file is being read. I usually make a very simple cfg file:

// First line is always a comment
lockPref("a.b.c.d", "e.f.g.h");

Then I go to about:config and verify that the a.b.c.d preference is there (it will be at the top). If the preference is not there, then something must be very wrong. I check the browser console to see if there are any errors. If the preference is there, AutoConfig is working correctly. I then start adding it the parts of my AutoConfig file a piece at a time, leaving the setting of the a.b.c.d pref at the end of the file. Then I check about:config each time and see which line is breaking the AutoConfig file.

If the browser doesn’t start at all, the first thing I do is put all my AutoConfig code in a try/catch block like this:

// First line is always a comment
try {
  // My AutoConfig code.
} catch (e) {
  Components.utils.reportError(e);
}

If the browser then starts, I look in the browser console to see what the error was. If the browser still doesn’t start, I start removing pieces of my AutoConfig until it does.

The most common problem in the past with AutoConfig was the use of let instead of var. This was fixed in Firefox 42 and should no longer be an issue. Some other common problems were around the use of international characters, in particular saving AutoConfig files as UTF-8 versus ASCII. This should also be fixed. All AutoConfig files should be saved as UTF-8.

In general, as long as you don’t have JavaScript syntax errors in your AutoConfig file, they should just work. That’s been my experience, and I’ve written some pretty complicated AutoConfig files.

Please note: I reserve the right to delete comments that are offensive or off-topic.

Leave a Reply

Your email address will not be published. Required fields are marked *

5 thoughts on “Debugging Firefox AutoConfig Problems

  1. Thanks Mike for the AutoConfig update.

    An urgent topic came to my attention lately when I customised a new profile from scratch: the search engine problem. I found out that Mozilla stores all its configuration in the LZ4 compressed file search.json.mozlz4 now. Annoyingly, it’s not feasible any longer to get new search engines (Mycroft etc.) as separate files to customise them afterwards (e.g. removal of tracking ids), they’ll get directly written into search.json.mozlz4.

    There’s little what one can do, Florian Quèze mentioned one awkward method:
    https://bugzilla.mozilla.org/show_bug.cgi?id=1236498#c7

    This is another bad decision from Mozilla to piss off its loyal long-term users.
    How may I manage (customised) search engines, how do I scrape newly installed (Mycroft) additional engines out of search.json.mozlz4? I don’t need to automatise this, I’m just searching for a viable way…

    • I’ve just updated the add-on to support downloading XML files. So you can hold down the shift key when clicking on mycroft and get a copy of the XML file. You can then modify the XML and add it via the Add button in preferences.

  2. Hi Mike.
    Thanks to you I was able to add certificates using AutoConfig.
    I am using Firefox 49. The problem now I am facing is that some websites provide an invalid certificate see ( https://appsgate.iitk.ac.in/ ) , they are not being verified by Firefox (even after adding their certificate).
    I can still trust the server by manually adding it (clicking on ‘Add Exception’ in the Servers tab of ‘View Certificates’).
    Anyway to do that via AutoConfig ?
    Thanks Again