This is an archived page. It's not actively maintained.



Support for extensions using XUL/XPCOM or the Add-on SDK was removed in Firefox 57, released November 2017. As there is no supported version of Firefox enabling these technologies, this page will be removed by December 2020.

Add-ons using the techniques described in this document are considered a legacy technology in Firefox. Don't use these techniques to develop new add-ons. Use WebExtensions instead. If you maintain an add-on which uses the techniques described here, consider migrating it to use WebExtensions.

Starting from Firefox 53, no new legacy add-ons will be accepted on (AMO) for desktop Firefox and Firefox for Android.

Starting from Firefox 57, only extensions developed using WebExtensions APIs will be supported on Desktop Firefox and Firefox for Android.

Even before Firefox 57, changes coming up in the Firefox platform will break many legacy extensions. These changes include multiprocess Firefox (e10s), sandboxing, and multiple content processes. Legacy extensions that are affected by these changes should migrate to use WebExtensions APIs if they can. See the "Compatibility Milestones" document for more information.

A wiki page containing resources, migration paths, office hours, and more, is available to help developers transition to the new technologies.


Enables your add-on to log error, warning or informational messages. If you have started Firefox for your add-on from the command line with jpm run or jpm test then these messages appear in the command shell you used. If the add-on has been installed in Firefox, then the messages appear in the Browser Console.

If you're developing your add-on using the Extension Auto-installer, then the add-on is installed in Firefox, meaning that messages will appear in the Browser Console. But see the discussion of logging levels: by default, messages logged using log(), info(), trace(), or warn() won't be logged in these situations.

Console Methods

All console methods except exception() and trace() accept one or more JavaScript objects as arguments and log them to the console. Depending on the console's underlying implementation and user interface, you may be able to examine the properties of non-primitive objects that are logged.


Deprecated, you should use console.log() instead.

console.error(object[, object, ...])

Logs the arguments to the console, preceded by "error:" and the name of your add-on:

console.error("This is an error message");
error: my-addon: This is an error message


Logs the given exception instance as an error, outputting information about the exception's stack traceback if one is available.

try {
} catch (e) {

function UserException(message) {
   this.message = message; = "UserException";

function doThing() {
  throw new UserException("Thing could not be done!");
error: my-addon: An exception occurred.
UserException: Thing could not be done![, object, ...])

A synonym for console.log().

console.log(object[, object, ...])

Logs the arguments to the console, preceded by "info:" and the name of your add-on:

console.log("This is an informational message");
info: my-addon: This is an informational message


Starts a timer with a name specified as an input parameter. Up to 10,000 simultaneous timers can run on a given page.


Stops the specified timer and logs the elapsed time in seconds since its start. See Timers.


Logs a stack trace at the point the function is called.

console.warn(object[, object, ...])

Logs the arguments to the console, preceded by "warn:" and the name of your add-on:

console.warn("This is a warning message");
warn: my-addon: This is a warning message

Logging Levels

Logging's useful, of course, especially during development. But the more logging there is, the more noise you see in the console output. Especially when debug logging shows up in a production environment, the noise can make it harder, not easier, to debug issues.

This is the problem that logging levels are designed to fix. The console defines a number of logging levels, from "more verbose" to "less verbose", and a number of different logging functions that correspond to these levels, which are arranged in order of "severity" from informational messages, through warnings, to errors.

At a given logging level, only calls to the corresponding functions and functions with a higher severity will have any effect.

For example, if the logging level is set to "info", then calls to info(), log(), warn(), and error() will all result in output being written. But if the logging level is "warn" then only calls to warn() and error() have any effect, and calls to info() and log() are simply discarded.

This means that the same code can be more verbose in a development environment than in a production environment - you just need to arrange for the appropriate logging level to be set.

The complete set of logging levels is given in the table below, along with the set of functions that will result in output at each level:

Level Will log calls to:
all Any console method
debug debug(), error(), exception(), info(), log(), time(), timeEnd(), trace(), warn()
info error(), exception(), info(), log(), time(), timeEnd(), trace(), warn()
warn error(), exception(), warn()
error error(), exception()
off Nothing

Setting the Logging Level

The logging level defaults to "error".

There are two system preferences that can be used to override this default:

  • extensions.sdk.console.logLevel: if set, this determines the logging level for all installed SDK-based add-ons.

  • extensions.extensionID.sdk.console.logLevel, where extensionID is an add-on's Program ID. If set, this determines the logging level for the specified add-on. This overrides the global preference if both preferences are set.

Both these preferences can be set programmatically using the preferences/service API, or manually using about:config. The value for each preference is the desired logging level, given as a string.

When you run your add-on using jpm run (without --profile set) or jpm test, the global extensions.sdk.console.logLevel preference is automatically set to "info". This means that calls to console.log() will appear in the console output.

When you install an add-on into Firefox, the logging level will be "error" by default (that is, unless you have set one of the two preferences). This means that messages written using debug(), log(), info(), trace(), and warn() will not appear in the console.

This includes add-ons being developed using the Extension Auto-installer.