Visualizing web page memory use in Firefox

I remixed about:memory using D3 to make a treemap visualization of how loaded URLs are using memory in Firefox.

Load it by clicking the widget on the add-on bar, or Cmd/Ctrl+Shift+Y

This visualization focuses on which web pages are using large amounts of memory – this is not a complete accounting of all memory being used. This doesn’t yet show how much is being used by some of the Firefox internals.

Add-on installation does not require a restart. Only tested on Nightly builds.


Source code

Dormancy: Freeing up memory from unused tabs

Dormancy ‘retires’ tabs that have gone unused for a while, freeing up that memory. It then restores the tabs to life when accessed.

While Firefox 9 adds restore-on-demand for users that restore their session by default, many users will never benefit from it. This add-on targets users who don’t restore session, but do have long-running instances of Firefox and many tabs. This might land as a core feature in Firefox 9 (

NOTE: This is highly experimental, has only been tested on the Nightly builds, and probably will destroy your session. You’ve been warned.

Tabs are considered inactive when they haven’t been selected in longer than 5 minutes. To change that, set this pref to a value in milliseconds:

* extensions.dormancy.TabDormancyAgeMs

Tabs are checked for inactivity every 5 minutes. To change this, set this pref to a value in milliseconds:

* extensions.dormancy.TabCheckIntervalMs

Known bugs:

  • Awesomebar entry for dormant tabs shows data URI
  • Sometimes dormant tabs have no title and no favicon



Source code

Wallflower: Un-Socializing Your Web

I was looking at about:memory and noticed entries for Facebook and Google+ URLs, even though I didn’t have either open. I figured they were probably from the social buttonry that decorates the web these days. No big deal… except they were taking up a bunch of memory! The Facebook button was using over 20mb and the Google+ button was taking over 40mb!

I have never clicked either of these buttons.

So I wrote Wallflower, a simple Firefox add-on (restartless of course) that removes these buttons from any page your browse to, saving your precious memory, CPU and battery life for the content you actually want.

Install Wallflower.

View the source code on Github.

Peek: Apps, App Tabs, and Context.

The new app tab feature in Firefox is great. I use it a lot… which has starkly illustrated how apps and tabs have very different use-cases and usage patterns. Often I will check my Gmail app tab because I see the glowing notification that a new email has arrived, do something (or nothing), and then pop back to where I was browsing… in one of those 78 tabs I have open?!
The windowing model in operating systems allows me switch back and forth between contexts with ease. But app tabs do not:

  • If I’m using my Gmail app tab and I didn’t open any links while there, I can still see the last tab I was at, and click on it. But I have to use the mouse if I want to get directly back there.
  • Out of sheer muscle memory and mouse-averseness, sometimes I can traverse tabs via the next/previous-tab keyboard shortcuts to get back to where I was. Sometimes it’s a *lot* of tabs, so either I’ll hold the arrow key down, speeding past the tab I wanted (and back and forth a few times), or I’ll just hit the arrow key a bunch of times in quick succession. Both options are frustrating, slow and RSI-inducing.
  • Or I could expend mental energy to search in the awesomebar and switch to that tab, which often looks like this: “hm, type ‘bug’ and then try to remember some words in the bug summary, but those words match a bunch of other bugs, and i don’t know the bug number, and also I’m on an attachment page because I’m reviewing a patch on the bug, so the summary won’t be in the page title…” and on and on. Now add the fact that switch-to-tab rarely even shows up in the awesomebar for me, and well, a generally high level of fail with this option.

Then there’s link opening:

  • Links opened in app tabs are put at the beginning of your tabs, and the tab strip is animatedly scrolled there. Boom, instantly lost where I was before checking my email.
  • We tried an experiment where they open at the end of the set of open tabs. I found that to have serious “out of sight, out of mind” problems. That experiment was rolled back. And it doesn’t necessarily solve the context problem anyway.
  • Both approaches cause excess amounts of whizzing animations, either when you want to “go around the horn” to get to the tabs you just opened from app tabs, or when you want to go to them and then get back to where you were.
  • There’s no right answer! Sometimes I see a link to a recipe in my Seesmic app tab that I’d like to open in that series of tabs related to food that I have open somewhere in the middle of my open tabs. The user is not in control of *where* these links are opened. I can’t choose whether to open them at the beginning or end of the tab strip, or in a new tab group, or new window, etc. Part of me thinks that I actually might work best in a world where each app tab is bound to a single tab group, so that tab growth is bound to the source… but that’s a vision for another day (and blog post and add-on).

So I’ve made Peek, an add-on that’s a hybrid solution: Instead of making you go to your app tabs, your app tabs will come to you. Peek allows you to open your app tabs in a floating panel that opens on top of wherever you are in your tabs. Links open to the right of whatever your current active tab is, and in the background, so that when you’re finished peeking, you are exactly where you left off.

To use Peek, first create some app tabs. Then you can peek at them using the keyboard shortcut ALT+SHIFT+1-9 where the number corresponds with the order your app tabs are in. To stop peeking, hit escape (or switch apps or anything else that takes focus away from the panel).

INSTALL. Peek is a Jetpack add-on that does not require a restart of the browser. User beware: This is an experimental add-on – I’ve been using it on Nightly builds, but haven’t done much testing elsewhere.


  • Interact with your apps, and when you’re done, be exactly where you left off browsing.
  • Links are opened in the context of wherever you’re peeking.

Firefox, Android and ARMing the World with the Open Web.

I’ve been meaning to blog about this for a while, and Singularity Hub’s article about the explosive sales of low-cost Android phones in Kenya reminded me to actually do it.

I was lucky enough to attend a bunch of different tech events outside of the USA in the last year. I went to events in Thailand, Cambodia, Laos, Vietnam, Indonesia and Kenya. I also visited Malaysia and China, and briefly crossed the border into Burma.

Everywhere I went I found Android.

As the article mentioned, Huawei’s IDEOS phones are selling fast in Kenya at ~80USD. These were on sale in the airport in Nairobi, and in many of the mobile shops I went into. Nexian is a manufacturer in Indonesia, with a bunch of Android phones aimed at the mid- to low-end market. In Thailand, HTC is the big Android purveyor (and always *one* Windows phone on offer!). Their low-budget phones in the US are the mid-range phones in Thailand, such as the Wildfire and Tattoo. There were a bunch of other brands and models, I really should’ve taken pictures. The advertising was everywhere. Google was holding Android dev days in major cities. The presence was constant and sometimes unavoidable – like when I rode a tuk-tuk into Siem Reap from the airport and we drove under a Google/Android banner that crossed all 6 lanes of traffic.

Anyways, everywhere I went I was asked why Firefox wasn’t in the Android Market, or if it was, people said that it wouldn’t install, or crashed before starting up.

Well, the explanation is that not all Android devices are equal. The Android devices that are selling well in these countries are very low cost devices. They’re selling in places where 40% of the population lives on less than 2USD per day (Kenya, according to that article), or where >80% of the populace is not even online yet (less than 20% of Indonesia is online, according to The ARM CPUs that these Android phones have are not very powerful, and they usually have little memory. Often these devices are running 1.x versions of Android. Their screens are small and have the best resolution you could get in a phone in 2002.

But that’s only part of the explanation. These phones all come with browsers! Why can’t they install Firefox instead?

  • Firefox on Android doesn’t support the ARM CPUs commonly used in these phones.
  • Firefox is not realistically usable given the amount of memory many of these phones ship with.

There’ve been bugs filed about supporting Android devices with weak CPUs, little memory and poor screen resolution, but no traction. The mobile team has explicitly not targeted these phones. Maybe this is because Firefox as it exists today is too far away from being able to run under these conditions. If that’s the case, maybe we need to look at other options, like radically cutting down the feature set, even further than Fennec did.

I don’t think we can wait for decent hardware to become affordable in these markets. They are growing fast, and turning to the Android they can get, and taking the only Web they can get: The one they can afford. There’s not much choice in that scenario, and choice is a key part of the Mozilla mission. When the other 80% of Indonesia comes online for the very first time, Mozilla and Firefox should be there, ready to provide that choice.

Extensibly Awesome: A Jetpack API for the Firefox Location Bar

I tweaked some of Mardak’s code for the Twitter Add-on, and created a Jetpack module that makes it terribly simple to write add-ons that extend the awesomebar with your own suggestions. As an example, here’s an add-on that uses the Google Translate API to translate text into a specified language directly in the location bar. If you type in the keyword ‘translate’, followed by a language code and some text, it will show the translation in the awesomebar results:


The code:

  keyword: 'translate',
  onSearch: function(query, suggest) {
    let lang = query.substring(0, query.indexOf(' '));
    let text = query.substring(query.indexOf(' '));
    if (lang.length == 2 && text.length > 2) {
      translate(lang, text, function(translatedText) {
          title: 'Translated text in ' + lang + ': ' + translatedText,
          url: '' + lang +
               '&q=' + encodeURIComponent(text),
        }, true);

function translate(lang, text, callback) {
    url: '',
    content: {
      v: '1.0',
      q: text,
      langpair: '|' + lang
    headers: {
      Referer: require('tabs').activeTab.location
    onComplete: function() {

The example needs niceties such as being able to write full language names, but you get the gist.

Here’s the awesomebar.js module.

There’s a bit of documentation in there. The code could use some cleanup, and could probably be much smaller if converted to use the internal Jetpack APIs for things like window-watching, etc.

Barcamp Chiang Mai (or: Communicating Mozilla)

Barcamp Chiang Mai was last Saturday. Registration was double what we expected, and actual turnout was fantastic. There were great sessions on HTML5, building the Chiang Mai tech community, web platform toolkits for building mobile apps, and many others. I gave a general talk, covering Mozilla as an organization, Firefox 4, and then a quick overview of a bunch of various projects in the Mozilla world. Slides and links here. Some of the feedback I got from people after this talk:

  1. how little they knew about Mozilla before the talk
  2. how they were going to upgrade to Firefox 4 immediately
  3. or had already upgraded but didn’t know about any of the features I covered
  4. had no idea that Mozilla had any projects outside of Firefox
  5. didn’t know we had a mobile browser (and were subsequently bummed because it didn’t run on their phone)

The geeks didn’t know about the Web Console, and knew little or hadn’t heard about most of the Mozilla Labs projects I mentioned. And most developers that I talk to *still* don’t know that Firefox add-ons are written in JavaScript, let alone Firefox itself.

A large number of both geeks and non-geeks were using Firefox 4 but hadn’t heard about App Tabs or Panorama or Switch-to-Tab. If we don’t already, we should probably do user testing to see if pages like this are actually effective. Or maybe we just need to push them more?

Compared to Apple (46,000 employees), Google (26,000 employees) and Microsoft (89,000 employees), we’re a tiny penniless rag-tag group. I think we broke 400 employees this year! So slathering whole countries in advertising isn’t really an option, and isn’t our style anyway. For a long time we’ve talked about using Firefox itself as a vector for this type of communication, with things like built-in tutorials and introductory wizards for major upgrades. Now that we have about:home, that might be a good place to communicate news about Mozilla the organization, highlighting specific people in the project and important milestones (“500th employee hired!”, “One million bugs filed!”). I’m sure the Engagement group is thinking about these things already (RIGHT?!).

Every time I talk about Mozilla publicly, whether at a technology event or to a random person in line at an airport (I always wear a Firefox shirt when traveling!), I meet people that know very little about this piece of software they use every day and the organization behind it. This experience has been the same at US events, everywhere that I’ve been in SE Asia in the last year, and in Kenya last month as well. We might be a household name, but we’ve still got a lot of work to do on communicating effectively to both geeks and non-geeks alike.


Get every new post delivered to your Inbox.