SDK 1.4: known issue with hard-coding resource URIs

The Jetpack project released Addon SDK version 1.4 yesterday; this release is likely the most significant release of the SDK since 1.0 in June, and includes a number of improvements. One of the improvements was a change to simplify the internal file & folder structure of the xpi packages the SDK creates. This work was tracked in bug 660629.

One side-effect of this change is that the resource urls for files in the data folder of an add-on have changed. If you have created an add-on and for some reason hard-coded a resource url into your code, you will need to change your code in order for your add-on to work when packaged with SDK version 1.4.

While the release notes go into this issue in detail, I would like to highlight here the two main examples we are seeing in the wild of hard coded resource uris, with strategies for working around each.

1. Hard coded resource uris in main.js

Addon authors occasionally reference html and javascript files in the addon’s data directory directly via a hard-coded string:

var myPanel = require("panel").Panel({
  contentURL: "resource://jid1-294x0ji6mesjag-at-jetpack-example-data/my-file.html",
  contentScriptFile: "resource://jid1-294x0ji6mesjag-at-jetpack-example-data/my-script.js"

You should always use the method instead:

var data = require("self").data;
var myPanel = require("panel").Panel({
  contentURL: data.url("my-file.html"),
  contentScriptFile: data.url("my-script.js")

2. Hard coded resource uris in html or css files inside the data directory.

Referencing a css or image file from an html or css file in the addon’s data directory does not require the entire resource uri path because these resources can be referenced with relative paths. Instead of doing this:


…all you need to do is this:


If you have created an SDK-based addon and have included some hard-coded resource uris in your code, you will only need to make changes to address this issue if you re-package your addon with 1.4. As we are not re-packing addons on AMO automatically for this release, there is no immediate need to update your code.

It is possible 6 weeks from now that we will re-pack all addons to use SDK 1.5, and at this point any remaining addons using hard-coded resource uris will stop working. To mitigate this we are working with the AMO team to identify all affected addons and contact addon authors directly to encourage them to update and use the best practices I demonstrated above.

6 responses

  1. Aris wrote on :

    Does this “issue” affect bootstrapped add-ons with resource uris too?

    I’m using similar code like this:

    function startup(aData, aReason) { let resource =“resource”).QueryInterface(Ci.nsIResProtocolHandler); let alias =; if (!aData.installPath.isDirectory()) alias =“jar:” + alias.spec + “!/”, null, null); resource.setSubstitution(“myaddonpackage”, alias); … }

    function shutdown(aData, aReason) { if (aReason == APP_SHUTDOWN) return; let resource =“resource”).QueryInterface(Ci.nsIResProtocolHandler); resource.setSubstitution(“myaddonpackage”, null); …

    where code like this one can be used:



    1. Jeff Griffiths wrote on :

      This issue should *not* affect restart-less addons, it only affects SDK-based addons.

  2. Asi wrote on :

    Hi, unfortunately none of the above options works for me..
    it previously worked with the resource uri, but now – nothing.
    the images are located in the data folder, not in the lib. so I’ve tried the direct reference – can’t load the image. I don’t get an error in the console or something like that.
    I’ve upgraded to firefox 10, compiling with sdk 1.4 (tried 1.4.1, 1.4.2 as well).
    any idea?

    1. Jeff Griffiths wrote on :

      Here’s an example that load an image into a panel from the data folder – for anything in the data directory you can just use relative paths, right?

      1. John Nagle, Silicon Valley, CA wrote on :

        Error 404: “We’re sorry, but we can’t find what you’re looking for.”

        1. Jeff Griffiths wrote on :

          Hi John!

          Sorry – builder changed all of its urls at some point and failed to do forwards properly.

          That example is now here: