Skip to content

Extending the New Developer Toolbar

Firefox 16 will be released in a couple of days. Among its many improvements, there’s the new Developer Toolbar. This toolbar is essentially a command line that allows you to execute commands on the developer tools, like inspecting elements, starting up the debugger and generating screenshots from web content. This feature is designed to be easily extensible, so I decided to give it a try. Here are my results.

I thought it was particularly useful that there is a screenshot command in it. Since I’m not much of a web developer, this is the command that struck me as most useful. So I decided to take the screenshot command and juice it up. I created a restartless extension that adds a new imgur command that, predictably, uploads screenshots to instead of saving them locally.

Creating commands is surprisingly easy. There’s no documentation for it yet – that I know of – so it required some digging around. Since it made sense to base my code on the screenshot command, first I located its source. As you will see if you inspect that code, declaring commands is super simple, and something you can cobble together in a few minutes (sans localization). Once I had the base for my code, it was just a matter of looking into imgur’s API, and then code, debug, repeat.

I finally got it in a decent state.

imgur instalado

The resulting code can be found on Github. It’s worth noting that the code won’t work as is, just because I decided not to publish the imgur API key I generated. If you want to fork the code, you just need to visit imgur’s API page, generate your own key and replace it in the code. However, if you want to give the add-on a try, here it is. It should work on Firefox 16 and later.

I created this add-on as an experiment, and as part of a Firefox Developer Tools presentation I’m giving later this week in Costa Rica. So, this is far from a finished product. A few things should be corrected, like the lack of localization and the fact that it doesn’t send any metadata (like the title and description) to imgur. So, if you’re interested in turning it into a decent add-on, be my guest :).

Tagged , , , , , ,

Software Freedom Day 2012 @ Costa Rica

Last Friday we had our first Mozilla community activity in Costa Rica. The event was Software Freedom Day, celebrated a week late over here because it coincides with our national independence festivities (the evening of September 14th and all of September 15th). The event was hosted by PROTEA and the Free Software Community at Universidad de Costa Rica.

We organized ourselves for this event in a matter of a couple of weeks. We were lucky enough to have the support of the event organizers, who were extremely welcoming. We were also lucky to be backed by the excellent Mozilla Reps program, who sent us stand swag with very little forward notice (you guys rock!).

Reps goodiesThe theme of this event was Free Software and Education, so we promoted  Webmaker and Hackasaurus on our Facebook page and Twitter account. They’re both very interesting projects that aim to promote education of web technologies, particularly to children and not-so-technical people. What I learned about these tools is really fantastic, and I hope someone in Costa Rica can take the initiative and implement it locally.

Our booth was very successful. We ran out of Firefox pins and Mozilla stickers in just a couple of hours (the event lasted all day), and many people came up to us to talk and ask questions. The majority of booth traffic happened in the morning, so we were smart not to hold on to much swag for the afternoon. I did realize that we should have had informative flyers for our visitors. That was an idea that lost importance during the planing process, but we should definitely take into account for future events.

Mozilla Costa Rica

This was a great first opportunity for us to work together and begin sending the Mozilla message. Activity on our Facebook page grew considerably throughout the days leading to the event. We got to meet members of various free software communities in Costa Rica. And, most importantly, we got to share the Mozilla vision with many interested people. The reaction we got from people who support free software and specially Firefox is very encouraging. We hope this is just the first of many similar endeavors.

Thanks to everyone who visited us and made this event possible!

Tagged , , ,

Signing XPI files (using python and m2crypto) on (Mountain) Lion

I want to call out this post by the Appcoast folks: Signing XPI files (using python and m2crypto) on (Mountain) Lion. They contacted me recently because they were having some problems with the old way of signing XPIs, and I pointed them to Wladimir’s post in the AdBlock Plus blog. Their post just elaborates their experience getting it working on Mountain Lion, which might also apply to other systems. Hopefully this will be useful to people.

Tagged , , ,

Should we fix Personas?

This post is about Personas, also known as lightweight themes, not Browser ID, now known as Persona (naming is fun!). Also, these are just my thoughts, not an official position of Mozilla or the Add-ons Team.

I think we skipped a step when we graduated Personas from Mozilla Labs and implemented them as a Firefox feature. Personas have always felt like an incomplete idea, which has lead to some quality, performance and openness problems. High performance on Firefox is a top priority for Mozilla, and Personas are extremely popular, so I think revisiting the Personas feature would benefit Firefox users greatly.

The Problems

All of the problems are rooted in the feature’s simplistic design. A Persona consists of 2 images, one for the header and one for the footer.

Window width can be arbitrarily large depending on screen(s) resolution, and the header area can be variably tall depending on how many toolbars are active. This led to the decision of requiring Persona images to be excessively large in order to cover all use cases. The header is required to be 3000px wide x 200px high, and the footer 3000px wide x 100px high! Click on the example below to get an idea (you’ll need to use the magnifier to see its actual size).

Persona Header

This creates a number of problems:

  1. Performance problems. Decoding these massive image files can introduce a non-trivial delay in Firefox startup time.
  2. Poor image area management. It’s very common to see designs that are almost completely hidden height-wise, or designs that look good in the browser but look really strange on the Personas site and AMO (we got a ton of complaints about that one). Designers have to figure out ways to pad their images so they don’t look bad. In the example above I decided to be lazy and went with a plain white.
  3. No flexibility. There’s no way for designers to control how the image is displayed in different screen sizes or toolbar configurations. It’s also not possible to tile backgrounds.
  4. Limited distribution outside of Mozilla properties. Personas can’t be easily packaged up and distributed outside of or There are ways to set up a Personas repository, but it isn’t easy for casual designers who might want to share their creations with their friends. This puts us in a position where we’re almost the sole arbiters for Personas designs, and our policies become the world’s policies.

The Solution?

I think Personas should behave more like add-ons:

  • Have a package (xpi?) that holds the images and a manifest (install.rdf? json?).
  • The images can have predetermined names, like header.png, header-background.jpg, etc. to avoid having the declare them in the manifest.
  • A Persona can have as little as one header image (the only required one), and as much as 4 images: header, header background, footer, footer background. The idea here is that the background is tiled by default, and the foreground image can be small and transparent, giving designers much greater flexibility.
  • The manifest can have basic metadata (name, designer, homepage) and a few additional image positioning features, like allowing the header foreground image to be proportional to the displayed area instead of being cropped, allowing the background to be stretched instead of tiled, or making the background a solid color or fade using CSS.

This would allow designers to submit much smaller images that would look better in most configurations. It wouldn’t break backward compatibility because we can just package existing Personas in the new format. Most importantly, we don’t need to make things difficult for designers. We can use the same image upload form that we currently have and create the package server-side, eventually extending the form to support the new features. Finally, it would allow designers to package their Personas and share them with others without having to go through our site.

This, of course, requires lots of work in the Add-ons Manager and our Personas properties. It’s worth thinking about, though, specially because of the potential performance gain, which could be substantial. Perhaps it’s a good project for the next GSOC?

Tagged , , , , , ,

Experiencias en MozCamp América Latina

MozCamp LatAm finalizó hace una semana y todavía estoy intentando recuperar el sueño. Fue una experiencia intensa, mucho más que cualquier otro evento de Mozilla al que haya atendido anteriormente. Se sintió como que cada miembro de la comunidad latina / hispana venía mentalizado para pasarla fantásticamente, y sacarle el jugo a cada minuto que pasaron en Buenos Aires. Bueno, creo que lo lograron con creces!

He aquí un pequeño recuento de mis experiencias en el MozCamp:

MDN Hack Day

El MDN Hack Day ocurrió el día antes del MozCamp, un viernes. Se dieron varias charlas interesantes sobre apps, herramientas de desarrollo, y el Add-ons SDK, entre otras.

Desafortunadamente la mayoría de las charlas fueron en inglés, lo cual fue un problema para muchos locales que atendieron el evento. A pesar que uno esperaría que la gente que trabaja en software tenga un entendimiento razonable del inglés, esto varía mucho a través de América Latina. Creo que tenemos que hacer un esfuerzo mayor en conseguir expositores que hablen la lengua nativa, aunque no sean expertos de primera mano en los temas de los que se va a hablar.

La tarde se abrió para hacer hacking libre. Al principio nadie sabía qué hacer, pero luego nos organizamos y formamos grupos alrededor de distintos temas y empezamos a trabajar en proyectos pequeños que se pudieran hacer durante la sesión. Dediqué un tiempo para demostrar cómo se puede hacer un userscript de cero, utilizando las herramientas de desarrollo del Firefox. La herramienta de inspección, el Scratchpad y la extensión Scriptish sirven para crear buenos userscripts en cuestión de minutos; ésto lo aprendí durante la preparación para mi presentación en el MozCamp.

Luego Hernán se nos unió y propuso una idea que podíamos trabajar como equipo: un complemento hecho con el SDK que imita a Instagram. El Hipsterizer permite hacer click derecho en una imagen y subirla a un servicio de imágenes luego de aplicarle un pinche efecto fotográfico. Actualmente solo aplica blanco y negro, y sube la imagen a imgur, pero podría aplicar cualquiera de los efectos de la librería filtrr, que es lo que utilizamos. Los filtros se aplican usando un canvas, así que estamos utilizando estándares web de lleno. Quieren contribuir? También estamos dispuestos a vender el proyecto por 7 mil millones de dólares.


Como siempre, el MozCamp arrancó con una maratón de presentaciones excelentes, seguidas de un tallado calendario de dos días. Los tracks estaban muy bien organizados, así que no tuve mucho problema en decidir qué charlas atender. El sitio del evento estaba muy bien, aunque sí había que caminar bastante para cambiar de salas. El clima no fue ningún problema, afortunadamente.

El domingo temprano hubo un juego de fútbol para los pocos que estuvimos dispuestos a levantarnos a esa hora tan terrible y correr un rato bajo el sol mañanero. Terminamos abarrotando alrededor de 20 jugadores en una cancha de fútbol 5. Estuvo genial! Me divertí mucho y todas la carrera me dio energía para el resto del día. Debería ejercitarme más cuando viajo.

Madalina - mejor arquera del mundo
Madalina – mejor arquera del mundo

Dí mi charla el segundo día. Normalmente me pongo muy nervioso al hablar en público, y las circunstancias no ayudaron ni un poco. Siendo el segundo día del evento, las cosas empezaron un poco tarde, y la sesión de Q&A antes de mi charla se extendió más de lo esperado, así que ya todo iba con una media hora de atraso. Luego hubo un problema con las pantallas en la sala donde yo iba a dar la charla, y eso tomó una eternidad en resolverse (creo que fueron unos 15 minutos de tiempo real). Tuvo que dar la charla muy rápidamente y luego robarle algo de tiempo al almuerzo para poder responder preguntas.

Dando mi charla
Muevo mucho mis manos

A pesar de todo, creo que la charla salió bien. El demo salió sin problemas, que es mucho decir dada la pobre conexión de internet que tuvimos todo el tiempo. Recibí una buena ovación cuando dije que iba a dar la charla en español. Mi elección de idioma iba a depender en quiénes iban a estar en la charla, pero finalmente la decisión la tomé debido a la limitación de tiempo que tenía. Solo había un brasileño en el público y por suerte él entendía español suficientemente bien.

Community Work Day

Luego del MozCamp hubo un día adicional dedicado a coordinar el proyecto Mozilla Hispano.

Esto es algo que creo que es bastante único de la comunidad hispana. Mozilla Hispano es una meta-comunidad compuesta de varias comunidades hispanohablantes, las cuales comprenden numerosos países y potencialmente uno de los grupos de contribuyentes más grandes del mundo. La ventaja de tener un idioma común significa que la mayoría de las iniciativas se pueden coordinar a nivel de Mozilla Hispano, en vez de individualmente en cada comunidad.

La comunicación en el MozCamp ocurre principalmente en una dirección, un punto que Kevin Dangoor cubrió muy bien. El Work Day le dio a las comunidades un canal de dos vías para alinear sus visiones y decidir qué quieren hacer. Las sesiones fueron muy abiertas y dirigidas a entablar discusiones y debate. Todos tuvieron la oportunidad de dar sus opiniones, a veces emocionalmente pero nunca agresivamente. Esto es algo que me gustaría que todos los MozCamps tuvieran.

Community Work DayEstaba muy interesado en la sesión de Mozilla Hispano Labs, por razones obvias, y me encontré hablando mucho en ella. Las mayores preocupaciones del grupo tenían que ver con conseguir la gente correcta para contribuir en sus proyectos, además de mantenerlos interesados. Esto me recordó muchas de las experiencias que he tenido con la comunidad de desarrolladores de complementos, y el grupo de los AMO Editors, así que tuve mucho qué decir al respecto. Se puso en evidencia que el grupo no estaba haciendo lo suficiente para proyectar su imagen y atraer desarrolladores. Una serie de acciones salieron de la discusión: crear una lista de correos separada, actualizar la página principal de Labs, y crear un blog de desarrolladores (al que me ofrecí a contribuir). Avanzada la discusión, Felipe – quien la estaba liderando y actualmente coordina MH Labs – dijo algo que me pareció divertido y curioso. Fue algo como “Bueno, parece que no podemos codear ninguna de estas soluciones”. Cuando tienes un martillo, todo parece un clavo :).

Me alegra mucho haberme reconectado con la comunidad de MH, y me hace sentir un poco culpable que ellos hagan tanto por Mozilla en su tiempo libre mientras yo me siento frecuentemente agobiado solo haciendo el trabajo por el cual me pagan. También me avergüenza un poco que no exista una comunidad de Mozilla en Costa Rica, y que yo debería haber hecho algo al respecto hace mucho tiempo. Así que estoy tomando algunos pasos iniciales en esa dirección, y estoy determinado en formar aunque sea un grupo pequeño que represente a mi país en MH. Daré actualizaciones sobre esto en el futuro cercano.

A pesar de lo exhaustivo que fue mentalmente y físicamente, este MozCamp es el mejor evento de Mozilla al que he atendido. Cada hora que pasé sin dormir valió totalmente la pena. Juntar tanta pasión, intelecto y fuerza bajo un solo techo es algo que no tiene precio. Me encanta la dirección que los MozCamps como un todo están tomando, y espero que continúen creciendo de esta manera.

Y, finalmente, para todos los que trabajaron organizando este evento: GRACIAS!

Tagged , , , ,

Experiences at MozCamp Latin America

MozCamp LatAm ended a week ago and I’m still trying to recover my sleep. It was an intense experience, much more so than any other Mozilla event I’ve ever attended before. It felt like every member of the Latin American / Hispanic community had their mind set on having a fantastic time and making the best of every minute they spent in Buenos Aires. Well, I think they succeeded!

Here’s a recap of my MozCamp experiences:

MDN Hack Day

The MDN Hack Day was held the day before MozCamp, on Friday. There were a number of interesting talks about apps, developer tools and the Add-ons SDK, among others.

Unfortunately most talks were given in English, which is a challenge for many locals who attended the event. While one would expect people working in software to have an above average understanding of English, this varies significantly across Latin America. I think we need to make a bigger effort getting native speakers to give these talks, even if they are not first-hand experts in the subjects being discussed.

The afternoon was opened for free hacking. People at first had no idea what to do, but then we got organized and formed groups around different subjects and started working on small projects we could get done during the session. I spent some time demoing how you can build a userscript from scratch using the developer tools that now ship with Firefox. Inspector, Scratchpad and the Scriptish extension can help you create effective userscripts in a matter of minutes, as I discovered while preparing my MozCamp talk.

Later, Hernán joined us and came up with an idea we could work on as a team: an SDK add-on that imitates Instagram. Hipsterizer lets you right-click on an image and upload it to an image service after applying some lame photo effect. At the moment it only does black and white and uploads to imgur, but it can potentially use all effects supported by the filtrr library, which is what we’re using. The image filters are applied using canvas, so it is web standards all the way down. Want to contribute? We’re also willing to sell it for 7 billion dollars.


As usual, MozCamp began with a marathon of excellent keynotes, followed by a tightly packed two-day schedule. The tracks were fairly well organized, so I didn’t have much trouble figuring out which talks to attend. The venue was a nice place, though it took lots of walking most of the times you needed to switch rooms.

Early on Sunday there was a soccer match for those few of us who were willing to get up at an ungodly time and run around under the morning sun. We ended up packing 20 or so players in a small field usually meant for 5-on-5 games. It was a blast! I had a great time and running around energized me for the rest of the day. I should exercise more when I travel.

Madalina - best goalkeeper ever

Madalina - best goalkeeper ever

I gave my talk on the second day. I’m usually very nervous about speaking in public, and the circumstances didn’t help at all. This being the second day, things started a bit late, and the Q&A session right before my talk ran longer than scheduled, so we were a good half an hour behind. Then there was a problem with the video displays in the room I was giving the talk in, and that took what seemed like an eternity to fix (I think it took about 15 minutes in reality). So, I had to rush the talk and then take some extra time from the lunch break to do Q&A.

Giving my add-ons talk

I move my hands too much

Overall, I think the talk went well. The demo went without a hitch, which is saying a lot given the poor Internet connection we had across the whole event. I got a good cheer when I told people I was giving the talk in Spanish. My choice in language initially depended on the crowd, but finally I just went with Spanish because of all the delays. There was only one Brazilian in the crowd and fortunately he understood Spanish well enough.

Community Work Day

Following MozCamp, there was a separate day dedicated for Mozilla Hispano project coordination.

This is something that I think is fairly unique to the Hispanic community. Mozilla Hispano is a meta community composed of several Spanish-speaking communities, spanning numerous countries and potentially one of the largest groups of contributors in the world. Having a common language means that most efforts can be coordinated at the Mozilla Hispano level, rather than the local community level. The communication at MozCamp is fairly unidirectional, a point Kevin Dangoor covered very well. The Work Day gave the Hispanic communities a bidirectional channel to align their visions and figure out what they want to do. The sessions were very open-ended and meant to encourage debate. Everyone had their chance to speak their mind, sometimes emotionally but never aggressively. I’d like to see MozCamp have some of that.

Community Work DayI was very interested in the Mozilla Hispano Labs session, for obvious reasons, and I found myself talking a lot in it. Their biggest concerns were focused around getting the right people to contribute in their projects, and keeping them interested. This paralleled many of the experiences I’ve had while working with the add-on developer community and the AMO Editors team, so I had plenty to say. It became evident that the group wasn’t doing enough to project its image and engage developers. A number of important action items came out of this discussion: setting up a separate mailing list, updating the Labs landing page, and setting up a developer blog (where I volunteered to contribute). About halfway through the discussion, Felipe – who was leading the discussion and currently manages MH Labs – said something like “Well, it looks like we can’t code any of these solutions!”. When you have a hammer, everything looks like a nail :).

I was very happy to reconnect with the MH community, and it makes me feel a tad guilty that they are doing so much for Mozilla in their spare times while I often feel overwhelmed just doing the work I’m paid for. I’m also a bit embarrassed that there’s no Costa Rican Mozilla community whatsoever, and I should’ve done something about it long ago. So, I’m taking some initial steps in that direction, and now I’m determined in forming at least a small group that can represent my country in MH. Expect updates about this in the near future.

As mentally and physically exhausting as it was, this MozCamp is the best Mozilla event I’ve attended so far. Every hour I spent not sleeping was totally worth it. Bringing so much passion, intellect and strength under one roof is priceless. I love the direction MozCamps are taking in general, and I hope they continue growing as they have.

To all the people who worked organizing this event: THANK YOU!

Tagged , , , ,

A couple of add-ons that could use forks / developers

I’m preparing to write a few posts for the Add-ons Blog in which I’ll be covering Firefox 3.6 compatibility. Specifically, I’ll be talking about add-ons that are still popular in 3.6 and are holding some users back since they don’t have recent updates. Luckily, I’ve discovered that most of these add-ons have suitable replacements, so this is more a matter of telling users where to find them.

I mentioned this in passing in a dev.planning discussion, and someone brought up a couple of add-ons that are also in need of some developer love and I know won’t be mentioned in my upcoming posts. I was specially interested in them because they provide useful accessibility features and they are in need of support for Thunderbird and SeaMonkey, which admittedly we give little attention to.

Here they are:

  • NoSquint. It currently supports Firefox. Apparently, older versions of this add-on supported SeaMonkey and Thunderbird, which is what we want. It is licensed under the GPL.
  • Quote Colors. Works on older versions of Thunderbird and SeaMonkey, but it hasn’t been updated for a while. Judging by its usage stats, forcing compatibility makes it work, which would make it a fairly trivial fork. It is licensed under the MPL.

My recommendation when forking add-ons is to always try to approach the original developer first. The ideal case is that you can work together and get the new version out under the same add-on listing. However, if that doesn’t work, creating a new listing with the fork is the next best thing. Choose a name that relates to the original – so that users can find it – but not that close to be confusing. Something like “Quote Colors Updated” works.

Let me know if you know of any active forks or if you’re interested in taking any of these.


Tagged , , , ,

All green!

Today we reached a very significant milestone.

Review queue statusThis 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!

Tagged , , ,

My experience porting an add-on to Mobile Firefox

I’ve been meaning to experiment more with Mobile Firefox for a while, but I’ve had very little time to work on my own add-ons, which are the best source of real-world development experience for me. Since I had received a couple of requests to port Remote XUL Manager to mobile, and this is a fairly simple extension, I thought this would be the ideal learning experience.

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.


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.


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.


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.


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.

Tagged , , , , ,

Keeping add-ons compatible in the rapid release process

I began this discussion in the newsgroups today. Keeping add-ons compatible in the rapid release process. It is mostly aimed at Mozilla developers, but this should interest add-on developers just the same. We’re establishing a better system to communicate breaking changes, which should make it easier and quicker to identify what needs to be added to the compatibility validator for the automatic version bumps.


Tagged , , , , ,