Category: Extensions

I just put together a simple restartless add-on, Cloud Viewer, that integrates the Google Docs Viewer into Firefox Mobile. I saw a few similar add-ons on AMO for desktop Firefox, but none for Firefox Mobile. Opera and Dolphin also have add-ons integrating support for online document viewers.

The concept is pretty nice, especially for mobile devices: Open online documents in an online viewer. No need to waste time downloading the file and waste space on your device saving the file. Google’s viewer supports Powertpoint (PPT), Word (DOC, DOCX), Excel (XLS, XLSX), PDF and some non-web image formats. The viewer even uses a mobile UI when running on devices.

Restartless Fun – The Details

I wanted the add-on to be restartless because restartless add-ons rock. I also wanted the add-on to work at a deeper level than a context menu. I could have put a menu item on the context menu to open links in Google’s viewer, but that wouldn’t work on links that weren’t directly pointing to the file – think Google search results. The link Google gives you in a search result redirects you to the actual file, so a context menu item wouldn’t be the best solution. The redirection issue occurs more than you think on the web. Instead, I override an XPCOM component the controls how Firefox treats files the browser doesn’t natively handle. Normally, this component (nsIHelperAppLauncherDialog) starts a file download and will open the file using a local application.

Cloud Viewer overrides the component. I check the extension of the direct URI to the file and if supported, I ask the user if we should open the file in an online viewer. Since the add-on is restartless, I can’t use the normal method of registering JS XPCOM components. I have to manually register and unregister the component myself. This worked fine and was pretty easy. See the source code.

I really think we should be writing more restartless add-ons, especially the simple ones. Great UX and a really small download. Only 2.5KB XPI file for Cloud Viewer. The internal support for restartless add-ons will only keep getting better.

I saw a neat technique in Bug 564675 for creating default preferences in bootstrapped add-ons. Edward Lee posted a link to some code he uses for a bootstrapped add-on. Essentailly, the default preference branch is writable, but not permanent. This is a good thing for bootstrapped add-ons. The add-on should write it’s default preferences every time it loads and the preferences disappear when the session ends. The code looks like:

const PREF_BRANCH = "extensions.myaddon.";
const PREFS = {
  someIntPref: 1,
  someStringPref: "some text value"
};

function setDefaultPrefs() {
  let branch = Services.prefs.getDefaultBranch(PREF_BRANCH);
  for (let [key, val] in Iterator(PREFS)) {
    switch (typeof val) {
      case "boolean":
        branch.setBoolPref(key, val);
        break;
      case "number":
        branch.setIntPref(key, val);
        break;
      case "string":
        branch.setCharPref(key, val);
        break;
    }
  }
}

function startup(aData, aReason) {
  // Always set the default prefs as they disappear on restart
  setDefaultPrefs();
  ...
}

I haven’t tested to see if there is a clean way to remove these preferences when a bootstrapped add-on is disabled or uninstalled. The default preferences will likely still hang around until a shutdown occurs.

We’re starting to amass a sizable collection of code snippets for bootstrapped add-ons. I think a new section in the MDC Code Snippets area might be needed.

After playing around with bootstrap (restartless) add-ons a bit more, I came to the point where I needed some extra resources in the add-on. For images, I could have stuck with the data: URI approach I mentioned previously, but I also wanted to add an options UI for my add-on. Turns out it was pretty simple. Thanks to Vlad for getting the ball rolling.

The trick I am using now is to programmatically add a resource: alias for my add-on. A resource: alias creates a handy way for you to create URIs pointing to resources, like scripts and images, in your add-on bundle. It’s pretty simple to add a resource: URI pointing to the add-on’s root folder or XPI bundle. Here is the code snippet taken from my bootstrap.js file:

function startup(aData, aReason) {
  let resource = Services.io.getProtocolHandler("resource").QueryInterface(Ci.nsIResProtocolHandler);
  let alias = Services.io.newFileURI(aData.installPath);
  if (!aData.installPath.isDirectory())
    alias = Services.io.newURI("jar:" + alias.spec + "!/", null, null);
  resource.setSubstitution("myaddonpackage", alias);
  ...
}

function shutdown(aData, aReason) {
  if (aReason == APP_SHUTDOWN) return;

  let resource = Services.io.getProtocolHandler("resource").QueryInterface(Ci.nsIResProtocolHandler);
  resource.setSubstitution("myaddonpackage", null);
  ...

The isDirectory check is needed because it is possible for add-ons to be installed in folders or XPI bundles, which require the jar: URI syntax. The code adds a resource alias, after which you can use URIs like this:

resource://myaddonpackage/images/someimage.png
resource://myaddonpackage/content/somescript.js

In these examples, images and content are folders inside your add-on bundle. Now you can add URI-based resources to your install.rdf like this:

  ...
  resource://myaddonpackage/content/icon.png
  resource://myaddonpackage/content/options.xul
  ...

Yes, the em:optionsURL works just fine for providing an options UI in your add-on. I hope this tip gives you more help converting your traditional add-on to a restartless add-on.

Updated: I added the removal of the resource: alias on shutdown based on feedback from Nils in comments. Check out his link to some great bootstrap add-on information too. The part about stale caches after an add-on update presents a painful problem. Waldimir has also previously posted about the limitations of bootstrapped add-ons.