The Mozilla Open Data Project

The Mozilla Open Data Project is an index of all of the open APIs and data-sources available in the Mozilla project.

It’s also something that does not exist yet!

Or maybe it does, but I couldn’t find it…

Anyways, we’ve got massive amounts of data available throughout the project, from check-in logs to performance data to bugzilla APIs. However, there’s no central location that lists all of the sources that currently exist. This also means that’s it’s not easy to scan and see what’s not available that should be.

Maybe this is something we should list on a public index that already exists, like Programmable Web.

For now, I started a list here: https://wiki.mozilla.org/Modp

Please add any sources of data or public APIs that you know of to that list, or here in the comments and I’ll add them for you.

UPDATE: To clarify, this is different than the community metrics work being done by the Metrics team. But we’re talking about having this information available in the metrics portal at some point in the future, likely driven off a publicly editable source.


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.

Install

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 (https://bugzilla.mozilla.org/show_bug.cgi?id=675539).

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

EXPERIMENTAL. MAY EAT YOUR SESSION OR DO OTHER BAD THINGS.

INSTALL

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.

Benefits:

  • 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 Internetworldstats.com). 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:

Screenshot

The code:

require('awesomebar').add({
  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) {
        suggest({
          title: 'Translated text in ' + lang + ': ' + translatedText,
          url: 'http://translate.google.com/?tl=' + lang +
               '&q=' + encodeURIComponent(text),
        }, true);
      });
    }
  }
});

function translate(lang, text, callback) {
  require('request').Request({
    url: 'http://ajax.googleapis.com/ajax/services/language/translate',
    content: {
      v: '1.0',
      q: text,
      langpair: '|' + lang
    },
    headers: {
      Referer: require('tabs').activeTab.location
    },
    onComplete: function() {
      callback(this.response.json.responseData.translatedText);
    }
  }).get();
}

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.


Follow

Get every new post delivered to your Inbox.