Featured Articles

Sort by:


  1. Hacking Firefox OS

    This blog post is written by Luca Greco, a Mozilla community member who loves to hack, especially on JavaScript and other web-related technologies.

    A lot of developers are already creating mobile applications using Web technologies (powered by containers like Phonegap/Cordova as an example),
    usually to develop cross platform applications or leverage their current code and/or expertise.

    As a consequence Firefox OS is a very intriguing project for quite a few reasons:

    • Web apps have first class access to the platform
    • Web apps are native (less abstraction levels and better performance)
    • Platform itself is web-based (and customizable using web technologies)

    Mobile platforms based on web technologies can be the future, and we can now touch it, and even more important, we can help to define it and push it further thanks to a platform (Firefox OS) developed completely in the open. I could not resist the temptation, so I started to dive into Firefox OS code, scrape it using MXR and study documentation on the wiki.

    Hack On Firefox OS

    In a couple of weeks I was ready to put together an example app and an unofficial presentation on the topic (presented at the local LinuxDay 2012):

    Slides: “Hack On Firefox OS”

    Example App: Chrono for Gaia (user interface of Firefox OS):

    During this presentation I tried to highlight an important strength I believe Firefox OS and Firefox have in common:

    “It’s not a static build, it’s alive! a truly interactive environment. Like the Web”

    I can telnet inside a B2G instance and look around for interesting stuff or run JavaScript snippets to interactively experiment the new WebAPIs. There’s more than one option to get a remote JavaScript shell inside B2G:

    • Marionette, mainly used for automated tests
    • B2G Remote JS Shell, a minimal JavaScript shell optionally exposed on a tcp port (which I think will be deprecated in future releases)

    Unfortunately these tools currently lack integrated inspection utils (e.g. console.log/console.dir or MozRepl repl.inspect and, so during the presentation I opted to install MozRepl as extension on the B2G simulator, but in the last weeks Remote WebConsole landed into Firefox Nightly.

    Obviously RemoteWebConsole isn’t mature yet, so we need to be prepared for bugs and silent errors (e.g. we need to be sure B2G has “remote debugger” enabled or it will fail without errors), but it features objects inspection, network progress logging, JavaScript and CSS errors (like our local Firefox WebConsole).

    Developing for Firefox OS

    In my experience, developing an OpenWebApps for Firefox OS isn’t really different from hybrid applications based on Phonegap-like technologies:

    We’ll try to code and test major parts of our application on desktop browsers and their development tools, using mockups/shims in place of native functionalities. But during my 2 weeks of studying, I’ve collected an interesting amount of working notes that can be useful to share, so in next sections I’m going to:

    • Review development workflow and tools
    • Put together a couple of useful tips and tricks
    • Release to the public (independently and in the Mozilla Marketplace)

    As an example app, I’ve chosen to create a simple chronometer:

    Workflow and Tools

    During this experience my toolset was composed by:

    • VoloJS – development server and automated production build (minify js/css, generate manifest.appcache)
    • Firefox Nightly Web Developer Tools – Markup View, Tilt, Responsive Design View and Web Console
    • R2D2B2G – integrate/interoperate with B2G from a Firefox Addon

    Using Volo, I can test my app from volo integrated http server, split JavaScript code into modules using Require.js, and finally generate a production version, minified and optionally equipped of an auto-generated manifest.appcache.

    During my development cycle I iteratively:

    • Make a change
    • Reload and inspect changes on desktop browser
    • Try changes on b2g-simulator using R2D2B2G
    • Debug on desktop browser or remotely on b2g-simulator
    • Restart the loop :-)

    Using my favorite desktop browser (Firefox, obviously :-P), I have the chance to use very powerful inspection/debugging tools, not usually available on mobile web-runtimes:

    • Markup Viewer to inspect and change DOM tree state
    • Styles Editor to inspect and change CSS properties
    • Tilt to check where offscreen dom elements are located
    • Web Console to inspect and change the JavaScript environment

    Thanks to new Mozilla projects like “Firefox OS” and “Firefox for Android”, more and more of these tools are now available as “Remote Web Tools” and can be connected to a remote instance.

    Tips and Tricks

    Gaia UI Building Blocks

    Gaia isn’t only a B2G UI implementation, it’s a design style guide and a collection of pre-built CSS styles which implements these guidelines:

    We can import components’ styles from the repo above and apply them to our app to achieve a really nice native Look & Feel on Firefox OS. Some components are not stable, which means they can interact badly with other components’ styles or doesn’t work perfectly on all platforms (e.g. Firefox Desktop or Firefox for Android), but usually it’s nothing we can’t fix by using some custom and more specific CSS rules.

    It doesn’t feel like a mature and complete CSS framework (e.g. Bootstrap) but it’s promising and I’m sure it will get better.

    Using Responsive Design View we can test different resolutions (and orientations), which helps to reach a good and consistent result even without test our app on Firefox OS or Firefox for Android devices, but we should keep an eye on dpi related tweaks, because we currently can’t fully recognize how it will looks using our Desktop browser.

    App Panels

    A lot of apps needs more than one panel, so first I looked inside official Gaia applications to understand how native apps implements this almost mandatory feature. This is how Gaia Clock application appear from a “Tilt” eye:

    Panels are simple DOM elements (e.g. a section or a div tag) initially positioned offscreen and moved on screen using a CSS transition:

    In the “Chrono” app, you will find this strategy in the Drawer (an unstable Gaia UI Building Block):

    and in the Laps and About panels (combinated with :target pseudo class):

    The Fascinating -moz-element trick

    This is a very fascinating trick, used in the time selector component on Firefox OS:

    and in the Markup View on Firefox Nightly Desktop (currently disabled):

    Thanks to this non-standard CSS feature we can use a DOM Element as background image on another one, e.g. integrating a complex offscreen visual component into the visible space as a single DOM element.

    Fragments from index.html

    Fragments from chrono.css

    Fragments from chrono.js

    Using -moz-element and -moz-calc (compute components size into CSS rules and already included into CSS3 as calc) is really simple, but you can learn more on the subject on MDN:

    Release to the public

    WebApp Manifest

    During our development cycle we install our application into B2G simulator using an R2D2B2G menu option, so we don’t need a real manifest.webapp, but we have to create a real one when ready for a public release or to release it to test users.

    Creating a manifest.webapp is not difficult, it’s only a simple and well documented json file format: App/Manifest on MDN.

    Debugging problems related to this manifest file is still an unknown territory, and some tips can be useful:

    • If the manifest file contains a syntax error or cannot be downloaded and error will be silently reported into the old Error Console (no, they will not be reported inside the new Web Console)
    • If your application is accessible as a subdirectory in its domain, you have to include this path in resources path specified inside the manifest (e.g. launch_path, appcache_path, icons), more on this later
    • You can add an uninstall button in your app to help you as a developer (and test users) to uninstall your app in a platform independent way (because “how to uninstall” an installed webapp will be different if you are on Desktop, Android or Firefox OS)

    Using OpenWebApps APIs, I added to “Chrono” some code to give users the ability to install itself:

    Install an app from your browser to your desktop system

    Check if it’s already installed (as a webapp runtime app or a self-service installer in a browser tab):

    On a Linux Desktop, when you install an OpenWebApp from Firefox, it will create a new launcher (an “.desktop” file) in your “.local/share/applications” hidden directory:

    $ cat ~/.local/share/applications/owa-http\; 
    [Desktop Entry]
    Comment=Gaia Chronometer Example App
    [Desktop Action Uninstall]
    Name=Uninstall App
    Exec=/home/rpl/.http; -remove

    As you will notice, current conventions (and implementation) supports only one application per domain, if you give a look inside the hidden directory of our installed webapp you will find a single webapp.json config file:

    $ ls /home/rpl/.http\;
    Crash Reports  icon.png  profiles.ini  webapp.ini  webapp.json  webapprt-stub  

    Reasons for this limitations are documented on MDN: FAQs about app manifests

    To help yourself debugging problems when you app is running inside the webapp runtime you can run it from command line and enable the old (but still useful) Error Console:

    $ ~/.http\; -jsconsole

    Uninstalling an OpenWebApp is really simple, you can manually removing it using the “wbapprt-stub” executable in the “OpenWebApp hidden directory” (platform dependent method):

    $ ~/.http\; -remove

    Or from JavaScript code, as I’ve done in “Chrono” to give users the ability to uninstall the app from a Firefox Browser tab:

    AppCache Manifest

    This is a feature integrated a lot of time ago into major browsers, but now, thanks to OpenWebApps, it’s becoming really mandatory: without a manifest.appcache, and proper JavaScript code to handle upgrades, our WebApp will not works offline correctly, and will not feel like a real installed application.

    Currently Appcache it’s a kind of black magic and it deserves a “Facts Page” like Chuck Norris: AppCacheFacts.

    Thanks to volo-appcache command, generate a manifest.appcache it’s simple as a single line command:

      $ volo appache
      $ ls -l www-build/manifest.appcache
      $ tar cjvf release.tar.bz2 www-build

    Unfortunately when you need to debug/test your manifest.appcache, you’re on your own, because currently there isn’t any friendly debugging tool integrated into Firefox:

    • appcache downloading progress (and errors) are not currently reported into the WebConsole
    • appcache errors doesn’t contains an error message/description
    • Firefox for Android and Firefox OS doesn’t have an UI to clean your applicationCache

    Debug appcache problems can be very tricky, so here a couple of tricks I learned during this experiment:

    • Subscribe every window.applicationCache events (‘error’, ‘checking’, ‘noupdate’, ‘progress’, ‘downloading’, ‘cached’, ‘updateready’ etc) and log all received events / error messages during development and debugging
    • Add upgrade handling code in your first public release (or prepare yourself to go house by house to help your users to upgrade :-D)
    • On Firefox for Desktop you can remove applicationCache from the Preferences dialog
    • Analyze server side logs to understand where the “appcache updating” is stuck
    • Activate logging on applicationCache internals when you run Firefox or B2G to understand why it’s stuck

      export NSPR_LOG_MODULES=nsOfflineCacheUpdate:5
      export NSPR_LOG_FILE=offlineupdate.log
      firefox -no-remote -ProfileManager &
      tail -f offlineupdate.log
      -1614710976[7fc59e91f590]: nsOfflineCacheUpdate::Init [7fc55959ce50]
      -1614710976[7fc59e91f590]: nsOfflineCacheUpdate::AddObserver [7fc56a9fcc08] to update [7fc55959ce50]
      -1614710976[7fc59e91f590]: nsOfflineCacheUpdate::AddObserver [7fc55c3264d8] to update [7fc55959ce50]
      -1614710976[7fc59e91f590]: nsOfflineCacheUpdate::Schedule [7fc55959ce50]
      -1614710976[7fc59e91f590]: nsOfflineCacheUpdateService::Schedule [7fc57428dac0, update=7fc55959ce50]
      -1614710976[7fc59e91f590]: nsOfflineCacheUpdateService::ProcessNextUpdate [7fc57428dac0, num=1]
      -1614710976[7fc59e91f590]: nsOfflineCacheUpdate::Begin [7fc55959ce50]
      -1614710976[7fc59e91f590]: nsOfflineCacheUpdate::NotifyState [7fc55959ce50, 2]
      -1614710976[7fc59e91f590]: 7fc559d0df00: Opening channel for http://html5dev:8888/gaia-chrono-app/manifest.appcache
      -1614710976[7fc59e91f590]: loaded 3981 bytes into offline cache [offset=0]
      -1614710976[7fc59e91f590]: Update not needed, downloaded manifest content is byte-for-byte identical
      -1614710976[7fc59e91f590]: done fetching offline item [status=0]
      -1614710976[7fc59e91f590]: nsOfflineCacheUpdate::LoadCompleted [7fc55959ce50]
      -1614710976[7fc59e91f590]: nsOfflineCacheUpdate::NotifyState [7fc55959ce50, 3]
      -1614710976[7fc59e91f590]: nsOfflineCacheUpdate::Finish [7fc55959ce50]
      -1614710976[7fc59e91f590]: nsOfflineCacheUpdateService::UpdateFinished [7fc57428dac0, update=7fc55959ce50]
      -1614710976[7fc59e91f590]: nsOfflineCacheUpdateService::ProcessNextUpdate [7fc57428dac0, num=0]
      -1614710976[7fc59e91f590]: nsOfflineCacheUpdate::NotifyState [7fc55959ce50, 10]
      -1614710976[7fc59e91f590]: nsOfflineCacheUpdate::RemoveObserver [7fc56a9fcc08] from update [7fc55959ce50]
      -1614710976[7fc59e91f590]: nsOfflineCacheUpdate::RemoveObserver [7fc55c3264d8] from update [7fc55959ce50]

    Adding applicationCache support to “Gaia Chrono App”, I used all this tricks to finally discover Firefox didn’t send me an “updateready” event, so I was not able to tell the user to reload the page to start using the new (and already cached) version. With a better understanding of the problem, and searching in the code on MXR and in tickets on Bugzilla, I finally found an existing ticket in the bugtracker: Bug 683794: onupdateready event not fired when an html5 app cache app is updated.

    Workaround this bug its really simple (simpler than tracking it down): add a dummy “updateready” listener on applicationCache object in a script tag to be sure it will be fired:

    If you are going to start to use this feature (and soon or later you will), be prepared to:

    • Implement as suggested from the standard
    • Debug reason why it’s not behave as it should
    • Search an existent bug or file a bug if it’s not reported (NOTE: this is really important!!! :-D)
    • Find a workaround

    This is definitely a features that needs more supports into web developer tools, because a regular web developer doesn’t want to debug his webapp from “browser internals” point of view.

    Port to Firefox for Android

    An interesting feature of OpenWebApps is “they can be installed on any supported platform without (almost) any changes”. As an example we can install our “Chrono” App on our Desktop using Firefox Nightly and on Android using Firefox for Android Nightly.

    In my own opinion, Firefox for Android can be a strategic platform for the future of OpenWebApps and even Firefox OS: Android is an already popular mobile platform and give developers the option to release their application on Firefox OS and Android from a single codebase is a big plus.

    The only problem I faced porting “Chrono” App on Android was related to the different rendering behaviour of Firefox for Android (and as a consequence in the WebAppRT, which contains our application):

    A GeckoScreenshot service will force a repaint only when and where it detects changes. This feature interacts badly with the -moz-element trick and it needs some help to understand what really needs to be repainted:

    Release to the public

    GitHub pages are a rapid and simple option to release our app to the public, even simpler thanks to the volo-ghdeploy command:

      $ volo appcache && volo ghdeploy

    When you deploy your OpenWebApp in a subdirectory of a given domain (e.g. using Github Pages) you should take into account that paths from manifest.webapp needs to be relative to your origin (protocol+host+port) and not your current url:

    We can install only a single OpenWebApp from every origin, so if you wants to deploy more than one app from your Github pages you need to configure Github pages to be exposed on a custom domain: Github Help – Setting up a custom domain with pages.

    When our app is finally online and public accessible we can submit it to the Mozilla Marketplace and gain more visibility.

    During the app submission procedure, your manifest.webapp will be validated and you will be warned if and how you need to tweak it to be able complete your submission:

    • Errors related to missing info (e.g. name or icons)
    • Errors related to invalid values (e.g. orientation)

    As in other mobile marketplaces you should collect and fill into your submission:

    • manifest.webapp url (NOTE: it will be read-only in the developer panel and you can’t change it)
    • A longer description and feature list
    • Short release description
    • One or more screenshots

    Mini Market

    Mozilla Marketplace goal is to help OpenWebApps to gain more visibility, as other mobile store currently do for their ecosystem, but Mozilla named this project OpenWebApps for a reason:

    Mozilla isn’t the only one that could create a Marketplace for OpenWebApps! Mozilla designed it to give us the same freedom we have on the Web, no more no less.

    This is a very powerful feature because it open to developers a lot of interesting use cases:

    • Carrier Apps Market on Firefox OS devices
    • Non-Public Apps Installer/Manager
    • Intranet Apps Installer/Manager


    Obviously Firefox OS and OpenWebApps aren’t fully completed right now (but improves at an impressive speed), Firefox OS doesn’t have an official released SDK, but the web doesn’t have an official SDK and we already use it everyday to do awesome stuff.

    So if you are interested in mobile platforms and you wants to learn how a mobile platform born and grow, or you are a web developer and you wants more and more web technologies into mobile ecosystems…

    You should seriously take a look at Firefox OS:

    We deserve a more open mobile ecosystem, let’s start to push it now, let’s help OpenWebApps and Firefox OS to became our new powerful tools!

    Happy Hacking!

  2. Firefox OS – video presentations and slides on the OS, WebAPIs, hacking and writing apps

    In August, Mozilla’s Director of Research Andreas Gal, and one of the lead engineers for Firefox OS, Philipp von Weitershausen, gave a couple of presentations in Brazil about Firefox OS. We’re now happy to share both the videos and the slides, in various formats for you to see or use, giving your own presentations!


    The videos are available on YouTube in the Mozilla Hacks channel, and they are split up into:

    Firefox OS – Introduction & Components

    FirefoxOS – Developer Enviroment, Apps, Marketplace

    FirefoxOS – WebAPIs & UI hacking

    Note: if you’ve opted in to HTML5 on YouTube you will get HTML5 video.


    There were four different slide decks being used:

    They are also available in Portuguese:

    We’ve also made these slide decks available in other formats if you want to reuse them and give your own presentations about Firefox OS (and if you love talking about the Open Web, have you considered becoming an Evangelism Rep?).

    Keynote format

    PowerPoint format

  3. Tracking Down Memory Leaks in Node.js – A Node.JS Holiday Season

    This post is the first in the A Node.JS Holiday Season series from the
    Identity team at Mozilla, who last month delivered the first beta
    release of Persona
    . To make Persona, we built a collection tools addressing areas ranging from debugging, to localization, to dependency management, and more. This series of posts will share our learnings and tools with the community, tools which are relevant to anyone building a high availability service with Node.JS. We hope you enjoy the series, and look forward to your thoughts and contributions.

    We’ll start off with a topic about a nitty-gritty Node.js problem: memory leaks. We present node-memwatch – a library to help discover and isolate memory leaks in Node.

    Why Bother?

    A fair question to ask about tracking down memory leaks is “Why bother?”. Aren’t there always more pressing problems that need to be tackled first? Why not just restart your service from time to time, or throw more RAM at it? In answer to these questions, we would suggest three things:

    1. You may not be worried about your increasing memory footprint, but V8 is. (V8 is the engine that Node runs on.) As leaks grow, V8 becomes increasingly aggressive about garbage collection, slowing your app down. So in Node, memory leaks hurt performance.
    2. Leaks can trigger other types of failure. Leaky code can hang on to references to limited resources. You may run out of file descriptors; you may suddenly be unable to open new database connections. Problems of this sort may emerge long before your app runs out of memory and still leave you dead in the water.
    3. Finally, sooner or later, your app will crash. And you can bet it will happen right at the moment when you’re getting popular. And then everybody will laugh and say mean things about you on Hacker News and you’ll be sad.

    Where’s That Dripping Sound Coming From?

    In the plumbing of a complex app, there are various places where leaks can occur. Closures are probably the most well-known and notorious. Because closures maintain references to things in their scope, they are common sources for leaks.

    Closure leaks will probably be spotted eventually if somebody’s looking for them, but in Node’s asynchronous world we generate closures all the time in the form of callbacks. If these callbacks are not handled as fast as they are created, memory allocations will build up and code that doesn’t look leaky will act leaky. That’s harder to spot.

    Your application could also leak due to a bug in upstream code. You may be able to track down the location in your code from where the leak is emanating, but you might just stare in bewilderment at your perfectly-written code wondering how in the world it can be leaking!

    It’s these hard-to-spot leaks that make us want a tool like node-memwatch. Legend has it that months ago, our Lloyd Hilaiel locked himself in a closet for two days, trying to track down a memory leak that became noticeable under heavy load testing. (BTW, look forward to Lloyd’s forthcoming post on load testing.)

    After two days of bisecting, he discovered that the culprit was in the Node core: Event listeners in http.ClientRequest were not getting cleaned up. (When this was eventually fixed in Node, the patch consisted of a subtle but crucial two characters.) It was this miserable experience that made Lloyd want to write a tool to help find leaks.

    Tools for Finding Leaks

    There is already a good and continually growing collection of good tools for finding leaks in Node.js applications. Here are some of them:

    • Jimb Esser’s node-mtrace, which uses the
      GCC mtrace utility to profile heap usage.
    • Dave Pacheco’s node-heap-dump takes a snapshot of the V8 heap and serializes the whole thing out in a huge JSON file. It includes tools to traverse and investigate
      the resulting snapshot in JavaScript.
    • Danny Coates’s v8-profiler and node-inspector provide Node bindings for the V8 profiler and a Node debugging interface using the WebKit Web Inspector.
    • Felix Gnass’s fork of the same that un-disables the retainers graph
    • Felix Geisendörfer’s Node Memory Leak Tutorial is a short and sweet explanation of how to use the v8-profiler and node-debugger, and is presently the state-of-the-art for most Node.js memory leak debugging.
    • Joyent’s SmartOS platform, which furnishes an arsenal of tools at your disposal for debugging Node.js memory leaks

    We like all of these tools, but none was a perfect fit for our environment. The Web Inspector approach is fantastic for applications in development, but is difficult to use on a live deployment, especially when multiple servers and subprocess are involved in the mix. As such, it may be difficult to reproduce memory leaks that bite in long-running and heavily-loaded production environments. Tools like dtrace and libumem are truly awe-inspiring, but don’t work on all operating systems.

    Enter node-memwatch

    We wanted a platform-independent debugging library requiring no instrumentation to tell us when our programs might be leaking memory, and help us find where they are leaking. So we wrote node-memwatch.

    It gives you three things:

    • A 'leak' event emitter

      memwatch.on('leak', function(info) {
      // look at info to find out about what might be leaking
    • A 'stats' event emitter

      var memwatch = require('memwatch');
      memwatch.on('stats', function(stats) {
      // do something with post-gc memory usage stats
    • A heap diff class

      var hd = new memwatch.HeapDiff();
      // your code here ...
      var diff = hd.end();
    • And there is also a function to trigger garbage collection which can be
      useful in testing. Ok, four things.

      var stats = memwatch.gc();

    memwatch.on('stats', ...): Post-GC Heap Statistics

    node-memwatch can emit a sample of memory usage directly after a full garbage collection and memory compaction, before any new JS objects have been allocated. (It uses V8′s post-gc hook, V8::AddGCEpilogueCallback, to gather heap usage statistics every time GC occurs.)

    The stats data includes:

    • usage_trend
    • current_base
    • estimated_base
    • num_full_gc
    • num_inc_gc
    • heap_compactions
    • min
    • max

    Here’s an example that shows how this data looks over time with a leaky application. The graph below is tracking memory usage over time. The green crazy line shows what process.memoryUsage() reports, and the red line shows the current_base reported by node_memwatch. The box on the lower-left shows additional statistics.


    Note that the number of incremental GCs is very high. This is a warning sign that V8 is working overtime to try to clean up allocations.

    memwatch.on('leak', ...): Heap Allocation Trends

    We have a simple heuristic to warn you that your app may be leaky. If, over five consecutive GCs, you continue to allocate memory without releasing it, node-memwatch will emit a leak event. The message tells you in nice, human-readable form what’s going on:

    { start: Fri, 29 Jun 2012 14:12:13 GMT,
      end: Fri, 29 Jun 2012 14:12:33 GMT,
      growth: 67984,
      reason: 'heap growth over 5 consecutive GCs (20s) - 11.67 mb/hr' }

    memwatch.HeapDiff(): Finding Leaks

    Finally, node-memwatch can compare snapshots of object names and allocation counts on the heap. The resulting diff can help isolate offenders.

    var hd = new memwatch.HeapDiff();
    // Your code here ...
    var diff = hd.end();

    The contents of diff will look something like this:

      "before": {
        "nodes": 11625,
        "size_bytes": 1869904,
        "size": "1.78 mb"
      "after": {
        "nodes": 21435,
        "size_bytes": 2119136,
        "size": "2.02 mb"
      "change": {
        "size_bytes": 249232,
        "size": "243.39 kb",
        "freed_nodes": 197,
        "allocated_nodes": 10007,
        "details": [
            "what": "Array",
            "size_bytes": 66688,
            "size": "65.13 kb",
            "+": 4,
            "-": 78
            "what": "Code",
            "size_bytes": -55296,
            "size": "-54 kb",
            "+": 1,
            "-": 57
            "what": "LeakingClass",
            "size_bytes": 239952,
            "size": "234.33 kb",
            "+": 9998,
            "-": 0
            "what": "String",
            "size_bytes": -2120,
            "size": "-2.07 kb",
            "+": 3,
            "-": 62

    HeapDiff triggers a full GC before taking its samples, so the data won’t be full of a lot of junk. memwatch‘s event emitters will not notify of HeapDiff GC events, so you can safely put HeapDiff calls in your 'stats' handler.

    In the graph below, we’ve added the objects with the most heap allocations:


    Where to Go From Here

    node-memwatch provides:

    • Accurate memory usage tracking
    • Notifications about probable leaks
    • A means to produce a heap diff
    • That is cross-platform
    • And that does not require any extra instrumentation

    We want it to do more. In particular, we want node-memwatch to be able to provide some examples of a leaked object (e.g., names of variables, array indices, or closure code).

    We hope you’ll find node-memwatch useful in debugging leaks in your Node app, and that you’ll fork the code and help us make it better.

  4. Aurora 18: HiDPI & Touch Events

    In this Aurora cycle, Firefox gained several new interesting features:

    • HiDPI displays are now supported (like Mac’s Retina)
    • Performance and Memory improvements (with IonMonkey and a huge improvement for people using HTTP proxies)
    • Web standard support: HTML5, JS & CSS new features, with the full support of the W3C Touch events.

    Let’s look at this in more details!

    Some new HiDPI iconsMac users with a Retina displays will be pleased to have an adapted Firefox: support for HiDPI screens has landed and it is gorgeous. Not only the text is using the whole resolution, but all icons have been redone.

    A lot of performance improvements have landed during this cycle:

    • IonMonkey is the codename for the latest JavaScript improvements, and that’s a huge boost in our performance.
    • CSS Gradients use a new caching mechanism that leads to speed gains on page heavily using them.
    • Also work on reactivity led us to lower our start-up times: an unnecessary certificate validation has been removed, but the most significant gains will be seen by people using Firefox behind a proxy, like a lot of business users.
    • Finally, tab switching is quicker as Jared Wein replaced a costly regular expression by more efficient code.

    Memory management continues to get some significant work, though most progress is seen on special cases:

    • We introduced coalescing of inline style rules across nodes, when possible, leading to a significant reduction (up to 20%) of memory on pages with a lot of nodes.
    • Optimizations of our event queues led to less memory used by pages with a lot of HTML and CSS errors (when the console is closed).
    • Also tabs not yet restored are using less memory.

    As expected DThe new preset of the Responsive Design Vieweveloper Tools see steady improvements. Paul Rouget made some nice videos of these features. Of special notice we have:

    • The live preview of the DOM Tree is available.
    • The Responsive design view has now presets and the scroll bars behave more similarly of how they do on mobile phones.
    • On Mac OS, the Scratchpad now supports the native fullscreen feature.
    • New commands, dbg open & dbg close, have been added to our Command line.

    Implementation of CSS3, HTML5 & JavaScript features continues at a quick pace:

    • The W3C Touch events are now implemented on Windows too. That means that our experimental MozTouch event is no more necessary on any platform and should be replaced by the standard way of doing them. We plan to remove support of these deprecated events very soon.
    • The HTML5 reversed attribute of the <ol> element is implemented.
    • The EcmaScript 6 proxies landed.
    • WebWorkers now supports transferable objects.
    • CSS Animations have been adapted to the latest evolution of the CSS cascade.
    • SVG Glyphs can now be integrated into OpenType fonts.

    Like always, this cycle brought its fair share of novelties. And more to come in the future: CSS3 Flexible boxes layout landed and is in Aurora, but the implementation is still experimental and behind a pref, layout.css.flexbox.enable. Not yet ready for prime time, but we are getting close. Similarly WebRTC is available behind a pref, and feedback is welcomed.

    Exciting time ahead for Web developers.

  5. Creating the future of mobile with Firefox OS – resources, docs and more!

    Just under a month ago I wrote a personal post about my thoughts on Firefox OS and why I think there is something ‘magical’ about what it stands for and the possibilities it brings to the table. This post is a follow-up that aims to cover much of the same ground but with extra detail and more of a technical focus.

    What is Firefox OS?

    In short, Firefox OS is about taking the technologies behind the Web, like JavaScript, and using them to produce an entire mobile operating system. It’s effectively a mobile OS powered by JavaScript!

    Firefox OS screenshots

    This is achieved with a custom version of Gecko, the rendering engine in Firefox, that introduces a variety of new JavaScript APIs needed to create a phone-like experience; things like WebSMS to send text messages, and WebTelephony to make phone calls.

    You might be wondering what’s running Gecko, as a phone can’t naturally boot directly into Gecko. To do that, the phone boots into a very lightweight Linux kernel that, in turn, boots the Gecko process. The process is a little more involved than that and much more detail can be found in the B2G Architecture documentation, including how Gecko accesses the radio hardware and other phone-specific functionality.

    The Firefox OS project also aims to combine many of the other projects at Mozilla into a single vision, what we refer to as the Web as the platform. These projects include the Open Web Apps initiative and Persona, our solution to identity and logins on the Web (formally known as BrowserID). It’s the combination of these various technologies that completes Firefox OS.

    If you want to find out more technical information about the OS then definitely check out the Firefox OS pages on MDN.

    Why Firefox OS?

    A couple of common questions that come up are, “Why Firefox OS?” and more specifically, “Why build a mobile OS using JavaScript?” These are incredibly important questions so let’s take a moment to delve into them in a little detail.

    Why build a mobile OS using JavaScript?

    Answering this question can quite simply be boiled down to one sentence; because it’s possible. It’s not the one and only answer but it succinctly handles most of the arguments against JavaScript being used in this way.

    A longer answer is that a JavaScript-powered OS unlocks a whole range of possibilities that aren’t normally or easily available to developers and users with existing operating systems.

    The most obvious of the possibilities is the ability to build applications using the technologies that we already use to build websites; namely JavaScript, CSS, and HTML. While not a truly unique feature of Firefox OS — projects like PhoneGap have done this for years on ‘native’ platforms — it allows developers everywhere to create mobile applications without having to learn native languages and APIs.

    Another draw of JavaScript is that it’s both extremely well documented and free to develop with. Anyone could sit down for a weekend and put together an application without having to pay for a single thing. Obviously that’s not true in the majority of cases, as people tend to buy their own hosting or tooling, but theoretically there is nothing to stop you building with these technologies for free.

    What’s arguably most interesting about JavaScript being used in this way is that it inherently enables physical devices to communicate using the same APIs that we already use on websites. In effect, instead of accessing the Web through a mobile browser the entire phone is now capable of accessing and communicating with any Web API. For example, there is nothing to stop you building an application for Firefox OS that uses WebRTC (once added) to create Skype-like P2P video communication between phones, desktop computers, or anything else that supports WebRTC.

    This really only scrapes the surface of “Why JavaScript?” but it certainly gives you a feel of how this is both interesting and important, beyond the tired debate of ‘native’ vs. Web. If you’re still not convinced, just think for a moment about how you can now customise an entire mobile OS using nothing by JavaScript. You’d be hard pushed to deny that it’s pretty darn interesting!

    OK, but why Firefox OS?

    Effectively, Firefox OS has been built to put our money where our mouth is (so to speak) and prove that JavaScript is capable of doing what we say it can do. However, there is much more to the project than just proving the the technology is fast enough.

    The first reason ‘Why Firefox OS’ is that the mobile ecosystem is overrun with proprietary platforms, most of which prevent you from easily moving between various platforms. What Firefox OS aims to achieve is a truly ‘open’ platform that doesn’t lock you in and inherently makes it as easy and possible to move between devices as and when you choose.

    Mozilla is effectively replicating its success with Firefox, in which it stormed the browser market and showed users that there is an alternative, one that lets them be in control of how they use the Web. In this case, it’s less about browsers and more about mobile platforms and application portability.

    Another reason is that Firefox OS is an attempt to push the Web forward into the world of physical devices. One direct benefit of this is the addition of brand new Web standards and APIs that allow for things like hardware access using JavaScript.

    Plenty of challenges

    It’s fair to say that the Firefox OS journey will contain a number of technical challenges along the way, however that’s part of the fun and the reasons why we’re working on it.

    One of those challenges is how to manage an apps ecosystem that is open and distributed. This is something that we are tackling with the Open Web Apps initiative and the Mozilla Marketplace. It’s a challenge that we are dealing with as things progress and as we learn more about how things work best, as is the nature with new ways of thinking.

    Another of the challenges is making sure that the phone runs as fast as possible, creating the best experience possible. This also relates to questions raised within the developer community around the performance capabilities of JavaScript, particularly when it is used to do things that are perceived to be complex, or when it is compared against ‘native’ technologies. This is a challenge that we are taking very seriously and one which we feel we can overcome. In fact, it’s a challenge that I believe we have already overcome.

    One prime example of how capable JavaScript has become is seeing beautiful JavaScript games running in Firefox OS at near-enough 60 frames per-second, on a low-end, cheap phone.

    Beyond the mobile phone

    While the phone aspect of Firefox OS is immediately interesting, you should consider the wider implications of a JavaScript OS and what possibilities it unlocks. For example, what other devices could benefit from being powered by JavaScript? And, what would a network of JavaScript-powered devices allow us to do — things like Ubiquitous Computing, perhaps?

    These aren’t things that we are exploring directly at Mozilla, but they are things that are now inherently possible as a result of the work that we’re doing. There is nothing to stop you taking the Firefox OS source code from GitHub and porting it to a device that we’ve never even considered.

    We’re already starting to see this happen with examples like a Firefox OS port for the Raspberry Pi, as well as another for the Pandaboard.

    What about a game console powered by Firefox OS? A TV, or set-top box? What about a fridge? Individually, these are all interesting projects, but together they offer something we don’t really have at the moment, a network of different devices powered by the same, open technologies and able to access and communicate across the Web with the same APIs.

    We are a long way away from that kind of world but it is projects like Firefox OS that may pave the way for it to happen. You could even be a part of it!

    Getting started with Firefox OS

    The hope is that by now you’re sufficiently interested in Firefox OS to begin exploring, experimenting and playing with it. The good news is that there are a whole host of ways that you can do that.


    One of the first places to start is the MDN documentation surrounding Firefox OS and its related technologies. This is where you’ll find everything you need to know about the developer-facing aspects of the platform.

    If you’re more interested with the inner-workings of the platform then you’ll want to cast an eye over the B2G wiki, which outlines much of the internals in plenty of detail.

    Source code

    If you’re keen to get to grips with the source code of Firefox OS then you’ll want to head over to GitHub and check it out. The two main repositories that you want are ‘b2g’ (the underlying Gecko engine) and ‘gaia’ (everything you can see, the OS).

    Getting involved

    There are a few ways to get involved with the project. You could check out some of the issues and get involved in fixing them, or perhaps just hang out in the mailing list for B2G, or the one for Gaia, and take part in the discussions there.

    If you just want to ask a few immediate questions then try out the #b2g and #gaia rooms on We’re all pretty friendly!

    Development options

    If you just want to dig in and make some applications, or perhaps customise the OS, then you’ll need to know about the various development options available to you. They are covered in some detail on MDN but here is a brief overview.

    The simplest method to get started is running Gaia (the visual side of Firefox OS) within Firefox Nightly. This doesn’t give you a true representation of a phone environment but it will allow you to install applications and use all of the developer tools within the browser that you’re already used to.

    Slightly more involved than Nightly is using the desktop B2G client. This is effectively a chromeless build of Firefox that looks phone-like has some added APIs that aren’t normally available in standard Firefox. This doesn’t replicate phone hardware but it’s the next best thing before starting to develop on an actual device.

    Setting up the desktop B2G client isn’t too hard, but it could be made easier. In the meantime, projects like r2d2b2g aim to make the process super simple. Definitely worth checking out.

    The last method, and arguably the most important one, is developing on an actual Firefox OS device. This is the only method that will give you a true representation of how your application will perform. It is also the only method that will give you access to the all the new APIs that come with Firefox OS.

    Right now, you’ll need to build and install Firefox OS on one of the supported devices. In the future you will be able to skip this step and get access to devices that already run Firefox OS. We don’t have any dates for that just yet.

    Go forth and be part of something big

    My hope is that by now you should now have enough inspiration and information to go forth and begin building for this new platform, powered by the technologies you already use. We hope you do and we’d love to see what you come up with.

    It’s not every day that you get the opportunity to be a part of something that could quite literally change the way we do things.

  6. r2d2b2g: an experimental prototype Firefox OS test environment

    Developers building apps for Firefox OS should be able to test them without having to deploy them to actual devices. I looked into the state of the art recently and found that the existing desktop test environments, like B2G Desktop, the B2G Emulators, and Firefox’s Responsive Design View, are either difficult to configure or significantly different from Firefox OS on a phone.

    Firefox add-ons provide one of the simplest software installation and update experiences. And B2G Desktop is a lot like a phone. So I decided to experiment with distributing B2G Desktop via an add-on. And the result is r2d2b2g, an experimental prototype test environment for Firefox OS.

    How It Works

    r2d2b2g bundles B2G Desktop with Firefox menu items for accessing that test environment and installing an app into it. With r2d2b2g, starting B2G Desktop is as simple as selecting Tools > B2G Desktop:

    B2G Desktop Menu Item

    To install an app into B2G Desktop, navigate to it in Firefox, then select Tools > Install Page as App:

    Install Page As App Menu Item

    r2d2b2g will install the app and start B2G Desktop so you can see the app the way it’ll appear to Firefox OS users:

    B2G Desktop

    Try It Out!

    Note that r2d2b2g is an experiment, not a product! It is neither stable nor complete, and its features may change or be removed over time. Or we might end the project after learning what we can from it. But if you’re the adventurous sort, and you’d like to provide feedback on this investigation into a potential future product direction, then we’d love to hear from you!

    Install r2d2b2g via these platform-specific XPIs: Mac, Linux (32-bit), or Windows (caveat: the Windows version of B2G Desktop currently crashes on startup due to bug 794662 795484), or fork it on GitHub, and let us know what you think!

  7. First Beta release of Mozilla Persona – Login without Passwords

    For the past year, we’ve been rapidly improving Mozilla Persona (previously BrowserID). Our goal is simple: we want to eliminate passwords on the Web. Today, after many iterations based on community implementation feedback, Persona enters Beta. This first beta means:

    1. we’ve produced and are committing to a much improved API
    2. the first-user experience is significantly improved and streamlined: it’s actually hard to get lost
    3. critical new features, including support for showing your site’s name and logo, as well as terms of service and privacy policy, are live

    Since the beginning, Mozilla Persona was designed to work across browsers. Our commitment to this continues: Persona Beta 1 supports all major mobile, tablet, and desktop browsers. In fact, we’re working to build an extensive library of automated regression tests across all browser platforms to ensure that this support remains rock solid as we continue to add features.

    Persona is not just a great product, it’s also designed with the Mozilla Values in mind. When you deploy Persona on your web site (in an afternoon or, sometimes, only 15 minutes), you’re showing respect for your users and their data. You’re only asking for the data needed to log them in, and users know they’re only sharing exactly what’s shown on the screen.

    The technology behind Persona is interesting in its own right. We’ve built and scaled Mozilla’s first serious node.js-based service. We’ll be writing a few more posts on the specifics of our technology in the weeks and months to come. In the meantime, check out our source code, and join us on email or irc.

    And if you’re building or upgrading a web site, don’t forget to add Persona login support! Our quick setup guide should help you get off the ground in minutes.

  8. It’s Opus, it rocks and now it’s an audio codec standard!

    In a great victory for open standards, the Internet Engineering Task Force (IETF) has just standardized Opus as RFC 6716.

    Opus is the first state of the art, free audio codec to be standardized. We think this will help us achieve wider adoption than prior royalty-free codecs like Speex and Vorbis. This spells the beginning of the end for proprietary formats, and we are now working on doing the same thing for video.

    There was both skepticism and outright opposition to this work when it was first proposed in the IETF over 3 years ago. However, the results have shown that we can create a better codec through collaboration, rather than competition between patented technologies. Open standards benefit both open source organizations and proprietary companies, and we have been successful working together to create one. Opus is the result of a collaboration between many organizations, including the IETF, Mozilla, Microsoft (through Skype), Xiph.Org, Octasic, Broadcom, and Google.

    A highly flexible codec

    Unlike previous audio codecs, which have typically focused on a narrow set of applications (either voice or music, in a narrow range of bitrates, for either real-time or storage applications), Opus is highly flexible. It can adaptively switch among:

    • Bitrates from 6 kb/s to 512 kb/s
    • Voice and music
    • Mono and stereo
    • Narrowband (8 kHz) to Fullband (48 kHz)
    • Frame sizes from 2.5 ms to 60 ms

    Most importantly, it can adapt seamlessly within these operating points. Doing all of this with proprietary codecs would require at least six different codecs. Opus replaces all of them, with better quality.
    Illustration of the quality of different codecs
    The specification is available in RFC 6716, which includes the reference implementation. Up-to-date software releases are also available.

    Some audio standards define a normative encoder, which cannot be improved after it is standardized. Others allow for flexibility in the encoder, but release an intentionally hobbled reference implementation to force you to license their proprietary encoders. For Opus, we chose to allow flexibility for future encoders, but we also made the best one we knew how and released that as the reference implementation, so everyone could use it. We will continue to improve it, and keep releasing those improvements as open source.

    Use cases

    Opus is primarily designed for use in interactive applications on the Internet, including voice over IP (VoIP), teleconferencing, in-game chatting, and even live, distributed music performances. The IETF recently decided with “strong consensus” to adopt Opus as a mandatory-to-implement (MTI) codec for WebRTC, an upcoming standard for real-time communication on the web. Despite the focus on low latency, Opus also excels at streaming and storage applications, beating existing high-delay codecs like Vorbis and HE-AAC. It’s great for internet radio, adaptive streaming, game sound effects, and much more.

    Although Opus is just out, it is already supported in many applications, such as Firefox, GStreamer, FFMpeg, foobar2000, K-Lite Codec Pack, and lavfilters, with upcoming support in VLC, rockbox and Mumble.

    For more information, visit the Opus website.

  9. Full WebRTC support is soon coming to a web browser near you!

    The web is such an integral part of our lives and how we communicate with each other. That’s why we get so excited when we reach evolutionary peaks that take us leaps and bounds forward in offering a better and open game-changing experience for users and web developers alike! We believe WebRTC to be one of those steps.

    What is WebRTC?

    The RTC in WebRTC stands for Real-Time Communications, offered directly on the web without any need for plugins or third-party software. The idea is to be able to share and stream video, audio and data in the most powerful fashion, directly in a web browser, offering media rich exchanges.

    Representatives from Mozilla, Google, Opera and others have been working on WebRTC over a year, and it is on its way to becoming a W3C recommendation.

    The three corner stones in WebRTC are:

    Granting web apps/sites access to the camera and microphone on your computer, via the getUserMedia API.
    Communicating data peer to peer.
    PeerConnection API
    Enabling direct peer to peer connections between two web browsers for audio and video.

    Code simplicity

    If you take a look at our work with WebAPI, you will see examples of a number of simple and intuitive APIs. We believe it’s important for WebRTC to be as easy-to-use by all web developers, not just the rocket scientists among us (nothing wrong with being one, by the way – it’s just that not everyone is. :-))

    To enable this, the web browser handles the real-time media and networking for the web developer, so developers can focus on writing apps that include real-time communication as one of the features. We feel the web itself has in part become an incredibly popular tool for so many developers because it makes it easy to create wonderful things to share with the world.

    We believe WebRTC will become successful for the same reason.

    For example – and you’ve probably already seen this elsewhere – it is very simple to stream the webcam of your computer directly into a web page (with user-granted access, of course):

    	NOTE: This is meant to show a simplified version,
    	without prefixes and such that are currently used 
    	for experimental implementations
    // Get a reference to an existing video element, set to autoplay
    var liveVideo = document.querySelector("#live-video");
    /*  Request access to the webcam
    	Note: in current implementations, this has to 
    	be prefixed, and Google Chrome needs a Blob URL 
    	for the MediaStream
    	{video: true},
    	function (stream) {
    		liveVideo.src = stream;
    	function (error) {
    		console.log("An error occurred: " + error);

    If you want to delve more into the code and APIs right now, then Real-time communication without plugins is a good read.

    Coming to a web browser near you!

    It is important to note that WebRTC has been planned for a long time, and we are now finally reaching a step where cutting edge web browsers – such as Firefox, Google Chrome and Opera – implement their support and bring WebRTC to the web. With Firefox, our plan is to ship full WebRTC support in Firefox 18, in the beginning of January next year.

    Stay tuned, and we’ll keep you up to date on the progress!

  10. Announcing the No JavaScript Challenge (July Dev Derby) winners!

    What can I say? Wow.

    The No JavaScript Challenge was absolutely incredible. It was our most successful Dev Derby yet, and by far. You shared more than seventy amazing demos of what you can do without touching a single line of JavaScript. More than seventy amazing demos of how powerful declarative markup can be. That’s nearly twice the number of demos submitted to our second most popular Derby.

    Dev Derby

    As you can imagine, it is extremely difficult for us to name only a handful of winners. But after looking through the entries, our three new expert judges — David Walsh, Joe Stagner, and (filling in for John Hammink this month) Chris Heilmann — have decided on their top five picks.



    Congratulations to these winners and to all of our contributors for making this our most exciting contest yet. All of these people have done a fantastic job pushing declarative markup forward and deserve lots of praise for doing so. We might even see some of them again next month… here’s hoping!

    Enjoy the No JavaScript challenge? Remember that we have a new contest every month! We are now accepting entries related to Geolocation (September), CSS Media Queries (October), and the Full Screen API (November). Head over to the Dev Derby to get started.