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!

Discuss!

People saying that this discussion is pointless neglect that Firefox is one more thing. It’s a platform, and most add-on developers rely on it. Version numbers matter to add-on developers because the add-on compatibility system relies on application version, not features. And since the features are pretty much every access point in the platform, doing feature detection is not realistic. So, if you’re an add-on developer and you want to keep your add-on up to date, you’ll have to test and increase its compatibility every six weeks, potentially having to make code changes.

On AMO, we have implemented a system where we automatically detect which add-ons are compatible with the latest Aurora version (the version that is between 12 and 6 weeks from release) and then upgrade those that do. All developers for the tested add-ons should get an email explaining their add-on was upgraded, and if not, why. This has been fairly successful, and we have a high compatibility percentage (relative to usage) at the moment (it’s even higher if you ignore the .NET Assistant, which could be compatible now). However, there are still many popular add-ons that aren’t compatible, specially those hosted elsewhere. And the burden on those who develop add-ons with binary components is pretty much constant, because they’ll have to update their add-ons every 6 weeks, with no exception.

So, while only a small percentage of add-on usage consists of add-ons that are incompatible (hovering something between 10% and 20%, I think), the probability that one of our add-on users has at least one incompatible add-on is even higher. And having to roll the dice every 6 weeks and see if your add-ons are compatible or not puts a great deal of stress and dissatisfaction on users. And like Colin Coghill comments in Gerv’s post:

If add-ons break randomly every few weeks, effectively FF no longer has add-ons.

Version numbers have a real impact on our users then, and they should be taken very seriously. Now, would the previous releases have worked as minor version increases? I think so, yes. The breaking compatibility changes have been fairly minor so far, with the exception of binary add-ons. Even if we hadn’t done any communication about it, I’m fairly sure that the problems would have gone mostly unnoticed, by both developers and users. Of course, that’s only because so far the changes have been minor. This shouldn’t be the case for every release, and that’s a big concern. For example, Firefox 7 will remove a couple of JSON parser functions that are heavily used by add-on developers. We’ll see how that goes.

So, what are the alternatives? There are a number of proposals, with their own advantages and limitations. I personally think that going back to the initial idea or 3 month-long tracks (instead of 6 weeks) would be a major improvement. Nils Maier (author of DownThemAll!) has a very detailed proposal in the comments on Gerv’s blog (unfortunately, I can’t link to the comment directly), which consists of having planned minor and major releases, where major releases happen only twice a year. I like that one as well.

As usual, I expected this be a short post and then it grew into a monster. Oh well. I’ll close by saying that we’re working on a number of ideas to make this release cycle as smooth and stress-free as possible to add-on developers. Most releases will change nothing you care about, so you shouldn’t need to worry about it. I strongly recommend all of you to track the Add-ons Blog, which is becoming an increasingly important source for updates. I also recommend that you give the Add-on SDK a shot. If your add-on can be implemented using the SDK, it’s better for you that it is.

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

I revisited my old add-on performance article and noticed that the contents of the Measuring Startup wiki page have changed substantially since I originally linked to it. It now recommends installing an add-on  to measure startup performance. I haven’t tried it, but there are a few reasons I can think this is not the best approach. (Update: I’ve been informed that the add-on is only a display for data that is gathered and stored locally. You can make test runs and then install the add-on to look at the data. That dispels my previous doubts about this approach.) Regardless, I’m documenting the old testing method here, because it is the one I have been using for a while and is also very similar to the one implemented on our automated Talos testing framework.

I have been doing lots of add-on startup testing recently, mainly to double check if the results of the Talos tests are sound. We also correlate them to real world usage data that we have been collecting since early versions of Firefox 4. This data, manual testing and source code review are the main backup sources that give us a good confidence level in the results we display on our infamous performance page (it has been linked enough).

Here’s what I do.

Setup

1. Create a new profile dedicated for testing add-on performance (I called it startuptest).
2. Download this HTML page and save it somewhere convenient. The page is blank if you open it directly. All it does is run some JS that extracts a timestamp after the # character in the URL, compares it against the timestamp when the script is run, and shows the difference on the page.
3. Set up a console command that opens Firefox in your testing profile and opens the downloaded file, with the current timestamp embedded after the # character. On my system (Mac OS), this command is the following:

/Applications/Firefox.app/Contents/MacOS/firefox-bin -P startuptest -no-remote file:///Users/jorge/startup.html#`python -c 'import time; print int(time.time() * 1000);'`

The old version of the Measuring Startup page explains how to set this up on Windows.

Testing

1. Locate the testing profile folder and delete all files in it, if there are any.
2. Open Firefox on this profile. You can use the console command or any other shortcut if you prefer.
3. Copy and paste the add-on listing page URL on the new profile and open the page.
4. Install the add-on using the install button and restart if necessary.
5. Optionally, set up the add-on in a realistic way. For example, if this is a Facebook add-on, it may make sense to log in to a Facebook account since otherwise most of the add-on’s functionality would be inactive.
6. Quit Firefox.
7. Run Firefox using the console command.
8. Note the result in the startup page.
9. Quit Firefox. I prefer using the Quit key shortcut, to interact with Firefox as little as possible.
10. Repeat steps 7-9. I discard the 2 first runs, which are normally much slower than the rest, and measure the 10 runs after that.

Interpreting results

For your results to make any sense, it’s also necessary to make a test run without any add-ons installed, and use that as your baseline. It’s also a good idea to run all the tests consecutively to have some certainty that they are all running under similar conditions. I record and compare my results on a spreadsheet, like this one where I tested both my add-ons.

Looking at the results, Fire.fm has a somewhat noticeable impact on startup. This is not surprising because it is a complex add-on with a very complex overlay and startup processes. I documented on improving startup code in my old blog post, and we’re planning on greatly simplifying its overlay soon(ish). I doubt we’ll make the coveted 5%, but we’ll see. Remote XUL Manager is clearly simpler, and it shows how the results should not be taken at face value. Since all it does in the overlay is add a menu item that opens a separate window, it’s understandable that its impact is negligible. But does it really improve startup? No, of course not. This just means that the error margin is larger than its real performance impact.

The key takeaway here is that the results of manual tests shouldn’t be taken literally, but they’re still a good indicator of the performance impact of an add-on. Even if the error margin is not ideal (or even measurable under these conditions), you can still get a good idea of who’s fast and who’s slow. They have been very valuable to us when comparing them against Talos results.

How does this compare to Talos?

On one hand, these tests are influenced by how the testing system is set up. I have several applications open at all times, and I don’t close them all for testing. I do take care in not running anything heavy simultaneously, like Time Machine or MobileMe Sync. And then there’s clearly the fact that I have to spend some time setting things up and running the tests. The longer the tests take, the more likely it is that some other process affects the results.

On the other hand, it’s easier for me to recognize errors during testing. Many of the complaints we’ve received about the testing system is that it makes silly mistakes like trying to install an add-on from an incorrect URL, or trying to install an add-on that is not compatible with the Firefox version being tested. These are things that one can clearly see when testing manually, but they weren’t obvious when running the tests automatically. Those add-ons have been getting very good performance rankings because they’re not really being loaded, so those results are not reliable.

Luckily, the people complaining about our testing are also filing bugs and talking to us directly, so we’re looking into the issues and trying to get them resolved as soon as possible. Special thanks to Wladimir and Nils, who have been very helpful filing and categorizing bugs. More details coming up in the Add-ons Blog.

As always, the developer community proves itself as an invaluable asset for Mozilla (well, you are Mozilla). Even if our discussions can become harsh and are generally very public, the outcome is almost always a set of improvements both in our technical and communication fronts. Getting things right take a lot of work and a lot of patience, and I hope we can quickly get to a place where we’re all satisfied.

Firefox 4 for Add-on Developers

For now, this is a pretty good reference if you want to start supporting the Firefox 4 betas in your add-ons. I’ll be elaborating on this subject through the following weeks, in the Add-ons Blog.

I’ve been an extension developer for a long time, and I like to think that developing extensions is actually quite easy. Maybe it has to do with my C++/Java background, where setting up a development environment is much more involved than using a text editor and zipping some files together.
That doesn’t negate the fact that the Mozilla add-ons platform is old, and showing its age. There are a number of problems with it that make it hard to take the first steps into add-on development, and it’s amazing how little has been done to solve them over the past years. These are the top 3 in my mind:

• Extensions can’t be installed or uninstalled without a browser restart.
  • That’s bug 256509. Can it be fixed? Probably, but it would take a major development effort.
• The documentation about extension development is incomplete or outdated.
  • I’m working on this in the XUL School project, to be finished soon.
• Getting started with a basic “hello world” extension is too much effort: install.rdf, chrome.manifest, chrome JAR, content, skin, locale, defaults, OMG!

The last point is the one I want to tackle in this post. There’s a ridiculous amount of boilerplate, redundant coding to do even for the most basic of add-ons, specially if you’re making an extension that should be skinable and localizable. These are the specific problems I’ve identified:

• There are two manifest files: install.rdf and chrome.manifest, in completely different formats.
• They are both defined in relatively obscure formats. The install.rdf file is one of the very few places where RDF is still used in Firefox. Sticking to a dying format (at least in this context) is a very bad idea.
• The default chrome structure (with content, locale, skin, etc.) is too bureaucratic and inflexible, and almost completely redundant. Most add-ons have exactly the same structure, and having to define it every single time is unnecessary.

I think we can reimagine add-on packaging in way that simple tasks can be performed in the simplest of ways, and so that it can scale to be as fine-tuned as it is today. So here are my ideas.#1 Merge install.rdf and chrome.manifest into a single file. What format should be used? I think JSON is as good as any other, and Mozilla already includes a native and very fast JSON parser. This manifest file could also match the package.json manifests being used for Jetpacks. package.json is actually a pretty good name for the manifest file. Perhaps the same standard can be use for Jetpacks and other add-ons?

#2 Default to the root extension directory for chrome URLs in order to minimize chrome.manifest declarations. This means that a hello world extension could have this structure:

• helloworld.xpi2
  • package.json
  • overlay.xul
  • overlay.js
  • overlay.dtd

And the manifest file would be something like:

{
  id : “helloworld@xulforge.com”,
  name : “Hello World!”,  
  type: “2”
  compatibility :    
    { id : “{ec8030f7-c20a-464f-9b0e-13a3a9e97384}”,
      minVersion : “3.5”,
      maxVersion : “3.6.*”},     
  domain: “helloworldchrome”,
  overlays:      
    { source : “chrome://helloworldchrome/content/overlay.xul”,
      target : “chrome://browser/content/browser.xul”}
}

(Note: ‘compatibility’ and ‘overlays’ can be arrays when there’s more than one item. And the ‘domain’ value is a general declaration of the chrome domain.)

In this new system, you would be able to have all of your chrome files in the root directory and have no need for chrome directives other than declaring your main overlay. Also, in your root directory you can have a locale or skin folder that the system would know how to handle without any changes to the manifest. If a file isn’t found in the locale or skin folder, then the system falls back to the root directory as a last resource. Of course it would still be possible to declare specific locations for content, locale and skin in the manifest, in order to allow the “old style” to be used.

What about other special locations?

• platform and components will continue to have their special meanings.
• JSM files can be handled just the same as chrome files, except that they use resource:// instead of chrome://.
• The default preferences file should also be moved to the root and have a predetermined name, like defaultPrefs.js.

#3 Installing the package. When you install an XPI file, the file is unpacked in your profile directory. It is common (but not mandatory) practice for chrome files to be packed in a JAR file, which remains packed after installation. According to recent discussions about add-on performance, it’s more efficient to keep files packed together. Instead of requiring authors to use the internal JAR approach, I think it makes more sense to require authors *not* to use JARs, and then keep the packed XPI in the profile on installation. Files that need to be extracted, like the manifest (maybe) and binary components (according to this) can be extracted upon installation. This way it’s up to the platform and not the developer to look after performance.That’s it. Given that this new packaging system would be backwards-incompatible with the current one, it might make sense to change the file extension to something like XPI2, in order to make a clearer distinction between the 2. However it should suffice to look for the manifest file in order to identify the system in use.
How hard is this to implement? I think #1 and #3 are fairly simple to implement. #2 is the one that may present a bigger challenge, since the chrome URL system is something that runs deep in the Mozilla code, and changing its file location rules could cause breakage or vulnerabilities in non-add-on code. It might also be possible to limit the scope of these changes to add-ons only, but again, that may require lots of work. I’d love to hear the opinions of those who work on this part of the platform.

Some may wonder how does Jetpack fit into this whole idea. Well, Jetpack is a different platform, and it may very well replace traditional add-ons in the long term, but we’re still a long ways to go. We shouldn’t see Jetpack as some kind of competition, but as a lesson in what we can do better. If we improve add-on packaging to be closer to Jetpack packaging (I think this would be), then it’s a win for both, because it’ll make it less painful for developers to choose and switch between either platform.

I’d love to hear what experienced developers (both add-on and platform) think about this. I think there’s a real gain for novice developers in this if we were to implement it. I intentionally left out some details for brevity, but I’ll be happy to discuss them in the comments. Thanks for reading.

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.