Ten Mysteries of about:config
The Firefox Web browser, built by the Mozilla Foundation and friends is a complicated piece of technology—if you care to look under the hood. It's not obvious where the hood catch is, because the surface of Firefox (its user interface) is polished up to appeal to ordinary, nontechnical end users. This article gives you a glimpse of the engine. It explains how the Mozilla about:config URL opens up a world of obscure preferences that can be used to tweak the default setup. They're an improbable collection and therein lies the beauty of Firefox if you're a grease monkey or otherwise technical. At the end you'll know a little more about Firefox, but only enough to be dangerous.
Like any Linux-friendly piece of software, Firefox responds to preset environment variables. You can, for example, set the MOZILLA_FIVE_HOME or MOZ_PLUGIN_PATH variables prior to startup. They both work like the standard PATH, so no surprises there. The per-process space available for environment variables is, however, limited, and a simple textual concatenation of attribute-value pairs is a fairly inflexible way to store data. Firefox has a large set of runtime configuration options, and the environment isn't a suitable storage area.
Firefox configuration is stored in a small attribute-type-value database called the preference system. You can see a delta of this data set in the ~/.mozilla/firefox/*/prefs.js file. That file holds only the nondefault values selected by the user. The rest of the preferences either are unstated or stated in install files that are part of the standard install. For me, they're in /local/install/firefox/defaults/pref, because /local is my playpen of choice.
For a technical person, this system is a bit problematic because the full list of preferences doesn't appear anywhere on disk, and the standard way to change those preferences is to use the Firefox User Interface, which also is incomplete. That interface provides GUI elements (buttons, fields and check boxes) for only the most basic of the preferences available. Firefox isn't trying to be Emacs, after all. The rest of the preferences have to be dug up from elsewhere.
That other place is the special string about:config, which can be typed in the Firefox Location bar where the addresses of Web sites are entered. Briefly recall the taxonomy of W3C addresses: URIs (Universal Resource Identifiers) are a special case of IRIs (International Resource Identifiers). A URI either can be a URL (a Uniform Resource Locator) or a URN ( a Uniform Resource Name). It's URLs that we see all the time. They consist of a scheme (typically http), a colon (:) and an address (x.org).
You can define your own scheme. Mozilla does that for “about”, which is used to access internal browser resources. Try about:cache, for example. The config resource is a hook into the preference system. When you type about:config, you're navigating to a local resource just as you would navigate to a Web-based resource for an HTTP-based Web page. Figure 1 shows the results of loading the about:config resource.
This preference listing is also a form. Right-click on any preference to modify it or to state a new preference. Shorten the display by entering some text in the Filter box if you want. Many Firefox extensions can provide alternate interfaces to about:config. Feel free to experiment with them.
Nothing is perfect, alas; about:config shows only preferences that already have been set or specified anywhere. It doesn't show preferences that have meaningful uses, which appear nowhere in the about:config list. To add a value for a new preference that doesn't appear, simply right-click anywhere in the main window, and select New from the context menu, then select the type of preference: string, integer or Boolean.
Without further ado, here's a tour of preferences to which the Firefox UI doesn't give you access. Some are unmasked by about:config; some are not. They're all relatively safe to experiment with. If you get into trouble, go back to about:config and unset the preference, or, in the worst case, shut down Firefox and delete the prefs.js file noted earlier. Everything said to this point also applies to other Mozilla products: the Mozilla Application Suite, Thunderbird and so on. Hesitate before deleting the Thunderbird prefs.js file. It contains important pointers to your e-mail.
Here's a simple preference to begin with. You can explicitly set the size of the memory part of Firefox's Web cache. Here's the preference, which has a type of integer:
Set it to the integral number of KB (Kilobytes) that you want as a maximum. By default, this preference is unstated and has a default value of -1, meaning “expand to fill available memory as required”. That's a little like the Linux disk buffer cache. You might not want that if you're running OpenOffice.org and Firefox simultaneously and working both applications hard. If you do change this preference, you're going the way of Mac OS 9 and lower, where each application gets an explicit memory allocation. That could be a tuning burden if you go too far with it.
The Mozilla Web cache (both memory and disk) is akin to the function of servers like Squid. That is, both types of cache are smart about the use of HTTP headers for caching purposes. If you're in control of the local Web proxy, there's probably more value in a huge Squid cache than there is in a really big local disk cache. A bigger Firefox cache still gives some performance boost though. You can alter caching use through the integer preference:
This preference affects when Firefox accesses the cache, not how the cache itself works. The cache caches Web content every opportunity it gets, but if Firefox fails to check it, such opportunities will come rarely. Set the preference to 0 for one check per URL resource per Firefox Web surfing session, 1 always to use the cache, 2 never to use the cache and 3 (the default) when the HTTP caching rules says it's a good idea to cache.
Getting Started with DevOps - Including New Data on IT Performance from Puppet Labs 2015 State of DevOps Report
August 27, 2015
12:00 PM CDT
DevOps represents a profound change from the way most IT departments have traditionally worked: from siloed teams and high-anxiety releases to everyone collaborating on uneventful and more frequent releases of higher-quality code. It doesn't matter how large or small an organization is, or even whether it's historically slow moving or risk averse — there are ways to adopt DevOps sanely, and get measurable results in just weeks.
Free to Linux Journal readers.Register Now!
- Three More Lessons
- Django Models and Migrations
- August 2015 Issue of Linux Journal: Programming
- Hacking a Safe with Bash
- Secure Server Deployments in Hostile Territory, Part II
- The Controversy Behind Canonical's Intellectual Property Policy
- Huge Package Overhaul for Debian and Ubuntu
- Shashlik - a Tasty New Android Simulator
- Embed Linux in Monitoring and Control Systems
- KDE Reveals Plasma Mobile