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.

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.

My name is Jorge Villalobos. I’m a software developer who has been working for the past couple of years with Mozilla technologies, particularly XUL and Firefox extensions. I co-developed the very successful Fire.fm extension with Jose Enrique Bolaños, and helped develop several other extensions during my tenure at Glaxstar. I particularly enjoyed working on the eBay Companion.

I quit Glaxstar to pursue my own projects and ideas, and this is the purpose of Xulforge. I’ll be focusing mostly on Firefox extensions, but occasionally I might try a few different things which will likely end up here as well. I also have a personal blog which I’ll continue to use (and usually neglect) for more personal matters.

I’ll post again shortly, hopefully, with updates on the projects that I’ll be working on over here.