This is a screenshot of the AMO Editors dashboard, which we use to track the status of the AMO review queues. For the first time since I can remember, we are all green!

What does this mean? It means that all add-ons currently waiting in the queues have been waiting for less than 5 days. Also noteworthy is the fact that all queues have a length in the low double digits and even one in the single digits! They are normally in the hundreds, so this is quite impressive.

All credit goes to our add-on review community, the AMO Editors. Their continuous dedication and incredible competitiveness have brought us to a point that we could only dream of. And now to clear the rest of the queues…

Thank you!

My presentation is meant to be a starting point for those interested in add-on development. It contains many links on how to get started making extensions, GM scripts, SDK add-ons, Personas, Themes, and even mentions language packs, search engines and dictionaries. They include a trivial add-on that translates a string on a webpage, developed as a GM script, as an SDK add-on, and as an extension. Then I compare code complexity, flexibility, the security framework and other characteristics, trying to give developers a balanced view and good information on how to choose any of the above when building an add-on. Of course I can only gloss over the details during a 40-minute presentation; hence all the links. In the end of the presentation I briefly cover publishing on AMO, add-on monetization, and the plans for an add-on marketplace. I tried to personalize it a bit for the Chinese audience, so some things may not make as much sense.

The Q&A session was surprising, in that the developers who asked questions were very knowledgeable in add-on development and had very specific questions. Some had very well-established products and demoed some really advanced add-ons. There’s such great add-on development happening in China that I wish we had a much better communication channel with developers over there. That’s something we need to work on.

Overall, the trip was excellent. The presentation went well, I got in touch with a number of developers in the area, and most importantly we had plenty of time to talk to the Mozilla Online team. I discussed our add-on performance initiative with them, which is specially relevant for them given that the default Firefox install for China includes about 10 add-ons preinstalled. A number of them also joined the AMO Editors team, which is actively looking for new members. I’m really happy because there are many add-ons that are only testable in China, by people who understand the language and local websites.

And, of course, the food and the sights we managed to squeeze into one day of touring around were all fantastic. I’d like to thank the Mozilla Online team again for the invitation and organizing this very successful event. Special thanks to 张羽 (Rachel Zhang) for taking care of us. I’m sure she feels like on holiday this week

Random anecdote: I’m riding the subway by myself on the way to meet a friend who lives in Beijing, pointlessly trying to appear as if I do this all the time. Then some guy approaches me and starts speaking in what I assume was Mandarin, pointing to a cellphone he has in his hands. While I’m deciding how to react to this, I look at the phone and see a picture of me at the conference. Heh. It was just an attendant who was really happy to run into me in the subway. We managed to talk a little bit during the subway ride. Very friendly guy. So, there

• 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.

On Thursday, the update queue had about 80 add-on updates in line to be reviewed. This is a short as it’s been for a very long time. Today it stands close to 200 updates, and will continue to grow in the following couple of weeks. All authors are now rushing out updates because they just realized Firefox 3.6 is out.

Well, now it’s up to the editor team to catch up. It’ll take a while, I think. Authors that decided to update after the 3.6 release will now have to wait. It’s bad for everyone, and the result of bad communication. That’s something we’ll need to work on.

First of all, let me be very clear about this: there is no short term plan to eliminate the extension platform as we know it. XUL and XPCOM run deep in Firefox. They are Firefox. Eliminating the technologies that make extensions possible would require a rewrite of pretty much everything in the platform, which is massive. I’m not saying this couldn’t happen some time in the future (I don’t know, really), but it isn’t something that can be accomplished within a few weeks, or even a few months. It’s something that requires a great deal of planning and the collaboration of the whole community. Extension developers shouldn’t worry about their add-ons being obsolete overnight.

We should all look into the future, though. Not as something that we’ll have to accept, but as something we can shape. Jetpack and Personas are still experiments in many ways, and there’s much we can do to make them what we want them to be. I personally doubt they will ever reach the point where they will replace the current add-on options, but I am confident that they can come very close, and that’s a big win for everyone.

Jetpack

The goals of the Jetpack project are ambitious: no restarts for install / uninstall, a clean and more stable API, complete security, and a much easier development experience. They’re so ambitious that to think all of these can be accomplished while preserving the flexibility of the current platform would be naive at best.

There are no stable APIs. You can make higher abstractions that are less likely to change. But they will change. Jetpack only makes its add-ons dependent on its API, instead of the XUL/XPCOM platform. So, instead of updating your add-on to the next Firefox version, you’ll update it to the next version of Jetpack, which should happen much less often. That is of course assuming there will be some sort of versioning of the Jetpack API. If that’s not the case, well, then we have bigger problems to be concerned about.

Jetpack, unlike XUL and XPCOM, is not a fully open system. It can’t be. Not without sacrificing the security it’s meant to bring. As a secure system, it should be closed by default, enabling through its API only the features that are considered to be safe and necessary. This limits add-on creativity to the API designers’ imaginations, as opposed to the developers’. On the other hand, in the current system extensions can do pretty much anything. They can read, write and execute files. They can change your preferences and access your saved passwords. They can monitor your online activities and send information to third parties. The only real protection between you and the extensions you install is the review system that all of them have to go through in order to be publicly listed on AMO. A group of reviewers (also known as editors) make sure these extensions are safe to use and respect user choice. Which one is better? To me, the answer is simple: if it’s possible on Jetpack, use Jetpack. It’s simpler and safer. If it isn’t, then fall back to extensions, where you have almost limitless control.

Jetpack add-ons will be easier to develop, and it will be possible to install and remove them without restarts. This is a huge win for users and developers. Many, if not most add-ons will be easily portable to this new platform, and they will benefit from it. It remains to be seen, however, if highly complex (and extremely popular) add-ons like AdBlock Plus, NoScript and Firebug will be able to live in the Jetpack world. These extensions are strongly tied to the platform, and their interactions would be very hard to translate into a general use API. Maybe we can implement jetpack.magic.doWhatNoScriptDoes .

Personas

Personas are not even close to being a replacement for themes. Personas allow some very basic skinning using header and footer images and setting font colors for the main toolbox. Surely they could be extended to include images for the toolbar icons and some more advanced customizations, but that’s not the case now, and even then they wouldn’t be a complete replacement for themes. Themes can change the appearance of the application in very significant ways, and this can’t be accomplished without the complexity inherent in theme development. So, theme developers, you’re not done yet either.

The future

I think the future for extensions and themes is still bright. Jetpack and Personas have shown us how things can be different, and opening the field for new development and competition is a win for all.

There’s much we can do to improve the “classic” add-on world, in the area of documentation and tutorials, and even in the platform itself. We’re being shown how to improve. We should take this as a call to action, and improve. Let’s work on the platforms that will support the development of the future, but let’s not forget the ones that are still active and thriving.

Let’s not forget how we got here.

This discussion came up due to a denied update for Text Formating Toolbar 0.1.4.11. I was requested to come up with a POC that demonstrates how name conflicts can cause problems, so I created this add-on, which conflicts with Text Formatting Toolbar using seemingly harmless code. Here’s the link:

Name Conflict

If you install this with the Text Formatting Toolbar, you’ll notice that the bold, italics, code and color features are broken.

Here’s the code in my overlay:

window.addEventListener(
  "load",
  function() {
    window.setTimeout(
      function () {
        formatItalics = "i";
        formatBold = "b";
        formatColor = "white";

        formatCode =
          function(aString) {
            if (typeof(aString) != "string") alert('Invalid Code!'); }
      },
      100);
  },
  true);

As you can see, it’s fairly simple. The load event and setTimeout call are only used to make sure that it is the other extension and not this one the one that experiences the compatibility problems. If two add-ons use the same names in the global scope, then one is going to experience problems in one way or another. There’s nothing more to it.

Obviously I can intentionally create an add-on that causes conflicts with any other add-ons, but I hope you see past this and realize that the code I posted could very well be written by another author who is unaware of the rules we enforce. This is what we look after, and this is why we should reject global namespace pollution in almost all instances.