Dev : Using preferences

From MozillaZine Knowledge Base

(Difference between revisions)
Revision as of 19:16, 9 March 2005
Grimholtz (Talk | contribs)
(added info about Javascript Preferences Class)
<-- Previous diff
Revision as of 20:21, 9 March 2005
Grimholtz (Talk | contribs)
(removed name info about JS Preferences Class)
Next diff -->
Line 6: Line 6:
==Javascript Preferences Class== ==Javascript Preferences Class==
-grimholtz (eric h. jung) has written a [[Dev : Extensions : Example Code : Javascript Preferences Class | Preferences Class]] in Javascript for Mozilla. It encapsulates most of the functionality found on this page into a centralized, reusable class which traps exceptions, allows you to specify default values for preferences when they don't exist in any preference tree, and keeps code organized by localizing preference manipulation to a single class.+There are [[Dev : Extensions : Example Code : Javascript Preferences Class | Preferences Classes]] in Javascript for Mozilla. They encapsulates most of the functionality found on this page into a centralized, reusable class which traps exceptions, allows you to specify default values for preferences when they don't exist in any preference tree, and keeps code organized by localizing preference manipulation to a single class.
==XPCOM interfaces for preferences system== ==XPCOM interfaces for preferences system==

Revision as of 20:21, 9 March 2005

This page is part of the extension development documentation project.

Ask your questions in MozillaZine Forums. Also try browsing example code.

Note: development documentation is in process of being moved to Mozilla Development Center (MDC).

This article is about using Mozilla Preferences system. Information here applies to the Mozilla Suite, Firefox, Thunderbird and possibly other Mozilla-based applications. Intended audience is Mozilla extension developers who wish to learn details about using preferences in Mozilla.

If you haven't yet, read other documents about Mozilla preferences on XUL Planet and on (links below in Resources section).


Javascript Preferences Class

There are Preferences Classes in Javascript for Mozilla. They encapsulates most of the functionality found on this page into a centralized, reusable class which traps exceptions, allows you to specify default values for preferences when they don't exist in any preference tree, and keeps code organized by localizing preference manipulation to a single class.

XPCOM interfaces for preferences system

Mozilla exposes its preferences system through a few XPCOM interfaces. Look in the Resources section below for the link to list of preferences-related interfaces.

Three most used interfaces are nsIPrefService, nsIPrefBranch and nsIPrefBranchInternal. First two are frozen and will not change, last one is “internal”, but is very useful because it allows you to set up prefs observers — see below for an example.

It's worth noting that there also is an nsIPref interface. Despite it being used in some places, it is deprecated and should not be used.

Preferences service is instantiated exactly as any other service. (See Creating XPCOM Components document at XUL Planet for details.) To get an nsIPrefBranch, either QI the pref service (that will give you the root branch) or call nsIPrefService.getBranch() to get a sub-branch.

Here are two examples:

// Get the root branch
var prefs = Components.classes[";1"].
// Get the "extensions.myext." branch
var prefs = Components.classes[";1"].
prefs = prefs.getBranch("extensions.myext.");

Simple types

There are three types of preferences: string, integer and boolean. Each entry in preferences database (prefs.js) has one of those types. There are six methods of nsIPrefBranch that read and write them: getBoolPref, setBoolPref, getCharPref, setCharPref, getIntPref and setIntPref. Using them is as easy as:

// prefs is an nsIPrefBranch.
// Look in the above section for examples of getting one.
var value = prefs.getBoolPref("accessibility.typeaheadfind"); // get a pref
prefs.setBoolPref("accessibility.typeaheadfind", !value); // set a pref

Complex types

As noted in previous section, each entry in prefs database (prefs.js) must have a string, an integer or a boolean value. However, there is a concept of complex types, which makes it easier for developers to save and load nsILocalFile and nsISupportsString objects in preferences (as strings — note that from the preferences system's POV, complex values have a nsIPrefBranch.PREF_STRING type.)

There are two nsIPrefBranch methods implementing the concept — setComplexValue and getComplexValue. You can look up their implementation in nsPrefBranch.cpp. Here is the IDL definition:

void getComplexValue(in string aPrefName, in nsIIDRef aType, 
		[iid_is(aType), retval] out nsQIResult aValue);

void setComplexValue(in string aPrefName, in nsIIDRef aType, in nsISupports aValue);

As you can see, both of them take aType parameter. It can have the following values (to be precise, you should pass Components.interfaces.nsIWhatever instead of just nsIWhatever, which is undefined):

  • nsISupportsString — used to handle unicode strings in preferences. Use this when the preference value may contain non-ASCII characters (for example, user's name).
  • nsIPrefLocalizedString — almost same as nsISupportsString, but it is handled differently in getComplexValue when there's no user value for given preference, see below for details.
  • nsILocalFile and nsIRelativeFilePref — store paths in preferences. nsILocalFile is used to store absolute paths, while nsIRelativeFilePref is used to store paths relative to one of “special” directories, like the profile folder.


As noted above, this is used to handle unicode strings in preferences. Example:

// prefs is an nsIPrefBranch

// Example 1: getting unicode value
var value = prefs.getComplexValue("preference.with.non.ascii.value",

// Example 2: setting unicode value
var str = Components.classes[";1"]
      .createInstance(Components.interfaces.nsISupportsString); = "some non-ascii text";
      Components.interfaces.nsISupportsString, str);


Another complex type supported by Mozilla is nsIPrefLocalizedString. It is similar to nsISupportsString, the only difference is that when there is no user value, getComplexValue gets the default value from a locale file (thus making the default value localizable).

It's easier to explain this on example. Let's say you want to make the default value for extensions.myext.welcomemessage preference localizable. You should do the following:

  1. Add this line to some .properties file (for all of your locales), say to chrome://myext/locale/
    extensions.myext.welcomemessage=Localized default value
  2. Add the default value for extensions.myext.welcomemessage, pointing to that properties file, by adding the following line to your file with default preferences (see below).
    pref("extensions.myext.welcomemessage", "chrome://myext/locale/");
  3. Read the preference with getComplexValue, passing nsIPrefLocalizedString as aType:
    var prefs = Components.classes[";1"].
    var branch = prefs.getBranch("extensions.myext.");
    var value = branch.getComplexValue("welcomemessage",

The code in step 3 will read the default value from chrome://myext/locale/ when no user value is set, and will behave exactly the same as if nsISupportsString was passed as aType otherwise.

nsILocalFile and nsIRelativeFilePref

Please see the File IO article for details on nsILocalFile and nsIRelativeFilePref.

Default preferences

Each preference may have up to two values — current and default. That means there are two “pref trees” — current and default, — and each of them may or may not have a value for preference in question.

You can see the list of preferences in about:config (where available). Preferences that have user value are bold, those that don't have a user value are printed in normal font.

What effect do default preferences have on various get methods

When one of get methods of nsIPrefBranch (assuming it's a branch of the tree with current values) is called, it does the following:

  1. Checks whether the “current” tree has a value for the pref and whether the pref is locked.
  2. If there's a value of correct type (f.e. getBoolValue expects a value of type nsIPrefBranch.PREF_BOOL), and the preference is not locked, the method returns that value.
  3. If there's a value of incorrect type and the pref is not locked, an exception is thrown (NS_ERROR_UNEXPECTED)
  4. If the preference is locked or if there is no value for that preference in “current” tree, the get method checks the default tree.
  5. If there's a value of expected type in the “default” tree, it is returned (with the only exception, getComplexValue with aType parameter = nsIPrefLocalizedString, described above)
  6. Otherwise an exception is thrown (NS_ERROR_UNEXPECTED).

If the branch is from the “default” tree, the get method doesn't check the tree with current values at all.

(This is not exactly how it's coded in libpref, but it's equivalent)

Where are the default values read from

  • All Mozilla-based applications read (application directory)/defaults/pref/*.js .
  • In addition to that, the recent versions of new toolkit applications (Firefox 1.0, Thunderbird 1.0 and the like; not Mozilla Suite) read files listed in (profile folder)/defaults.ini — usually (profile folder)/extensions/{guid}/defaults/preferences/

How to install extension's defaults files

For Mozilla, copy them to (appdir)/defaults/pref in your install script.

For Firefox/Thunderbird, just put them in myext.xpi/defaults/preferences/. They will be copied and registered in defaults.ini automatically.

Using preferences observers

You can use nsIPrefBranchInternal interface to “listen” to changes to preferences in a certain branch. Here's an example (note, this code hasn't actually been tested, so it may contain typos and other errors):

var myPrefObserver =
  register: function()
    var prefService = Components.classes[";1"].
    this._branch = prefService.getBranch("extensions.myextension.");

    var pbi = this._branch.QueryInterface(Components.interfaces.nsIPrefBranchInternal);
    pbi.addObserver("", this, false);

  unregister: function()
    if(!this._branch) return;

    var pbi = this._branch.QueryInterface(Components.interfaces.nsIPrefBranchInternal);
    pbi.removeObserver("", this);

  observe: function(aSubject, aTopic, aData)
    if(aTopic != "nsPref:changed") return;
    // aSubject is the nsIPrefBranch we're observing
    switch (aData) {
      case "pref1":
        // extensions.myextension.pref1 was changed
      case "pref2":
        // extensions.myextension.pref2 was changed