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.

This article documents the self object that is available as a global in content scripts. self provides:

  • access to the options object
  • access to the port object
  • access to a mostly deprecated messaging API

For an overview of content scripts, see the main article.

Note that the self object in content scripts is completely different from the self module, which provides an API for an add-on to access its data files and ID.




Content-scripting APIs such as tab.attach(), page-mod, and page-worker let you pass read-only data to the content script as a JSON object via the contentScriptOptions option. If you do this, the data is available to the content script in the options property of self:

// main.js

const tabs = require("sdk/tabs");{
  url: "./page.html",
  onReady: function(tab) {
      contentScriptFile: "./content-script.js",
      contentScriptOptions: {
        a: "blah"
// content-script.js



You can use port to receive messages from, and send messages to, the main add-on code. See the documentation for port.


The self object has four methods, which enable the content script to send messages to, and receive messages from, the main add-on code.

This is an older API than the API provided by port, and for most purposes the port API is a better choice. The exception is the context-menu module, which still uses postMessage.


Send a message from a content script to a listener in the main add-on code:


This takes a single parameter, the message payload, which may be any JSON-serializable value.


Start listening to messages from the main add-on code:

self.on("message", function(addonMessage) {
  // Handle the message

This takes two parameters: the name of the event, and the handler function. The handler function is passed the message payload.


Exactly like on(), but stop listening after the first message is received.


Remove a listener to an event. This takes two parameters: the name of the event to stop listening to, and the listener function to remove.