Since I already had a working desktop extension, the amount of coding needed was fairly small. However, I did encounter several difficulties along the way, which I think are worth documenting. Here’s how it went.

Documentation

The first thing I looked for was documentation. It’s not hard to find the Mobile documentation page if you know that the Mozilla Developer Network exists. That’s a good hub with useful tidbits, although it could use some cleanup and consolidation. Many of its useful links lead to the Mozilla wiki, outside of MDN, and they are written in the format you expect for the wiki, not MDN. The Fennec Extensions page covers some of the basics, but it fails to say how to create a basic overlay. Something many developers need to know to get started is which chrome path is necessary to overlay. I believe it’s the same path as in Firefox, but I ended up not using an overlay at all.

UI

Figuring out the UI for my port was one of the most difficult steps. In Firefox I just add a menu item that opens the main management window. My extension also has a few extra windows for advanced features, but early on I decided not to support them in the mobile version.

The only UI area you really have available is the content, so I decided to create an about:remotexul XUL page. This requires registering a JS component instead of an overlay, and the component just tells Firefox to redirect about:remotexul to a XUL page in my chrome package. So, instead of clicking on a menu item, the user has to type this URL. Not terribly user-friendly, but not that bad either. I considered adding a button somewhere, but gave up almost immediately.

Which leads me to a few questions about mobile add-on development. Firstly, how can we expect add-ons to be built for mobile if there is no place for them in the UI? Do we only want add-ons that work silently in the content? And (more importantly IMO) are we applying the same philosophy for tablets? It seems that, at least in terms of add-ons and UI space, mobile phones and tablets are entirely different playgrounds.

My take on it is that we need an Add-on Bar for both. The panel on the right-hand side can afford one more button, and this button could toggle another panel where add-on buttons can live. A similar approach could be used for tablets, but in their case I think the toolbar could be enabled by default (provided it has buttons in it). Having no way to add UI is a gigantic obstacle in the way of add-on creation for mobile. The possibility of improving performance through more native UI toolkits is also a looming obstacle that we’ll need to tackle.

As a minor side note, I noticed some drawing oddities when panning my XUL document in the content area. I guess XUL content hasn’t been given enough attention on mobile, so if you want to take this same approach, you might want to consider using HTML instead.

Testing environment

Getting Mobile Firefox set up was much more difficult than I expected.

Since there’s a desktop emulator of Mobile Firefox and I didn’t have any supporting mobile devices at the moment, this was my only way to test. So I went to the main Mobile page to download the emulator. Oddly enough, this page offered (and continues to offer) version 4.0.1, which is a few releases old by now. The “See all our channels” link takes you to the desktop Firefox channels page, and changing firefox for mobile in the URL leads to a 404.  So I downloaded 4.0.1, and one of the first things I tried was to check for updates. There were none.

Hmm, ok, so I needed to do a little hunting for the emulator. Luckily, the MDN page has a direct link to the FTP site, with all builds for all platforms. So I downloaded the Mobile Firefox 6 emulator for Mac OS. I fired it up and everything looks OK until I try to load a page. Any page turns up blank. So I go to the #mobile channel on IRC and ask around. I am told to use Linux instead… But I also got a useful bug link. It turns out that the switch to multiple processes for Mobile Firefox broke the Mac OS build, and I guess it’s not such a big priority to get that sorted out. I suppose that this bug will get more attention once desktop Firefox goes multi-process for content.

At this point I realized I was going the about: page route for the UI, so I was able to test and debug most of the port in desktop Firefox. Then the Mozilla All Hands came along and I got a new Asus Android tablet for testing, so no more emulation for me .

The build-install-test cycle was really slow for me, though, since the easiest way to get the extension installed is to upload it to some public URL and install it using InstallTrigger (a bit of JS magic used to install add-ons from HTML). If you can use the emulator in your system, though, file:// URLs work fine as a shortcut.

Tools

I also felt the lack of development tools, some of which are key to add-on development.

I commonly used the FUEL library in my add-ons. Since it isn’t supported on mobile, I had to get rid of that code. Luckily, it wasn’t much I needed to change. There is ongoing work to port Jetpack to mobile, so that will probably become the best set of libraries available for add-ons in the future. For now I’ll just plug to components directly.

DOM Inspector is another tool I use heavily. But, is it even possible to have something like DOMi on mobile? Maybe on the tablet version, but certainly not on a phone… However, I think there are ways around this. It should be possible to integrate DOMi into the emulator. You can have it open in a separate window and inspect the mobile UI from there. Another random idea I have is to wrap the Mobile Firefox emulator as an extension you can install in desktop Firefox, so you get the benefits of all development tools that are already part of Firefox. I’m not sure if that’s feasible, though.

Conclusions

There are still many rough edges when diving into mobile add-ons for Firefox, some of which I think are not hard to fix. But there are also hard problems to solve, and hard questions to ask: does it make sense to support such a wide variety of add-ons in a mobile phone browser? And what about tablets?

This is an almost exhaustive list of the problems I encountered while porting my add-on, so I hope it isn’t taken the wrong way. The truth is that most of my code worked without any modifications. It is very satisfying to be able to support even more users of my add-on, and to have one of the few desktop+mobile add-ons around. Plus, tinkering around with code, failing and then succeeding is just plain fun .

Remote XUL Manager 1.1 is the first version that supports mobile, and it’s currently waiting to be reviewed (irony!). You can give it a try on this page.

I’d love to hear what others have to say about trying to port add-ons to mobile. If you have any similar stories, please share them in the comments.

• Remote XUL Manager has taken most of my spare time. It’s been exciting just because it’s a fairly new project and it had a pretty well-defined goal, which was reached only a few days ago. Version 1.0 was released on March 10th, and it does every I planned for this add-on to do. There are a couple of feature requests that I will consider in due time, but they’re pretty minor and I’m satisfied with the current state of this project.
• Fire.fm has taken the back seat. In the past few months all we’ve done is update locales, clean up some code, and push a few bug fixes (and then fixes on the fixes, and so on…). We have some plans for version 1.5, but it’s getting harder and harder to find the time for this. Specially because Last.fm keeps closing down their service and that has a very negative effect on my motivation. If it weren’t for the people that still use it – close to 200K – I would have abandoned this add-on a long time ago.
• My Add-on Packaging Proposal for the Google Summer of Code never gained any traction. Unfortunately the project was abandoned by the student assigned to it, so the whole idea stalled and was discarded. Now I’ve been approached by somebody who is interested in working on it. That’s very encouraging, but I need to give this some thought. I’ve been planning on reviewing the whole spec and giving it an overhaul based on all the stuff that has changed with Firefox 4 and the feedback I received. I’ll post here when (and if) I have an updated draft.
• The band I help as Executive Producer, Pneuma, has had a great deal of success locally, and they’re getting ready to tour Mexico and Europe. It’s very exciting times for them and I’m glad to be a part of this.

It’s been crazy times for me and the AMO Editor team. We had a very successful competition that yielded a incredible throughput and over 2500 reviews by the top 4 winners alone. And yet we’re still swamped with review submissions due to the upcoming Firefox 4 launch and the mass disabling of sandboxed add-ons, which resulted in a great deal of new submissions of old add-ons.

I have a bunch of ideas for new add-ons that I wish I had the time to work on. For now, I just write them down on my Someday list and wait

A while ago I suggested a different packaging system for add-ons that would (arguably) make it easier to work with. I proposed it as a project for the Google Summer of Code, and it was accepted. That was kind of unexpected, and I was very excited to be part of that experiment. There was a good student submission for the project and everything looked well underway.

Fast forward a few months, and I was contacted by the student working on the project. He wanted to drop it due to lack of time and progress . After chatting for a while, I agreed with him that dropping it was for the best. In the end the problem was a mixture of poor communication and a scheduling mismatch between the summer break in the US and other countries (Brazil in this case). He just couldn’t focus on the project due to school work.

So, the experimental implementation never happened, but the idea lives on. The project’s approval motivated me to create a pretty decent spec that I’ll update once Firefox 4 is released. Many changes have been introduced in Firefox 4 that affect manifest files, and others that overlap with some of the proposed features. Once Firefox 4 is stable for add-on developers, I’ll update the wiki and probably post an update here. I don’t have any plans to implement this or push the idea too hard, but I still think there’s some value there and it’s worthwhile to keep it alive.

At the moment I’m writing the complete manifest file specification, basically copying and adapting the current specifications for install manifests and chrome manifests. I’m pretty much done with the former, and will be adding the latter probably tomorrow.

After receiving lots of feedback regarding the manifest format, I agreed to take the manifest file the XML way. I followed JJ Barton’s suggestion of using HTML instead of a custom XML format, which leads to a very simple and familiar manifest format, with some very nice visualization options. This is the first time I’ve used the :before pseudo-class and the CSS content property, and I must say that they blew me away, limited as the latter is. Cool stuff.

If you want to discuss the pros and cons of the HTML manifest format, please fire away in the comments. I will be adding more content to the wiki as the project progresses.

Part 3 – Installation

Add-on performance has been a hot topic recently, given that add-ons are a significant contributor to slowdowns, specially at startup. One of the reasons I’ve seen mentioned is how extensions are laid out in the file system after installation. The suggestion is to educate developers on how to package add-ons taking performance into account. That’s not a bad approach, but I think it’s easier for developers and more effective in general if the post-install procedure handles performance optimizations. This might even be necessary, considering that different applications and different platforms can have different ways to optimize for performance.

The add-on installer should package most if not all files into a single, uncompressed JAR file, as suggested in this bug report:

• Add-ons in the new format should not have internal chrome JARs.
• All files that can be efficiently read from a JAR file will be moved into a single uncompressed JAR (like a TAR) upon installation. This is a single JAR for all add-ons using the new system. One possible “cheat” to accomplish this is to create a fake add-on install directory, with a single JAR and a generated manifest that includes the information for all add-ons contained in it. This manifest could even be an “old style” chrome.manifest, in case changing chrome resolution rules turns out to be too difficult.
• Files that can’t be put in the JAR (this is mentioned in the bug report, and I don’t know why this is the case), such as binary libraries and components should ideally be grouped together in the same place where the big JAR will be located. One concern here would be file name collisions and the way these files are automagically loaded from their special folders, which may be hard to overcome. In case this is too difficult, it’s probably best to lay them out like it’s done now: on their separate extension directories.

From a performance perspective, this is what makes most sense for all platforms as far as I know, so it would be the default and maybe only behavior. However, if different packaging requirements come up for specific platforms, it can and should be implemented, with the great advantage that it will be possible to do so, at least with add-ons using the new system.

Spec corrections

• By far, the most debated point in this spec has been the format chosen for the manifest. I’m convinced now, JSON was not the right way to go. I really like John J Barton’s idea of an HTML manifest, so I think I will pursue this approach. It makes sense due to familiarity, IDE support and even skinability. Somebody mentioned that I should also cover update.rdf and McCoy. This will be done in the new XML-based spec, and it should be very straightforward.
• In part 2 I mentioned that having internal JARs would still be possible. I’m reconsidering this decision. Since the new format is meant to be a fresh start in several regards, I’m thinking it would be a bad idea to drag these old practices back, considering that they would have a negative effect on the post-install process.

The final project spec will be moved to a wiki, where it makes more sense to have a document that will likely see many iterations and corrections. I will being working on this as soon as possible, and will post a link in this blog once there’s something everybody can look at.

I will also post updates when there’s more progress on the project.

Acknowledgements

• Google, for creating the very cool GSOC and keeping it alive for many years.
• Gerv, choffman, and all GSOC admins.
• Hebert Duarte, for volunteering to implement this project.
• Everyone who has been posting comments and giving me feedback. It’s all very valuable and not a single comment has gone unread.

Thank you all!

Part 2 – URL resolution

Here’s a simple chrome.manifest file, as exemplified in part 1:

content   xulschoolhello              jar:chrome/xulschoolhello.jar!/content/
skin      xulschoolhello  classic/1.0 jar:chrome/xulschoolhello.jar!/skin/
locale    xulschoolhello  en-US       jar:chrome/xulschoolhello.jar!/locale/en-US/

overlay chrome://browser/content/browser.xul  chrome://xulschoolhello/content/browserOverlay.xul

There are two things I find silly about it:

1. The file and directory structure is too complicated for a simple add-on. It could be simpler, but the form above is the current recommended way of doing things.
2. If this is the default, recommended way of doing things, then why is it necessary to explicitly declare it?

This part of the specification aims to remove as much redundancy as possible from chrome (and other) declarations, as well as provide sensible defaults so that simple add-ons are simple to develop.

The simplest manifest

Let’s begin with the new manifest file introduced in the previous part of the spec:

{
  "id" : "helloworld@xulschool.com",
  "name" : "XUL School Hello World",
  "description" : "Welcome to XUL School!",
  "version" : "0.1",
  "authors" : "Appcoast",
  "homepageURL" : "https://developer.mozilla.org/en/XUL_School",
  "type" : "2",
  "targetApplications" : {
    "id" : "{ec8030f7-c20a-464f-9b0e-13a3a9e97384}",
    "minVersion" : "3.0",
    "maxVersion" : "3.6.*"
  },
  "domains" : "xulschoolhello",
  "overlays" : {
    "source" : "chrome://xulschoolhello/content/overlay.xul",
    "target" : "chrome://browser/content/browser.xul"
  }
}

A couple of notes before diving in:

• There’s an ongoing discussion of what format is best for the manifest, JSON or some form of XML or HTML. Examples are being presented as JSON but could change eventually. If you want to join the discussion, please do so in Part 1.
• The “domains” property is now plural, as it should be. (Thanks Wladimir!)

The highlighted sections are the equivalent of the chrome.manifest file presented above. The “domains” declaration covers the “content”,  “skin” and “locale” declarations in the old format. However, the file layout also needs to change, since the defaults for the new format are much simpler than in the old one. Here are the default resolutions for all URLs and other special folders:

• “content” and “skin” URLs default to the root directory, where the manifest file is located. This means that the simplest of add-ons would consist of the manifest file and an overlay file zipped together. Complex add-ons would of course require directory structures in order to keep everything organized, but that’s left to the authors to determine.
• “locale” URLs are a little more involved. If the author only wishes to ship the add-on in one locale, then the locale files can be located in the root directory, just like “content” and “skin” files. If there are more languages, they can be organized under “/locale/en-US/” and similar. The “locale” directory in the root would have that special meaning, and all directories within it are considered locale folders and are automatically registered. There’s no need for chrome declarations even in this case.
• “resource” URLs will also default to the root directory, and will use the same domain. In the example extension above, “resource://xulschoolhello/hello.jsm” would point to the “hello.jsm” file in the root of the add-on package.
• The “components” and “platform” folders will continue to have their special meaning.
• The default preferences file will be named “defaultPrefs.js” and will also reside in the package root.

Advanced manifests

The defaults defined above should be adequate for most add-ons I’ve ever seen (and I’ve seen a lot!), but we can’t leave out add-ons that require more than this. It’s very important that the new system is as flexible as possible for authors, and that add-ons can be migrated to it without requiring significant changes or refactoring.
First of all, the “domains” attribute can be extended to include declarations similar to old-style manifests. Here’s the equivalent of the first chrome.manifest declarations in the first example:

"domains" : {
  "name" : "xulschoolhello",
  "content" : {
    "location" : "jar:chrome/xulschoolhello.jar!/content/"
  },
  "skin" : {
    "location" : "jar:chrome/xulschoolhello.jar!/skin/"
  },
  "locale" : {
    "locale" : "en-US",
    "location" : "jar:chrome/xulschoolhello.jar!/locale/en-US/"
  }
},

Some notes about this expanded format:

• “domains” can be an array, in case multiple domains need to be defined.
• The name of the skin is still redundant, so there’s no need to specify it.
• “content”, “skin”, “locale” and “resources” can be arrays, to specify multiple entries.
• “content”, “skin”, “locale” and “resources” support a “flags” attribute, in order to support manifest flags. This attribute can also be specified on overlays, overrides and style declarations, which are not exemplified but are the same as the overlay declaration shown before.

Moreover, it should be possible to change the locations of any of our “special” files and folders, in order to give developers maximum flexibility. For this, the manifest can have a “locations” attribute, exemplified here:

"locations" : {
  "defaultPrefs" : "prefs/myPrefs.js",
  "components" : "code/myComponents/",
  "platform" : "code/platform/"
},

The only file that has a mandated name and location would be the manifest file. The rest can be organized to the authors’ preference, provided they don’t like the defaults and they want to tinker with the manifest.

Manifest Localization

Localizing manifests is an arduous task. The most modern way to do it involves adding all the localized information in the manifest file, which isn’t yet supported by the most popular add-on localization community, Babelzilla. Keeping the manifest properly localized becomes a burden to add-on developers, and most don’t even bother.

The suggested solution in the new system is to take advantage of the existing localization infrastructure. The manifest localization file will default to the location “chrome://firstDeclaredDomain/locale/manifest.properties”, or can be explicitly defined (needs to be a chrome locale URL):

"localized" : "chrome://xulschoolhello/locale/manifest.properties",

This localized file would hold strings corresponding to the localizable attributes:

name = Hola Mundo de XUL School
description = Bienvenido a XUL School!
translator.1 = Jorge
translator.2 = Somebody else

The .1 and .2 suffix is just a way to handle multi-valued attributes.

Moving this information out of the manifest has one drawback: the add-on installer needs to do some additional effort to show these values during installation, since it will require to figure out the location of the localized file. This isn’t too hard to figure out using the manifest, though, and the advantages outweigh a few additional ms during installation.

Part 3 of this specification will cover add-on installation and any pending topics. It will also introduce a wiki page where the full spec will be fleshed out and all edge cases will be covered.

Part 1 – The Manifest File

Most add-ons rely on 2 manifest files: install.rdf and chrome.manifest. The install manifest holds add-on metadata such as its name, description, icon path and compatibility information. The chrome manifest determines where to locate chrome files under different circumstances (OS, application, version, etc.), as well as overlays, skins and locales.

These files are written in very different text formats, and they are not completely independent from each other. For example, the install manifest uses chrome paths to locate the extension icon, preferences window and about window, if defined. Install manifests also hold localized data which hasn’t been integrated properly into the add-on localization system. It’s also worth noting that the average add-on has very short and simple manifest files, including a significant amount of boilerplate code.

In order to simplify the packaging system, both manifest files should be merged into a single file. The file specification should allow for the least amount of unnecessary declarations that is possible, so that simple add-ons are simple to make. It should also be robust enough not to limit complex add-on creation, and it should cover every single non-obsoleted feature of both current manifest files. It should work for all add-ons that currently use the XPI format: extensions, themes, locale, and multi-item packages.

The chosen format for the manifest file is JSON. The reasons behind this decision are:

• JSON is a very compact and easy to read format.
• It’s widely used and well known.
• Firefox and Mozilla-based applications already include a fast and safe JSON parser.
• The Jetpack project uses JSON for its manifest file, and using the same base for all add-ons helps maintain consistency and ease switching between platforms if needed.

The only major disadvantage is not being able to comment in JSON files. There are workarounds, but they’re not very pretty.

The manifest file will be named manifest.json. It’s not package.json like previously speculated because it doesn’t serve the exact same purpose as package manifests in Jetpack, and it would cause confusion about the meaning of packages. It’s not install.json because it could be easily confused with the old install.js manifests.

The presence of manifest.json in the XPI file will indicate this file needs to be handled as a v2 package. If manifest.json isn’t found, the current install system should be used. XPIs should be able to include old and new manifest files in order to be backward-compatible with application versions that don’t support the new system.

A simple manifest file

A very simple Hello World add-on (taken from XUL School) would have the following manifest files.

install.rdf

<?xml version="1.0"?>

<RDF xmlns="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
  xmlns:em="http://www.mozilla.org/2004/em-rdf#">
  <Description about="urn:mozilla:install-manifest">
    <em:id>helloworld@xulschool.com</em:id>
    <em:name>XUL School Hello World</em:name>
    <em:description>Welcome to XUL School!</em:description>
    <em:version>0.1</em:version>
    <em:creator>Appcoast</em:creator>
    <em:homepageURL>https://developer.mozilla.org/en/XUL_School</em:homepageURL>
    <em:type>2</em:type>
    <em:targetApplication>
      <Description>
        <em:id>{ec8030f7-c20a-464f-9b0e-13a3a9e97384}</em:id>
        <em:minVersion>3.0</em:minVersion>
        <em:maxVersion>3.6.*</em:maxVersion>
      </Description>
    </em:targetApplication>
  </Description>
</RDF>

chrome.manifest

content   xulschoolhello              jar:chrome/xulschoolhello.jar!/content/
skin      xulschoolhello  classic/1.0 jar:chrome/xulschoolhello.jar!/skin/
locale    xulschoolhello  en-US       jar:chrome/xulschoolhello.jar!/locale/en-US/

overlay chrome://browser/content/browser.xul  chrome://xulschoolhello/content/browserOverlay.xul

The equivalent manifest file in the new system would be the following.

manifest.json

{
  id : "helloworld@xulschool.com",
  name : "XUL School Hello World",
  description : "Welcome to XUL School!",
  version : "0.1",
  authors : "Appcoast",
  homepageURL : "https://developer.mozilla.org/en/XUL_School",
  type: "2",
  targetApplications : {
    id : "{ec8030f7-c20a-464f-9b0e-13a3a9e97384}",
    minVersion : "3.0",
    maxVersion : "3.6.*"
  },     
  domain : "xulschoolhello",
  overlays : {
    source : "chrome://xulschoolhello/content/overlay.xul",
    target : "chrome://browser/content/browser.xul"
  }
}

The (not really) missing chrome declarations will be covered in part 2 of this specification.

Plural attributes in the manifest file (authors, targetApplications, overlays, and others) can either be a single value or object, or an array of them. So, if there were multiple authors to the add-on, the following would also work:

authors : [ "Appcoast", "Mozilla" ],

Part 2 of this specification will attempt to cover all possible attributes in the manifest file, as well as attribute localization.

But then the Google Summer of Code came to the rescue. I believe Gerv mentioned it in one of our weekly all hands meetings, and I thought “it’s a long short, but what the hell”. I just threw the idea into the candidates list. In a matter of a couple of weeks, the idea went from candidate to proposal, to approved proposal, to approved proposal with an assigned student. So, this summer, Hebert Duarte from Brazil will be working on the add-on packaging idea, and hopefully we will have a working implementation within a couple of months. That’s awesome!

Now it’s my responsibility to guide Hebert in the right direction, and to give him all he needs to get this project going. For that I will be posting a more detailed specification of the new add-on packaging system, to try to cover the quirks and special cases that need to be addressed. Expect it to appear on this blog very soon. Coding begins on May 24th, so I want to have everything figured out by then. Your feedback as usual is welcome.

Note that having a working implementation doesn’t guarantee it will become part of Firefox or other applications any time soon. At the moment there are no plans or expectations of when and if we will be including this into the Mozilla code base. That’s a whole other project

I keep feeling the same about a side project of mine that began shortly before I joined Mozilla. A long time friend of mine has lead a heavy metal band called Pneuma for quite a few years now. They had to break ties with their production company recently because of unacceptable delays on their part, and lots of the typical crap professional musicians have to deal with. They were looking for people to invest in the independent production of their next album, and I guess I was just in the right place at the right time.

Of course I wouldn’t invest in them if I didn’t think they were really good.  I have great expectations for their upcoming album and I’m helping them in every way I can. The best way I can help them is by bringing my knowledge of the web and technology to the table. So far I’ve helped them set up their temporary website and twitter account. I will also be helping them out with their online distribution, because not having your album listed on the iTunes Store is a very new and very big mistake a band can easily make.

But I digress. The point of this post is that I decided to use HTML5 on their site, and provide their first single in open OGG/Vorbis format (falling back to MP3 and Quicktime), with the added bonus that the band agreed to have the track available for download and free distribution. So anybody can listen and download the track in their preferred format, MP3 or OGG. The audio player looks fantastic on the site, by the way. Much better than QuickTime or WMP plugins. The audio quality is also great, and the file is much smaller than its MP3 counterpart.

Adding also to the surrealism of the whole “music producer” side of my life is the fact that Pneuma will be the opening act at the first Metallica concert in Costa Rica, next Sunday. This is the biggest concert in Costa Rican history, and I’m pretty sure I’ll be backstage. I haven’t really taken that in yet, there’s just too much work to do before the concert. But WOW.

If you like thrash / progressive metal, I recommend you visit http://pneumametal.com/ and have a quick listen. I think you’ll be pleasantly surprised.

1. Most of all, I’ve been contributing to the AMO editor team to keep the add-on review queues down to a manageable size. There’s a great deal of new submissions and updates due to the release of Firefox version 3.5. There are hundreds of updates that are minimal to non existent compatibility changes, so I’ve been able to review close to 200 updates on this month alone. I enjoy my work with the editor team, specially because I’ve very fond of doing code review and being ruthlessly critical. It’s in my nature, what can I say… There are plans for removing the AMO sandbox, which I find intriguing, to say the least. I wonder how that will change the editor group and their work.
2. The Extend Firefox 3.5 competition has been officially announced. With an October deadline, it includes several new interesting categories to compete in. Jose and I are already working on Fire.fm 1.3, which will be our entry for best extension update. There’s a great deal of new features we’ll be putting into it, which I think will greatly improve our user experience. We’re also working on a few ideas for new add-ons. I hope to be able to submit a couple of entries to increase our chances of winning.
3. Finally, the Add-ons Contributions pilot was introduced to AMO. This enabled add-on authors to request donations for their project right on AMO, giving our donation links more exposure and possibly allowing a few authors to remove donation requests from their add-on UI, which is always a loss for user experience. We have activated contributions for Fire.fm, and so far the response has been pretty good. We’re very happy about it and hope people will continue helping us out.

I still feel in ‘break mode’, and hope to start working in full gear soon. There’s so much I want to do, and I still need to get everything sorted out. More updates soon!