As we have been progressing towards a multi-process Firefox we have seen many bugs filed about slowness that after investigation turned out to be related to add-ons interacting poorly with the way multi-process Firefox now operates. This doesn’t necessarily mean that the add-on author has done anything wrong. Instead code that worked fine with single-process Firefox now behaves differently as seemingly innocuous calls can cause synchronous calls from one process to the other. See my previous post on unsafe CPOW usage as example of how this can occur.

This motivated us to start trying to measure add-ons and detect when they may be slowing down a user’s browser such that we can notify the user. As luck would have it, we recently made a key change that makes all of this possible. In bug 990729 we introduced “compartment-per-add-on” (though there may be multiple compartments per add-on), such that add-on code and Firefox’s js code run in separate compartments. This allowed us to then track the amount of time we running a particular add-on by measuring the time spent in the compartments associated with that add-on. We did that in bug 1096666.

That has allowed us to start notifying users when we notice add-ons running slowly on their system. The first cut of that recently landed from bug 1071880, but a more polished UX is being tracked by bug 1124073. If you’re using Nightly and testing e10s (multi-process Firefox) and are notified of a slow add-on, please try disabling it to see if it improves how Firefox is running and report your results to You can see the raw data of what we are measuring by having a look at about:compartments. Also note that all of this is experimental. In fact, we’re already rewriting how we measure the time we spend in compartments in bug 674779.

Cross Process Object Wrappers (aka CPOWs) are at the same time amazing and terrible. They are amazing in that they make things Just Work™ in Electrolysis (e10s). One of the major issues with converting Firefox code to work under e10s is chrome code that runs in the chrome process and would previously access content directly. Without CPOWs, this access would simply fail. With CPOWs in place, the code can carry on accessing these JavaScript objects that “live” in the content process. Having this mechanism in place has allowed us to have a working browser relatively quickly without the need to rewrite all of the code at once.

The trouble comes with the fact that in order to accomplish this magic, CPOWs send synchronous IPC messages to the content process. First of all, there is the general IPC overhead. Next, when you issue a synchronous IPC message from the chrome process, everything on the main thread of the chrome process comes to a complete stop until the content process gets around to handling that IPC message.

One of the scariest parts of CPOWs is that they allow synchronous messages to flow in both directions between the content and chrome processes. That kind of arrangement can be a recipe for deadlocks. We avoid them by forcing one side (the child) to process its incoming message while it waits for a response to its outgoing message. That has worked well so far. Other than some plugin-related issues that are solvable, we’re not aware of any CPOW-caused deadlocks in e10s right now (bugs are always possible of course). Unfortunately, performing this trick sometimes requires messages to be delivered in a different order than they were sent. In such situations, rather than deadlock or deliver messages out of order, we intentionally crash. Bug 1086684 is one example. We’ve been fixing these crashes on a case-by-case basis, but each one requires careful reasoning to fix.

There is, however, one circumstance where it is safe to do this, and that is while the chrome process is handling a synchronous message from the content process. In that circumstance, the content process is in a known good state and has nothing to do on the main thread other than handle the chrome process’s IPC messages. At this point the only downside is the IPC overhead.

So, with that context earlier this week I landed bug 1097998 which logs a warning to the console whenever CPOWs are used outside of this safe circumstance. Going forward we will be working to remove any instance of this unsafe usage from our code. Eventually, this may throw an exception (or some similar mechanism) to ensure we don’t regress.

I’m happy to announce that James Willcox, better known to many as snorp, is now an Android Widget peer. James has been doing reviews and acting as a de-facto peer for a while now so it is about time to make it official.

In reviewing this module ownership and speaking to the current peers, Vlad, Doug and Michael Wu have been removed from the peers list. While each of them have made fundamental and foundational contributions to the porting of Gecko to Android, all 3 have moved on to other projects over the last couple years and the code base has changed significantly since. I would, however, like to thank them for their contributions and say that I’m looking forward to any patches they may want to throw our way in the future.

Thanks to the great work of Kim Moir we now have nightly builds of Firefox for Android x86. If you have one of these devices, such as the Motorola Razr I, ZTE Grand X or Intel Black Ray you can download a nightly from here.


There is plenty of work to go before we can roll support for x86 out to our release channel, such as being able to produce signed release builds, bringing up automated testing in our continuous integration system, performance testing and of course QA. All of which is underway already. Once the quality and testing are up to our usual standards you should be able to find Firefox in a Google Play store near you. I’ll be sure to blog about it when that happens.

As I write this I’m sitting on a Virgin flight to SFO from Boston. Strangely enough, exactly 5 years and a day ago I was also on a Virgin flight to SFO from London. Back then I was flying out to start my new job at Mozilla. Earlier that year I had started to get antsy in my previous job and when Doug T heard about it he asked if I’d be interested in coming to Mozilla. My first thought was “there’s no way I could hack it at Mozilla.” In the previous 2 years I had been working with Doug T on Minimo and was consistently impressed and humbled by by the abilities of everyone I had interacted with at Mozilla.

My second thought was that I really had no interest in working on Joey. About a year ago the MoCo had officially stopped working on Minimo, not believing it was worth investing limited time and energy into a mobile browser. But Schrep was pretty convincing in telling me that Mozilla had changed its mind and was now serious about investing in a mobile browser and building a team to do it.

So I flew out, interviewed, got the job and the rest is history. We’ve had 3 great 1.0-like Fennec releases since then (side note: the name Fennec came from a google search for “small fox”), plus one aborted release for Windows Mobile which got to Alpha before Microsoft pulled the plug on Windows Mobile.

First we released a single process XUL-based product in January 2010. Responsiveness was an one of the biggest complaints about that release, so we largely rewrote the product to be multiprocess, but still XUL based. We released that as Firefox 4.0 for Android and Maemo May 2011. That release also got us on the same shipping schedule as desktop Firefox. We stayed on the rapid release schedule for 6 more releases, but eventually it became obvious that our start up time and memory footprint (which was causing Android to kill us in the background) were preventing us from being a competitive product on Android. So we re-wrote the product once more. This time we went with a native UI, which could come up fast so the user can start interacting with the product right away. We also switched back from the multiprocess architecture to a single process architecture, but retained our responsiveness by making that one process more multithreaded.

Looking back at the last 5 years is pretty satisfying at this point. Its been a winding road, but we’ve wound up in a great place. Firefox for Android is a product that I feel great telling my friends about. Even still there are plenty of exciting things coming down the road and some great challenges we need to wrap our heads around.

The mobile team is coming to Boston the 3rd week of August along with some of our friends from graphics, layout, sync, automation and QA for a work week. As part of the week we’re holding a hack day focusing on mobile games and mobile add-ons on Thursday August 16th on the 7th floor of 281 Summer st. in Boston (aka Space with a Soul).

The day will start out with a couple quick talks to help people get started with technologies they might not be familiar with. Mark Finkle will walk everyone through how to create restartless (aka bootstrapped) add-ons in the new native front end of of Firefox for Android. Vladimir Vukicevic will show off some of Firefox for Android’s capabilities as a gaming platform. Finally Pascal Rettig will talk about tips and tricks for HTML game development.

Following the presentations will be pitch time. If you have an idea, you get 1 minute to pitch it to the group and get people excited. We’ll then break for lunch and let people form teams around those ideas. The rest of the day we’ll spend cranking out code. Finally, to wrap up, the teams will have an opportunity to show off what they’ve created at the end of the day.

If you can join us please register at and start brewing up some ideas.

We launched pretty cool product about a month ago. It got lots of really great coverage in the press. After spending 9 months rewriting Firefox for Android, we’re really happy with the results. But that mostly just establishes a baseline for us and onward we go. Firefox 15 has lots of great new features that I promise I’ll blog about real soon.

Right now we’re super excited to call attention to the fact that we are bringing support for ARMv6 to Firefox for Android. Specifically, we landed all of the patches needed for ARMv6 support during Firefox 16’s time on trunk. So as the Firefox 16 train rumbles along the tracks to the Aurora station, we now have Aurora nightly builds and an associated update channel to keep you on the latest and greatest. These are the obvious continuation of the ARMv6 trunk nightly builds that Armen blogged about.

Now you get to choose between staying on the bleeding edge and seeing the latest and greatest things on the Nightly channel, or a more stable experience on our Aurora channel. Either way, you’re helping us ship a great product for ARMv6 users.

What is ARMV6 you ask? Well, ARM is the CPU architecture that powers the vast majority of mobile devices. As with everything technology related, the ARM Architecture evolves and with each new version of ARM new features get added that allow developers to either do entirely new things or maybe just do old things faster.

Specifically, we choose to target ARMv7 originally to take advantage of the Thumb-2 instruction set that was introduced with that version of the architecture. The main benefit of the Thumb-2 instruction set is it produces smaller binaries. In fact the ARMv7 (using Thumb-2) version of is 40% smaller than the ARMv6 version of (23.8MB vs. 17MB). In addition, the smaller binary size results in a performance benefit since more of the library’s binary will be cached at any given time. it should be noted though that due to compression, the resulting ARMv6 apk  is only 2MB bigger than the ARMv7 apk.

When we made the decision to use Thumb-2 binary for Firefox, the Android Market only allowed you to ship one version of your app at a time. Since then the Android Market (eventually renamed Google Play) added support for shipping different APK’s to different devices. This opened the door to us being able to ship the smaller and faster binaries to devices that were compatible with it and at the same time address the other half of the market which is running on ARMv6 hardware.

So, if you’ve previously been unable to get Firefox from the Google Play Store, please go grab an Aurora build and give it a try. We’d love to hear your feedback, which you can provide by signing up for the ARMv6 Mobile Test Drivers mailing list, and you’ll be helping to bring Firefox to millions more users who have been left behind by modern browsers.

Firefox 8 for Android is now being built with NDKr5. Bug 657723 tracked deploying the updated NDK to our build slaves and updating the configuration to use it. After a couple of hiccups along the way we started producing on change builds with it on Wed July 27th and the first NDKr5 built nightly went out the following Thursday. We will build Firefox 6 and Firefox 7 with NDKr4 as we want to get a full development cycle’s worth of testing with the new toolchain.

This is important for a couple reasons. First, it gave us some nice performance improvements. I’d love to show you some nice graphs that illustrate that, but our data is so noisy that it depresses me. Anecdotally, several Mozillians have come on the #mobile irc channel in the last few days to comment on the improved snappiness they’d noticed over the weekend.

But, the biggest thing for me is that you can now build Firefox for Android using a stock NDK. Previously you had to use our custom built NDK (which was built on the crystax NDK) to support the usage of STL in Mozilla. This should make it much easier for your casual Android developer to drop in and contribute to Firefox on Android.

To get started building Firefox for Android with NDKr5, check out the build instructions here. Or if you want to get started a little more quickly, you can grab the development VM I posted about.

About a year ago I posted a VMWare VM that had been set up to build Fennec for Android. That was still pretty early in the development of Fennec for Android and things have changed a lot since then. In particular, we now support developing with a stock NDKr5 (or NDKr6). So, I’ve created a new VM with these updated tools and an updated tree, which can be found here.
We’ll be moving to NDKr5 for our production builders as soon as we can resolve some issues we have with our testing automation. You can follow that progress with bug 657723

Since we switched to the rapid release process, the mobile team has been using tracking-fennec to track bugs we care about for a particular release (so that tracking-fennec=7+ means the patch or feature either landed in Firefox 7 or we expect it to). Yesterday we added another possible value to that in just a plain plus (“+”).
The motivation for this change is that there is a set of bugs that we know we care about and want to keep “on the radar” but that we can’t say with any certainty will land in a given release. When we get more clarity on that we can change the tracking flag to reflect that new information.
Since we’re not tracking the bugs marked tracking-fennec=+ for a given release, the drivers won’t be as religious about finding assignees for them. So if you’re looking for something to work on, have a look at the queries listed under “Bugs to pick up” on this page. They are essentially open, tracked bugs and unassigned, open tracked bugs.

Next Page »