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.

Discuss!

I use the Automator application that is part of all default Mac OS installations. This is a tool that allows you to create automated tasks, as you might have guessed. Then I do something like this:

1. Open Automator.
2. Choose the Application template.
3. From the long list in the second column, double click on Run Shell Script. This will add a box on the main panel, with a text input.
4. Enter this: /Applications/${APPLICATION}.app/Contents/MacOS/firefox-bin -P ${PROFILE} > /dev/null &
5. Replace ${APPLICATION} with the name of the application you want to run (Firefox, Aurora, Nightly, etc.). Replace ${PROFILE} with the name of the profile you want to run, or leave it blank to open the profile manager.
6. (Optional) Replace /dev/null with a file path to save the console output to a file.
7. Save the application to the Desktop.

That’s it. You now have a Windows-style shortcut that opens a specific application and profile combination. Repeat as necessary and you’ll have all the shortcuts you need, which you can open in parallel (except opening the same profile with multiple applications, which would be a bad idea). My desktop has a matrix of profiles and applications that are very convenient for my testing needs. You may want to have them in the dock or elsewhere, but that’s a matter of preference. You can also change their icon, which is not really worthwhile IMO.

You can copy and paste applications and then open them in Automator to edit their parameters. You need to open Automator and then choose the Open option, there’s no contextual edit option, which is a bit of an annoyance.

If anybody has a different system to deal with this on Mac OS, I’d love to hear it.

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.

• 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

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.

I did the first part of the workshop, explaining extension development.

I learned from this experience that it’s not a good idea to cover all of the boilerplate parts of extension development in a presentation with such limited time. For future events I think it’s a better idea to have some sort of required reading before attending, so that it’s easier just to dive into the actual juicy parts and get stuff done. I still managed to cover several topics surrounding extension development, and the slides were full of references that people can follow to continue learning about the topic.

The second part of the event was about Jetpack development, and was presented by newly appointed Jetpack Ambassador Hernán Rodríguez, from Agentina:

Hernán did a fantastic job. I also should give Jetpack some credit because it is incredibly easy to get started in a few minutes. The attendees had a chance to play around and do more experimenting than on my presentation. We had some fun playing around with Hernán Twitter slidebar and messing around with CSS transformations.

The event was a great success, and this was all thanks to the great work of the Mozilla Perú community. I was pleasantly surprised of how well organized they are, and the great deal of large-scale technology events that are held in Perú that could be good platforms for Mozilla to attract new community members.

Much more details about this event can be read (in Spanish) in the Mozilla Perú blog and Hernán’s blog:

• http://mozilla.pe/resumen-del-maow-lima-2010
• http://www.malditocrc.com.ar/peregrino/2010/03/lima-mozilla-y-addons/

Thanks again to Percy and Mozilla Perú community for organizing this event. I hope to see you again soon!

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!

This project is a set of skins for the Personas extension. Personas is a new approach to developing themes for Firefox and other Mozilla apps. Creating a skin is pretty simple: all you need is a header image and a footer image. Creating a good one is a little harder; you’ll need to fill a very, very large image area, while at the same time keeping in mind that only a tiny fraction of the image will be visible in the majority of browsers. Patterns and other artificial designs are probably easier, but mine are just extracts from my large photo collection, so it’s trickier.

I have a list of the skins I’ve created in the project page, with explanations on why I chose the pictures. So far my designs are doing pretty well, with a few hundred active daily users at this time. You can see the user counts in my designer page.

My skins were all created using The Gimp, and the pictures were taken with 2 different models of the Canon PowerShot (I upgraded recently). Artistic feedback is greatly appreciated.

Anyway, at the time we were pretty excited about it, and we spent a great deal of time and effort making Fire.fm a sure winner. And we won! We won the Best Music Add-on category, and I think we weren’t allowed to win in others, because I think we should have won the general competition as well . Needless to say, we were super happy with this, and we have been actively maintaining the add-on in our spare time.

Fire.fm is, in a nutshell, a Last.fm radio player. It used to be a very easy way to tune into Last.fm radio without having to be on top of the website all day long. Our users loved it, and shortly we were in the AMO Recommended List.

Sadly, Last.fm cut off their free radio service to most of the world shortly afterward, so at least I lost a lot of the motivation I initially had to continue making it grow. Still, I don’t want to abandon a project that still has much to be fixed, so I’ll certainly won’t quit until all the annoying bugs are solved. Most users have a very smooth experience with Fire.fm, but there are a few unlucky ones that have some serious problems, like not being able to listen to stations at all… New features in Fire.fm are probably going to be very rare from version 1.2.3 and later.

Xulforge was already in my mind when we began working on Fire.fm, so I always kinda saw it as a Xulforge project. Xulforge was put on hold until very recently, so it feels weird trying to associate the two. I’ll keep Fire.fm in my project list, though, because I it was one of my first independent projects, and also because it has been very successful and I’m very proud of it.

Fire.fm is open source, BSD-licensed (more on that in another post). So, if you want to take a look into our code, you’re more than welcome. See the Fire.fm Sourceforge Project Page for more information.

Fire.fm Logo