Oxymoronical

You might have heard of this web-browser. It’s called Firefox. You may have also heard that a new version is due out soon. As my part in its development I have helped completely reshape the way the add-ons manager looks. The good news is that the large bits of the changes are pretty much done, pretty much all that is left is a bunch of UI tweaks and some small behaviour changes.

This is where you come in. Yes you, the one reading this post. If you have an urge to help out you can look through this list of things we want to get done on the add-ons manager before release, pick one out and go nuts. These are all things that shouldn’t require very much experience working on the add-ons manager or even Firefox in general, though of course some are easier than others. We have some great information about how to get started and also a great community who can help out if you get stuck. So if you’ve ever had a hankering to get involved this would be a great time to dive in.

Once again that list is here: http://bit.ly/duYWdP, give me or Blair a shout if you have questions or don’t know where to get started.

One of the goals of the new add-ons manager API was to create something that was itself extensible. A couple of times in the past we’ve had to add new types of add-ons to the UI like Plugins and Personas. In both cases squeezing them into the UI was something of a kludge involving a bunch of custom code for each case. We already have a number of new types of add-ons that we want to add, things like search plugins which are currently managed by their own custom UI.

To help simplify this the API is largely type-agnostic. Internally it uses a number of so-called add-on “providers”, each of which may make information about add-ons available. Each provider is basically a JavaScript object with functions defined that the API can call to ask for information about add-ons that the provider knows about. The provider then just has to pass back JavaScript objects to represent each add-on. Each of these must have at minimum a set of required properties and functions and may also include a set of optional properties. The full set is defined in the API documentation.

With this design the user interface doesn’t need to care about implementation details of any of the providers, how they store their data or what exactly their add-ons are and do. Because each gives objects that obeys the same interface it can just display and manipulate them.

To try to show this all off I recently put together a small demo extension for the Mozilla Summit that registers a new type of add-on to be displayed in the main add-ons manager. This is a short overview of some of the highlights and I’ll make the code available for people to look at and take examples from. The add-on was a basic implementation of Greasemonkey allowing user scripts to be installed, managed through the add-ons manager and do it all as a restartless add-on.

Making a restartless add-on

Add-ons don’t have to be developed with Jetpack to make them restartless, although the Jetpack SDK certainly makes things easier on you, at the expense of less access to the internals of the platform.

The first thing to learn about making a restartless add-on is that you can forget about using XUL overlays or registering XPCOM components to be called at startup. Neither are supported at the moment, and maybe never will. Instead you have to provide a bootstrap script. This is a simple “bootstrap.js” file in the root of the extension that should include a “startup” and “shutdown” function. These are called whenever Firefox wants to start or stop your add-on either because the application is starting up or shutting down or the add-on is being enabled or disabled. You can also provide “install” and “uninstall” methods to be notified of those cases but that is probably unnecessary in most cases.

At startup the demo extension does some basic things. It registers for some observer notifications, registers a new add-on provider (I’ll talk more about that below) and does a little work to include itself in the add-ons manager UI (again, see below).

The rule is this. Anything your add-on does after being started must be undone by the shutdown function. The shutdown function often ends up being the inverse of startup, here it removes observer notification registrations, unregisters the add-on provider and removes itself from the UI. It also shuts down a database if it was opened.

Implementing a new provider

This extension implements probably the simplest possible provider. As far as the API goes all it supports is requesting a list of add-ons by type or a single add-on by ID. These functions pass add-on objects to the callbacks. For this add-on these objects are held in a database so that code does some fairy uninteresting (and horribly synchronous) sql queries and generates objects that the API expects.

Adding new types to the UI

Perhaps the hardest part of this extension is getting the new type of add-on to display in the UI. Unfortunately one thing that we haven’t implemented so far is any kind of auto-discovery of add-on types. Instead the UI works from a mostly hardcoded list. This is something that we think it would be nice to change but at the moment it seems unlikely that we wiull get time to before Firefox 4, unless someone wants to volunteer to do some of the work.

The demo extension works around this restriction by inserting some elements into the add-ons manager window whenever it detects it opening. In particular it adds an item to the category list with a value attribute “addons://list/user-script”. The add-ons manager UI uses this kind of custom URL to decide what to display when a category is selected. In this case it means displaying the normal list view (that plugins and extensions currently use) and to ask the API for add-ons of the type “user-script”. There is also some code there that overrides the normal string bundle that the manager uses to localize the text in the UI to allow adding in some additional strings. The code I am showing is of course badly written in that it is hardcoded and so could not be localized, please forgive me for cutting corners with the demo.

That is basically all that is needed to have the UI work to display the new add-ons from the registered provider however the demo also throws in some style rules to pretty things up with a custom icon

Notifying the UI of changes

When you implement your own provider you have to be sure to send out appropriate notifications whenever changes to the add-ons you manager happen so that any UI can update accordingly. I won’t go into too much detail here, hopefully the AddonListener and InstallListener API covers the events you need to know about enough. You can see the script database send out some of these notifications.

Get the full code

This has been a very short overview of the highlights of this demo, hopefully enough for the interested to pick up the code and make use of it themselves. The full source of the extension is available from the mercurial repository. Right now I wouldn’t really release this as an extension. As I’ve mentioned it uses synchronous sql queries (on every page load no less!) and cannot be localized. These things can be fixed but this was just made as a demo in basically one evening to show off the sorts of things that are possible with the new add-ons manager.

Are you an extension or application developer? Have you written any XPCOM components, JS, binary or otherwise? If not you can probably ignore the rest of this post, unless you are interested anyway.

If you do then you might be interested to hear that your components are probably going to break in an upcoming Firefox nightly, maybe as early as next week. I’m going to blog specific examples on the changes you need to make once we have better documentation up and builds to test against, for now it is just important for you to know that the changes are coming.

Changing XPCOM component registration

One of the things we are doing is changing how XPCOM components are registered. Previously during registration we would load all binary and JS component files and call them asking them to register themselves. If you used XPCOMUtils.jsm then some of that ugliness will have been hidden from you. The future though will be registration using manifest files, similar to how chrome is registered (in the same files in fact). Every single JS or binary component will need fixes to support this. The amount of work to do is fairly trivial per component and it is possible to support both old and new styles of registration in the same component but until that work is done your components will not work.

Starting extension components later

Currently there are a bunch of different notifications that components can listen for to perform actions during startup. Commonly xpcom-startup, app-startup and profile-after-change have been the most common. The latter is generally the best to use since this is one of the earliest notifications that occurs after the profile folder (and hence preferences and other services) is available.

The news is that once we make our changes components from extensions will no longer be able to register for and receive the xpcom-startup or app-startup notifications at all. profile-after-change will be the first notification that components can be loaded by.

Most of the reasons for loading on app-startup were either because developers didn’t know about profile-after-change or at one point it used to be necessary to load for app-startup just to be able to register for profile-after-change in the observer service. That is no longer the case as you can register for it in the category manager exactly as you can for app-startup.

Why?

You might well ask why we are making all these changes.

Currently whenever we detect a potential change in the set of usable components (meaning either the application version has changed or an extension has been added/removed/enabled/disabled) we must throw away existing component registrations and then perform what has become known as the EM restart where the application is restarted during its startup (in theory invisibly to the user) to make sure that any component that weren’t meant to be loaded are unloaded and to re-register everything and load any new components that need it.

Registration is itself a costly process since every component must be loaded and executed when really many if not most of them do not need to be loaded during startup. In the E10S world there are even more problems. Content processes must either register all components during every startup or somehow share a component cache with the chrome process.

The new registration model allows us to do away with the EM restart. On startup rather than relying on a potentially stale component cache we will read the registrations for the main application out of a manifest file. This will give us enough of XPCOM to then be able to load the extension manager and do any necessary work to install/uninstall/update any extensions after which we can simply load the component registrations for those out of the manifest file. Startup then just proceeds as normal, no restart is necessary since nothing from extensions can have been loaded when it shouldn’t.

E10S content processes can just read the component registrations during startup, since they are in simple manifest files this will go a lot faster

I’ve spent some time this week transferring all the API documentation for the new add-ons manager from the Mozilla wiki to the Mozilla Developer Network. This should now be the place to go for the definitive info.

Right now it is pretty dry, for the most part just pure API info with no examples. Before I started working more on that side of things I wanted to ask what kind of examples people might like to see documented?

For some time now Firefox has supported a way of installing extensions that involves simply copying the extension’s XPI file into one of the extension install locations. The next time Firefox runs it would pop up the install dialog for the extension and allow the user to choose whether to install it or not.

I don’t know how many people use this feature and while the code to do it (at least for the profile folder) isn’t terribly complex, it is additional code that may not be necessary. Right now the new add-ons manager doesn’t support it and I’ve heard only a couple of people comment on its absence but nightly testers are by no means representational so I’m asking a little more widely whether people have a real need for keeping this working in Firefox 4?

To be clear we aren’t talking about the method of installing where you extract your extension into a directory in the install locations, nor are we talking about the method where you create a text file in the install location containing the path to your extension.

Many of you nightly testers may have noticed that Nightly Tester Tools’ compatibility override feature doesn’t work with the new add-ons manager and may be wondering when I’m planning to issue an update to fix that. The more astute of you may have noticed that there hasn’t actually been a real code update to Nightly Tester Tools in 2 years, barring a couple of simple app compatibility fixes. Those with a sharp memory will remember that I said just under 2 years ago that I was ceasing work on my extensions in my spare time. I suggested that Nightly Tester Tools might still receive the odd update but obviously that hasn’t happened and the truth is that I can’t see it happening anytime soon. I’m too busy with that whole real life thing to even be able to work on projects I do enjoy, let alone maintain old stuff that no longer really interests me.

This unfortunately leaves a sizable number of users losing a feature that they liked and still potentially have a need for. I can only really see a couple of possible roads to follow from here:

1. Do nothing. Users will be annoyed for a time but eventually find ways around what they needed NTT for.
2. Find someone else to pick up and maintain NTT. I’ve had numerous requests for the source code for many of my extensions over the past two years, none have ever apparently tried to do anything though. Perhaps someone out there will pick up the torch this time?
3. Point all the users to something else, like the Add-on Compatibility Reporter (once that is updated to work on trunk). While nothing else I know of works quite like NTT at least something is better than nothing, and ACR has the benefit of being Mozilla supported, provides Mozilla with valuable information about add-on compatibility and may be rolled into Firefox at some point.

Option 3 is the only one available that involves any work on my part but probably the choice that leads to less user annoyance, unless someone reading this wants to take up the challenge or has a better idea?

A little sort of coincidental performance regression forced us to back out the new add-ons manager last week. It has now been re-landed with added bug fixes and should be in tomorrow’s nightly.

Finally, after far too much time, the new add-ons manager is about to land in trunk nightlies. I am putting together the final patches to land now. The bit most people will see is the new UI so I guess I’ll steal Boriss’ image for you to look at here with the same caveats. What you see on trunk over the next few days is just the initial steps to switching to a redesigned UI and (more importantly from my point of view) a totally new extension manager backend that will make it easier for us to improve and build upon in the future. The changes are so large that it is important to get more people testing it now while it still looks fairly unpolished so we can pick up problems that we’ve missed.

New Add-ons Manager UI

Tomorrow (Friday) the QA team are holding a test day on the new add-ons manager, if you want to help test for issues you can join us in #testday on irc.mozilla.org

We are filing bugs with [rewrite] in the status whiteboard and blocking either the backend tracking bug or the UI tracking bug. So you can check the dependency tree to see what issues we already know about and plan to take care of. Please file bugs for anything else you see, especially when it is something that is wrong compared to Firefox 3.6.

There will be some add-ons broken in the new builds. This is fairly normal for any API update. As a general rule if some add-ons work but others don’t then contacting the authors of those broken add-ons is the best idea.

Developers of other applications may find things broken, ultimately this is unavoidable when changing APIs on this scale, please contact me if you need some help getting things working again.

Since I posted last week about how I was experimenting with running Firefox on my Palm Pre a number of tech news sites, large and small, picked it up and posted their own take on it. Some of the sites (and some of the readers of those sites) made some fairly odd statements about my work. This is probably because to the uninitiated (and many of the initiated in fact) the internals of Firefox are something of a mystery. I also suspect I made a couple of poor choices of words which led to some misunderstandings so I’d like to try to clarify a couple of points that might make it easier to understand what is going on.

Why this isn’t a port of an Android application

Lots of sites made mention of how this is a port of Firefox for the Pre. This isn’t surprising since even I said that. Many also called it a port of the Android version of Firefox, this is slightly true but really a misnomer. What you have to realise is that the bulk of Firefox’s code is written to work on any platform, only a few fairly small parts of it are platform specific. For the most part this is called the widget code and handles drawing the UI on the screen and receiving mouse and keyboard events. There is a widget implementation for Windows, for Linux, for Mac, for the N900, for Android and would you believe also for BeOS and OS/2.

The largest part of the work of making Firefox run on the Pre was writing this widget implementation. It’s true some of it was copied from the Android widget code, but that is because that already had code to use OpenGL to draw to the screen. No point in trying to rewrite that from scratch when you’re going to do exactly the same thing anyway (especially if you are like me and have never touched OpenGL before). If it makes people feel any better though the Pre version is now using a 2D method of drawing to the screen which is totally written from scratch so hardly any of the copied Android code remains now.

Why user interfaces don’t always need to look nice

Fennec UI on the Palm Pre

I should probably have expected it. Loads of places posted only the screenshot and not the background description to it, my fault really for not getting the blog post up in time. Even then I didn’t say a lot about why I was using the full Firefox UI either so of course lots of people complained about how terrible the UI was and it would never be any use and was this some sort of joke? The thing is that during that early work having nice looking UI is really unimportant, maybe even detrimental to getting things done. All that is important is that you can see enough to see that things are working. Because of this it makes more sense to use Firefox’s desktop UI for testing as it is complicated and uses many different types of UI elements. If anything wasn’t working properly it would be obvious pretty quickly. In contrast the Firefox Mobile (commonly referred to by its codename Fennec) UI is simple and stays out of your way. Most of the time you can’t even see any of the UI, just the webpage. So you wouldn’t actually notice very quickly if a part of the UI was broken.

Once the code to run Firefox on the Pre was working switching between the full Firefox UI and the Fennec UI is actually pretty simple, basically just a different build configuration. Now that things are working I’m mostly testing with the simpler Fennec UI which hopefully looks more usable on the small screen. There may still be some work to do though, The Palm Pre has a smaller screen than I think any other device that the Firefox Mobile team develop for which means it is still perhaps too large to be useful. I’m looking at ways to solve that without having to fork the entire UI.

In the meantime here is a shot of what it looks like right now. This is a screenshot taken straight from the device.

Why the Palm PDK doesn’t suck

At least one site took my comments about problems debugging to mean that I didn’t think much of developing against Palm’s PDK, literally turning my statement that “Debugging is hell” into “Palm Pre coding is like hell”. This couldn’t be much further from the truth. For a mobile platform developing for the Pre seems remarkably easy. Granted this is the first mobile platform that I’ve ever developed for but the fact that it was basically a few hours before I had a command-line program compiled for and running on the phone seems like a testament for just how easy Palm have made this. Yes there are some teething problems with things missing from the PDK, but it is in beta, I’ve seen important bits missing from SDK’s released by Microsoft that are somewhere around their 7th version so in comparison Palm are doing great. And yes debugging is difficult, but debugging is difficult even on desktops. There has been really only one problem where I got completely stuck and had no way to try to figure it out myself, and in that case the Palm developer relations team stepped in and very quickly gave me the solution I needed.

Where are things now?

Since Palm helped me solve the main hanging problem a couple of days ago I’ve been working on resolving the main stumbling blocks to being able to really browse the web on the phone by fixing little things like making characters like “/” and “:” work from the keyboard. I’ve also added orientation detection so you can browse in portrait or landscape mode and fixed ctypes to work, it is this latter bit that will allow a future version of the Weave extension to work on the phone letting you sync bookmarks and history with your desktop. There are still a couple of bits that I’d really like to fix before letting people get their hands on this, like zoom and gesture support but I wouldn’t be surprised if I have those fixed very soon now.

I’m going to be at Palm’s developer day on Saturday if anyone wants to say hi, I’ll try to remember to load a working copy onto my phone to show off before I go.

One of the first things I did when I moved to the U.S. was to get myself a smartphone, and that phone was the Palm Pre. I’ve always thought it was way ahead of its competition in terms of the potential of its potential capabilities and platform. Sadly I think it is let down some by build quality and hardware issues, but I still love it as a phone and really hope that if Palm get bought they’ll continue work on it and develop a better 2nd gen version.

The browser on the Pre is pretty limited. I won’t deny it is nice to use but I miss things like the awesome bar from Firefox and so ever since Palm announced the PDK (a development kit for developing native apps for the Pre) I’d been wondering how much work it would take to get Firefox ported to the Pre. It turns out not a lot, at least so far. Unless you’re actually interested in the details of what I did you may just want to skip to the end of this post, or just move on to something more interesting.

Getting started

I had spoken to Vlad Vukicevic a while ago. He had gone through the process of porting Firefox for Android and he told me the steps to take were pretty straightforward. You basically have to get the core pieces (NSPR, Spidermonkey, XPCOM) compiling for the platform, then you need to write what is called the widget code and deals with displaying graphics on the screen and receiving input events from the device.

On Friday evening I sat down and for the first time seriously looked through the PDK documentation, which is reasonably good. Perhaps not surprisingly I quickly realised that the core libraries that are available in the device are basically the same as those available in Android’s NDK. Added to that I had read that Vlad was simply using OpenGL to draw to the screen, and the PDK provided OpenGL too. So ignoring input events it looked likely that I could just use a lot of the code they had used for the Android port to make things work on the Pre.

This turned out to be pretty much true. Getting Firefox compiling for the Pre took a little under half a day, mostly because of some strange build config problems that I still haven’t properly resolved and have just hacked around for now. The first thing I tried was copying the JS shell over to the device and running it. Aside from some library loading issues it basically worked first time and I could run simple JavaScript code.

Debugging is hell

Getting it to render a UI was slightly more involved. Writing the actual code to do it was simple and maybe took me an hour or two (mostly because I was just copying and adapting the Android code). The thing that took the long time (around 8 hours) was trying to find the one tiny line of code that I missed and was causing Firefox to crash shortly after startup. Firefox’s code is pretty complex, and while you can get so far with adding lots of logging there was just too much going on to find this bug this way so debugging with gdb is generally the solution. Apparently in the Windows version of the PDK Palm include an Eclipse plugin that allow you to remotely debug apps running on the device. Nothing like that seems to be included in the OSX version so I ended up having to find and build a gdb that would debug ARM code (Palm, please just include this in the next OSX PDK) and then set up gdbserver on the device and connect to it. Perhaps because of my self-built GDB symbol tables for shared libraries simply didn’t work right. For some reason my gdb never attempted to load symbols for libraries that the device loaded, I ended up having to use a horrific hack to force it to load them. It paid off though, 5 minutes after I got the symbols to load I found my problem and had Firefox running without crashing, just not displaying much.

Turns out it was trying to but my first attempt to read events from WebOS were blocking the load of images and XUL for the UI. I discovered this completely by accident when I got frustrated with the blank screen and tapped it a few times, moments later the Firefox UI appeared in all its squished glory. I hope you’re all as astounded as I was that it appeared basically pixel perfect the first time around. Credit should go entirely to the guys working on the Android port for that really.

Hot tip for new widget developers, when nsBaseAppShell calls your widget’s ProcessNextNativeEvent and tells it it may block for the next available event, don’t block.

What next?

Once the UI was visible it wasn’t very difficult to start pushing mouse (finger) and keyboard events through from WebOS to Gecko. All in all getting to that point took about two days though probably would have been half that if debugging had worked straight off. There are now a bunch of smallish issues related to mouse and keyboard events that need fixing and should be pretty simple to handle. The repainting code is also very inefficient as it redraws the entire screen in response to a single pixel changing. I’d also like to switch to the Fennec UI. The Firefox UI is good for testing as it is pretty complex and you can quickly see if there are any problems or not, but the Fennec UI will make far better use of the available screen space.

There are some larger issues though that would need to be fixed before I’d consider making this available to others. In particular right now it will randomly hang the entire phone. Once that happens you have to pull the battery to recover it and I’ve lost some settings on my phone because of that. I have no way to debug that right now since once it happens there is no way to see what is going on on the device (maybe someone out there has some suggestions on how to figure this out). As well as that the build system is pretty much hacked to work on my computer. I think there is just one small thing I’m not understanding there and then I can fix that, but finding people knowledgeable enough about Mozilla’s build system to help me figure it out is difficult. Once I’ve ironed out these issues I’ll make the code available, maybe even some test builds and hopefully some other developers might be interested in helping me tackle some of the remaining problems.

Perhaps it goes without saying but I am only working on this in my spare time, not as part of any official Mozilla drive to target the Palm devices. I don’t know if it will ever get to the point where Mozilla would include it as one of the official Firefox Mobile versions, but that isn’t all that much of a big deal. Assuming the main code that deals with the Pre’s hardware and platform is sound, the code should just continue to work whatever they do with the Fennec code and I know the mobile team will always be helpful to talk about how other devices work to help me figure out what the Palm code should do.