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.
|Designing Electronics with Linux||May 22, 2013|
|Dynamic DNS—an Object Lesson in Problem Solving||May 21, 2013|
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
- Linux Systems Administrator
- New Products
- Senior Perl Developer
- Technical Support Rep
- UX Designer
- Designing Electronics with Linux
- Dynamic DNS—an Object Lesson in Problem Solving
- Using Salt Stack and Vagrant for Drupal Development
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Have you tried Boxen? It's a
5 hours 36 min ago
- seo services in india
10 hours 8 min ago
- For KDE install kio-mtp
10 hours 9 min ago
- Evernote is much more...
12 hours 9 min ago
- Reply to comment | Linux Journal
20 hours 54 min ago
- Dynamic DNS
21 hours 28 min ago
- Reply to comment | Linux Journal
22 hours 27 min ago
- Reply to comment | Linux Journal
23 hours 17 min ago
- Not free anymore
1 day 3 hours ago
1 day 7 hours ago
Enter to Win an Adafruit Pi Cobbler Breakout Kit for Raspberry Pi
It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Pi Cobbler Breakout Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- 5-21-13, Prototyping Pi Plate Kit: Philip Kirby
- Next winner announced on 5-27-13!
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?