Articles by Robert Nyman [Editor]

Sort by:


  1. The Gamepad API

    I’ve been fascinated by video games since I was a kid. From the Atari and Colecovision to the NES and Super NES, I’ve spent countless hours playing a variety of games. While my own video game playing has tapered off, I’m still interested in the issues and advancements surrounding gaming. I’ve watched the recent popularity explosion of web gaming and am positive that it’s going to herald a new era of gaming, with a tremendous number of games available to a wide audience. However, one thing struck me while exploring the burgeoning web gaming scene–many of these games would be a lot more fun to play with a gamepad! I set out to remedy that by implementing something for Firefox and thus the Gamepad API was born.

    A collection of game controllers

    Enabling the API

    As of Firefox 24, the Gamepad API is available behind a preference. You can enable it by loading about:config and setting the dom.gamepad.enabled preference to true. Nightly and Aurora builds of Firefox have the API enabled by default. We expect to ship release builds with it similarly enabled in Firefox 28.

    Using the API

    The Gamepad API was designed to be very simple. The spec intentionally only attempts to describe an interface for working with traditional Gamepad controllers—a collection of buttons and axes. We felt that this covers the majority of the gaming controllers that are out there, while avoiding the complexity of trying to specify an API that covers everything in existence. The API consists of one function call, a few DOM events, and one type of object to work with.

    Getting a Gamepad

    As implemented, gamepads will not be exposed to a webpage unless the user interacts with them while the page is visible. This is for privacy reasons, mostly to prevent them from being used in fingerprinting a user’s system. If the user interacts with (presses a button, moves a stick) a controller while the page is visible a gamepadconnected event will be sent to the page.

    The GamepadEvent object has a gamepad property that describes the device in question. In Firefox, once one gamepad has been exposed to a page, connecting any other gamepad to the system (by plugging in a USB gamepad or associating a Bluetooth gamepad) will immediately expose that device to the page and send a gamepadconnected event.

    The Gamepad API also provides a function–navigator.getGamepads()–that returns a list of all devices currently visible to the webpage. Each gamepad visible to the page is returned at the position in the list specified by its index property.

    Note: this code snippet will work in Firefox 28 nightly builds but not in older builds due to a bug that was just recently fixed.

    If a gamepad is disconnected–by being unplugged, for example–a gamepaddisconnected event is fired at the page. Any lingering references to the Gamepad object will have their connected property set to false.

    The Gamepad object

    The Gamepad object represents the state of a game controller. It has several properties that describe the controller:

    A string containing some information about the controller. This is not strictly specified, but in Firefox it will contain three pieces of information separated by dashes (-): two 4-digit hexadecimal strings containing the USB vendor and product id of the controller, and the name of the controller as provided by the driver. This information is intended to allow you to find a mapping for the controls on the device as well as display useful feedback to the user.
    An integer that is unique for each device currently connected to the system. This can be used to distinguish multiple controllers.
    A boolean: true if the controller is still connected, false if it has been disconnected.
    A string indicating whether the browser has remapped the controls on the device to a known layout. Currently there is only one supported known layout–the “standard gamepad“. If the browser is able to map controls on the device to that layout the mapping property will be set to the string standard.
    An array of floating point values containing the state of each axis on the device. Usually these represent analog sticks, with a pair of axes giving the position of the stick in its X and Y axes. Each axis is normalized to the range of -1.0..1.0, with -1.0 representing the up or left-most position of the axis, and 1.0 representing the down or right-most position of the axis.
    An array of GamepadButton objects containing the state of each button on the device. Each GamepadButton has a pressed and a value property. The pressed property is a boolean indicating whether the button is currently pressed (true) or unpressed (false). The value property is a floating point value used to enable representing analog buttons, such as the triggers on many modern gamepads. The values are normalized to the range 0.0..1.0, with 0.0 representing a button that is not pressed, and 1.0 representing a button that is fully pressed.

    Cross-browser compatibility

    The Gamepad API specification is implemented in both Firefox and Chrome, to varying degrees of compatibility. Currently Firefox implements the entirety of the editor’s draft with the exception of the timestamp property on Gamepad objects.

    As of this writing, Chrome does not implement the ongamepadconnected or ongamepaddisconnected events. You must use the navigator.webkitGetGamepads() function (note the prefix) to access gamepads.

    Another difference to note is that Gamepad objects are snapshots in Chrome, whereas they always reflect the latest state of the controller in Firefox. This means that for Chrome you will need to poll the set of gamepads with navigator.webkitGetGamepads() each frame, whereas in Firefox you can hold a reference to a Gamepad object in a variable and refer to it later to check the current state.

    Finally, a recent spec change means Chrome and release versions of Firefox have a difference from Firefox 28—the buttons property of the Gamepad object was originally specified as an array of doubles, not an array of GamepadButton objects. This can be handled safely with a simple type check, as the following code sample shows.

    A simple demo

    I’ll leave you with a simple demo that puts all the pieces here together and shows how you can use the API today in a cross-browser fashion. It simply looks for gamepads being connected or disconnected and displays the current state of the buttons and axes of all known controllers. This demo should work in any version of Firefox from 24 onwards and in Chrome from version 21 onwards. You can find the source of the demo on Github.

    I hope this post inspires you to rethink what is possible in gaming on the web. Let’s go make some games!

    A screenshot showing the Gamepad test page

  2. Split console, pretty-print minified JS and more – Firefox Developer Tools Episode 28

    Just in time for the holidays, the Firefox Developer Tools teams has some excellent new surprises for you to enjoy as you hack on holiday projects! It’s a pretty long list, so let’s get started.

    App Manager

    The App Manager continues to be a priority for the Devtools team and with Firefox 28, in addition to many minor fixes and improvements the team has added two new major features to assist in mobile development. These two features consist of an additional manifest editor and an embedded toolbox.

    The Manifest Editor allows a developer to edit their app manifest directly. Using this editor you can add, edit, or delete fields in your app’s manifest.webapp and save them back to disk. This feature provides the developer an integrated experience, as the user never has to leave the tools while debugging and improving an application.

    Also new to the App Manager is the embedded toolbox. Now when you debug your app (either using the Simulator or on device) the toolbox will be opened in the App Manager in a separate vertical ‘tab’ that is easily distinguished by the app’s icon:

    Web Console

    The biggest change in the Web Console is a feature we call ‘split console’; the web console can now be summoned from any other tool. Using split console mode is easy – if you’re working with any other tool and need access to the console, simply hit the Escape key or click on the button to toggle the split console, as you can see in this short screencast:

    This isn’t the only improvement to the console though. In addition to split console we’ve also made the following changes:

    • CSS warnings are off by default – CSS warnings can often add hundreds of messages to the console as a page loads.
    • The console will now offer autocomplete suggestions for the current scope the debugger is in.
    • Message timestamps can be toggled on/off (the default is off)
    • console.exception() and console.assert() have been added to the console api.
    • We added a dark theme for the console


    In the debugger we’ve added two key features that developers have been asking for. First off we’ve added the ability to pretty-print minified JS files:

    This feature is particularly handy if you minify your JavaScript or need to step through a minified library served from a remote site – just click on the minification button (picture above) to get a much more nicely formatted version of the file.

    In addition to this we’ve added a feature to the debugger that allows you to inspect the value of a variable while debugging. For any variable, simply hover over it or click on it to bring up a pop-up that displays the current value:

    The pop-up allows you to inspect not only simple types like the boolean picture above, but also objects and DOM nodes:


    Following along from the addition of various tooltips to the Inspector in Firefox 27, we’ve added some additional features in the inspector:

    • A Color picker tooltip in the rule view
    • We updated style the style of tooltips to better match the dark and light themes
    • The display timeout for tooltips was tuned based on your feedback

    Here’s a screenshot to give you an idea what the color-picker tooltip looks like:

    Wrapping up

    That’s a huge list, but there were a couple of additional changes I’d like to call out as well:

    • The Network Monitor now has a clear button, which should be of particular use to developers creating apps that make heavy use of web APIs:

    • As a bonus for Add-on or Platform hackers, we’ve expanded the functionality of the Browser Debugger and re-named it the Browser Toolbox. When you open the toolbox you’ll see a full range of tools including not only the debugger but also the Console, Inspector, Style Editor, Profiler, Network Monitor and Scratchpad:
  3. Ember Inspector on a Firefox near you

    … or Cross-Browser Add-ons for Fun or Profit

    Browser add-ons are clearly an important web browser feature, at least on the desktop platform, and for a long time Firefox was the browser add-on authors’ preferred target. When Google launched Chrome, this trend on the desktop browsers domain was pretty clear, so their browser provides an add-on api as well.

    Most of the Web DevTools we are used to are now directly integrated into our browser, but they were add-ons not so long time ago, and it’s not strange that new web developer tools are born as add-ons.

    Web DevTools (integrated or add-ons) can motivate web developers to change their browser, and then web developers can push web users to change theirs. So, long story short, it would be interesting and useful to create cross-browser add-ons, especially web devtools add-ons (e.g. to preserve the web neutrality).

    With this goal in mind, I chose Ember Inspector as the target for my cross-browser devtool add-ons experiment, based on the following reasons:

    • It belongs to an emerging and interesting web devtools family (web framework devtools)
    • It’s a pretty complex / real world Chrome extension
    • It’s mostly written in the same web framework by its own community
    • Even if it is a Chrome extension, it’s a webapp built from the app sources using grunt
    • Its JavaScript code is organized into modules and Chrome-specific code is mostly isolated in just a couple of those
    • Plan & Run Porting Effort

      Looking into the ember-extension git repository, we see that the add-on is built from its sources using grunt:

      Ember Extension: chrome grunt build process

      The extension communicates between the developer tools panel, the page and the main extension code via message passing:

      Ember Extension: High Level View

      Using this knowledge, planning the port to Firefox was surprisingly easy:

      • Create new Firefox add-on specific code (register a devtool panel, control the inspected tab)
      • Polyfill the communication channel between the ember_debug module (that is injected into the inspected tab) and the devtool ember app (that is running in the devtools panel)
      • Polyfill the missing non-standard inspect function, which open the DOM Inspector on a DOM Element selected by a defined Ember View id
      • Minor tweaks (isolate remaining Chrome and Firefox specific code, fix CSS -webkit prefixed rules)

      In my opinion this port was particularly pleasant to plan thanks to two main design choices:

      • Modular JavaScript sources which helps to keep browser specific code encapsulated into replaceable modules
      • Devtool panel and code injected into the target tab collaborate exchanging simple JSON messages and the protocol (defined by this add-on) is totally browser agnostic

      Most of the JavaScript modules which compose this extension were already browser independent, so the first step was to bootstrap a simple Firefox Add-on and register a new devtool panel.

      Create a new panel into the DevTools is really simple, and there’s some useful docs about the topic in the Tools/DevToolsAPI page (work in progress).

      Register / unregister devtool panel


      Devtool panel definition


      Then, moving to the second step, adapt the code used to create the message channels between the devtool panel and injected code running in the target tab, using content scripts and the low level content worker from the Mozilla Add-on SDK, which are well documented on the official guide and API reference:

      EmberInspector - Workers, Content Scripts and Adapters

      DevTool Panel Workers


      Inject ember_debug


      Finally hook browser specific code needed to activate the DOM Inspector on a defined DOM Element:

      Inspect DOM element request handler


      Evaluate its features and dive into the exchanged messages

      At this point one could wonder: how much useful is a tool like this?, Do I really need it? etc.

      I must admit that I’ve started and completed this port without being an experienced EmberJS developer, but to be able to check if all the original features were working correctly on Firefox and to really understand how this browser add-on helps EmberJS developers during app development/debugging phases (its most important use cases), I’ve started to experiment with EmberJS and I have to say that EmberJS is a very pleasant framework to work with and Ember Inspector is a really important tool to put into our tool belts.

      I’m pretty sure that every medium or large sized JavaScript framework need this kind of DevTool; clearly it will never be an integrated one, because it’s framework-specific and we will get used to this new family of DevTool Add-ons from now on.

      List Ember View, Model Components and Routes

      The first use case is being able to immediately visualize Routes, Views/Components, Models and Controllers our EmberJS app instantiate for us, without too much webconsole acrobatics.

      So its immediately available (and evident) when we open its panel on an EmberJS Apps active in the current browser tab:

      Ember Inspector - ViewTree

      Using these tables we can then inspect all the properties (even computed ones) defined by us or inherited from the ember classes in the actual object hierarchy.

      Using an approach very similar to the Mozilla Remote Debugging Protocol from the integrated DevTools infrastructure (e.g. even when we use devtools locally, they exchange JSON messages over a pipe), the ember_debug component injected into the target tab sends the info it needs about the instantiated EmberJS objects to the devtool panel component, each identified by internally generated reference IDs (similar to the grips concept from the Mozilla Remote Debugging Protocol.

      Ember Extension - JSON messages

      Logging the exchanged messages, we can learn more about the protocol.

      Receive updates about EmberJS view tree info (EmberDebug -> DevtoolPanel):

      Request inspect object (DevtoolPanel -> EmberDebug):

      Receive updates about the requested Object info (DevtoolPanel -> EmberDebug):

      Reach every EmberJS object in the hierarchy from the webconsole

      A less evident but really useful feature is “sendToConsole”, to be able to reach any object/property that we can inspect from the webconsole, from the tables described above.

      When we click the >$E link, which is accessible in the right split panel:

      Ember Inspector - sendToConsole

      The ember devtool panel asks to ember_debug to put the defined object/property into a variable accessible globally in the target tab and named $E, then we can switch to the webconsole and interact with it freely:

      Ember Inspector - sendToConsole

      Request send object to console (DevtoolPanel -> EmberDebug):

      Much more

      These are only some of the feature already present in the Ember Inspector and more features are coming in its upcoming versions (e.g. log and inspect Ember Promises).

      If you already use EmberJS or if you are thinking about trying it, I suggest you to give Ember Inspector a try (on both Firefox or Chrome, if you prefer), it will turn inspecting your EmberJS webapp into a fast and easy task.

      Integrate XPI building into the grunt-based build process

      The last challenge in the road to a Firefox add-on fully integrated into the ember-extension build workflow was xpi building for an add-on based on the Mozilla Add-on SDK integrated into the grunt build process:

      Chrome crx extensions are simply ZIP files, as are Firefox XPI add-ons, but Firefox add-ons based on the Mozilla Add-on SDK needs to be built using the cfx tool from the Add-on SDK package.

      If we want more cross-browser add-ons, we have to help developers to build cross-browser extensions using the same approach used by ember-extension: a webapp built using grunt which will run into a browser add-on (which provides glue code specific to the various browsers supported).

      So I decided to move the grunt plugin that I’ve put together to integrate Add-on SDK common and custom tasks (e.g. download a defined Add-on SDK release, build an XPI, run cfx with custom parameters) into a separate project (and npm package), because it could help to make this task simpler and less annoying.

      Ember Extension: Firefox and Chrome Add-ons grunt build

      Build and run Ember Inspector Firefox Add-on using grunt:

      Following are some interesting fragments from grunt-mozilla-addon-sdk integration into ember-extension (which are briefly documented in the grunt-mozilla-addon-sdk repo README):

      Integrate grunt plugin into npm dependencies: package.json

      Define and use grunt shortcut tasks: Gruntfile.js

      Configure grunt-mozilla-addon-sdk tasks options


      Especially thanks to the help from the EmberJS/EmberInspector community and its maintainers, Ember Inspector Firefox add-on is officially merged and integrated in the automated build process, so now we can use it on Firefox and Chrome to inspect our EmberJS apps!


      Latest Build

      In this article we’ve briefly dissected an interesting pattern to develop cross-browser devtools add-ons, and introduced a grunt plugin that simplifies integration of Add-on SDK tools into projects built using grunt:

      Thanks to the same web first approach Mozilla is pushing in the Apps domain creating cross-browser add-ons is definitely simpler than what we thought, and we all win :-)

      Happy Cross-Browser Extending,

  4. Application Layout with CSS3 Flexible Box Module

    It has become very easy to create fluid application layouts thanks to the CSS3 Flexible Box Layout Module. In this article we are going to implement a simple application layout, which fills the whole screen, resizes with the browser window and comes with the additional bonus of a draggable splitter.

    Instead of the classic <div> elements let’s also use some HTML5 structural tags. This will not only make the code more semantic, but also more convenient to work with, since we can directly address the elements with a CSS type selector without having to rely on id attributes or parent-child relationships.

    Take a look at the complete demo to see how it works.

    First step: Add Vertical Boxes

    We start with only three tags (<header>, <main> and <footer>) in the body.

    <!DOCTYPE html>
        <title>CSS3 Application Layout</title>

    Let’s add the CSS to make these three elements fill the space vertically. This is achieved by setting the CSS display property of the <body> to flex and the flex-direction property to column. This tells the browser to lay out the body’s children (<header>, <main> and <footer>) as vertical flexible boxes.

    How this available space is distributed can be controlled with the flex shorthand property. You can read about it on MDN. In this application layout though, we don’t want the size to shrink or expand proportionally. Instead the <header> and the <footer> element should have a fixed height, whereas the <main> should just fill the remaining space by setting its flex property to auto.

    html, body {
        height: 100%;
        width: 100%;
        padding: 0;
        margin: 0;
    body {
        display: flex;
        flex-direction: column;
    header {
        height: 75px;
    main {
        flex: auto;
    footer {
        height: 25px;

    Show demo

    Second Step: Horizontal Boxes

    Let’s add three more elements (<nav>, <article> and <aside>) inside the <main> element. But this time we want them to fill the space inside the <main> element horizontally instead of vertically.


    This is achieved by setting the display property of the <main> element also to flex, but the flex-direction property to row (this is the default). The <nav> and <aside> element should have a fixed width, while the <article> should just fill the remaining space: this is achieved in the same kind of manner as before:

    main {
        display: flex;
        flex-direction: row;
        flex: auto;
    nav {
        width: 150px;
    article {
        flex: auto;
    aside {
        width: 50px;

    Show demo

    Thats all. Resize your browser window and enjoy the flexible application layout.

    Next step: CSS Refinements

    But wait. When there is a lot of content, an element can become smaller than specified and also scrollbars can appear.

    Therefore, we need to add a min-width property to all elements where we added a width property. We also should set the overflow property of the <body> and the <main> element to hidden as well as the overflow-y of <article> and <aside> to auto to only show scrollbars where we want them.

    body {
    	overflow: hidden;
    	display: flex;
    	flex-direction: column;
    header {
    	height: 75px;
    	min-height: 75px;
    footer {
    	height: 25px;
    	min-height: 25px;
    main {
    	display: flex;
    	flex-direction: row;
    	flex: auto;
    	border: solid grey;
    	border-width: 1px 0;
    	overflow: hidden;
    nav {
    	width: 150px;
    	min-width: 150px;
    article {
    	border: solid grey;
    	border-width: 0 0 0 1px;
    	flex: auto;
    	overflow-x: hidden;
    	overflow-y: auto;
    aside {
    	width: 50px;
    	min-width: 50px;
    	overflow-x: hidden;
    	overflow-y: auto;

    Note: This does probably not work in Safari yet. You might be able to get it to work by using the -webkit- prefix.

    Final Step: Throw a little JavaScript into the Mix

    As the final step, we want the user to be able to resize the <aside> element when dragging it with the mouse. For that we add a <div> element as a splitter, which will serve as the drag handle.

        <div class="splitter"></div>

    We set the width of the handle to 4px and give the cursor attribute a value of col-resize, to show the user that this element can be resized East-West.

    .splitter {
        border-left: 1px solid grey;
        width: 4px;
        min-width: 4px;
        cursor: col-resize;

    All what’s left now is to add a little JavaScript, that enables moving the splitter.

    var w = window, d = document, splitter;
    splitter = {
        lastX: 0,
        leftEl: null,
        rightEl: null,
        init: function(handler, leftEl, rightEl) {
            var self = this;
            this.leftEl = leftEl;
            this.rightEl = rightEl;
            handler.addEventListener('mousedown', function(evt) {
                evt.preventDefault();    /* prevent text selection */
                self.lastX = evt.clientX;
                w.addEventListener('mousemove', self.drag);
                w.addEventListener('mouseup', self.endDrag);
        drag: function(evt) {
            var wL, wR, wDiff = evt.clientX - splitter.lastX;
            wL = d.defaultView.getComputedStyle(splitter.leftEl, '').getPropertyValue('width');
            wR = d.defaultView.getComputedStyle(splitter.rightEl, '').getPropertyValue('width');
            wL = parseInt(wL, 10) + wDiff;
            wR = parseInt(wR, 10) - wDiff;
   = wL + 'px';
   = wR + 'px';
            splitter.lastX = evt.clientX;
        endDrag: function() {
            w.removeEventListener('mousemove', splitter.drag);
            w.removeEventListener('mouseup', splitter.endDrag);
    splitter.init(d.getElementsByClassName('splitter')[0], d.getElementsByTagName('article')[0], d.getElementsByTagName('aside')[0]);

    Note: For some reason the resizing doesn’t work in IE11 (, Safari?) or Chrome 31. It seems that it has something to do with the display: flex; property value.

  5. Monster Madness – creating games on the web with Emscripten

    When our engineering teams at Trendy Entertainment & Nom Nom Games decided on the strategy of developing one of our new Unreal Engine 3 games — Monster Madness Online — as a cross-platform title, we knew that a frictionless multiplayer web browser version would be central to this experience. The big question, however, was determining what essential technologies to utilize in order to bring our game onto the web. As a C++ oriented developer, we determined quickly that rewriting the game engine from the ground-up was out of the question. We’d need a solution that would allow us to port our existing code in an efficient manner into a format usable in the browser…

    TL;DR? Watch the video!

    Playing the Field

    We looked hard at the various options in front of us: FlasCC (a GCC Flash compiler), Google’s NaCl, a custom native C++ extension, or Mozilla’s Emscripten & asm.js.

    In our tests, Flash ran slowly and had inconsistent behaviors between Pepper (Chrome) and Adobe’s plugin version. Combined with the increasingly onerous plugin requirement, we opted to look elsewhere for a more seamless, forward-thinking approach.

    NaCl had the issue of requiring a walled-garden distribution site that would separate us from direct contact with our users, and also being processor-specific. pNaCL eliminated the walled-garden requirement and added dynamic code compilation support, but still had the issues of being processor-specific code necessitating in our view device-specific testing, and a potentially long startup time as the code would be linked on first run. Finally, only working in Chrome would be a dealbreaker for our desire to have our game run in all major browsers.

    A custom plugin/extension with C++ would require lots of testing & maintenance efforts on our part to run across different browsers, processor architectures, and operating systems, and such an installation requirement would likely scare away many potential players.

    As it turned out, for our team’s purposes the Emscripten compiler & asm.js proved to be the best solution to these challenges, and when combined with a set of other new-ish Web API’s, enabled the browser to become a fully featured platform for instant high-end 3D gaming. This just took a little trial & error to figure out exactly how we’d piece it together…and that’s what we’ll be reviewing here!

    First Steps into a Brave New World

    We Trendy game engineers are primarily old-school C++ programmers, so it was something of a revelation that Emscripten could compile our existing application (built on Epic Game’s Unreal Engine 3) into asm.js optimized Javascript with little to no changes.

    The primary Unreal Engine 3-specific code tweaks that were necessary to get the project to compile & run with Emscripten, were essentially… 1, 2, 3:

    // Esmcripten needs 4 byte alignment
    FNameEntry* Allocate( INT Size )
        #if EMSCRIPTEN
           Size = Align( Size, 4 );
    // Script execution: llvm needs aligned data
        #define XFER(T)
            T Temp;
            if (!Ar.IsLoading())
                appMemcpy(&Temp, &Script(iCode), sizeof(T));
            Ar << Temp;
            if (!Ar.IsSaving())
                appMemcpy(&Script(iCode), &Temp, sizeof(T));
            iCode += sizeof(T);
        #define XFER(T) { Ar << *(T*)&Script(iCode); iCode += sizeof(T); }
    // This function needs to synchronously complete IO requests for single-threaded Emscripten IO to work, so added a ServiceRequestsSynchronously() to the end of it which flushes & blocks till the IO request finishes.

    No really, that was about it! Within a day of fiddling with it, we had our game’s Javascript ‘executable’ compiled & running in the browser. Crashing, due to not having a graphics API implememented — but running with log output! Thankfully, we already had Unreal Engine3’s OpenGL ES2 version of the rendering subsystem ready to utilize, so porting the renderer to WebGL only took another day.

    WebGL appeared to essentially have a superset of features compared to OpenGL ES2, so the shaders and methods used matched up by simply changing some API calls. In fact, we were able to do improvements by making use of WebGL’s floating point render targets for certain postprocessing effects, such as edge outlining and dynamic shadows.

    Postprocessing makes everything prettier!

    But how’s it run?

    Now we had something rendering in the browser, and with a quick change to capture input, we could start playing the game and analyzing its performance. What we found was very encouraging: straight ‘out of the box’, in Firefox the asm.js version of the game was getting nearly 33% of the performance of the native executable. And this was comparing a single-threaded web application to the multi-threaded native executable (so really, not a fair comparison! ;). This was about 2x the performance we saw with our quick Flash port (which we still utilize as a fallback for older browsers that don’t yet support asm.js, though we eventually hope to deprecate entirely).

    Its performance in Chrome was less astonishing, more towards 20% of native performance, but still within our target margins: namely, can it run on a 2011-model Macbook Air at 45-60 FPS (with Vsync disabled)? The answer, thankfully, was yes. We hope Google will continue to improve the performance of asm.js on their browser over time. But as it currently stands, we believe unless you’re making the browser version of ‘Crysis’ with this tech (which may not be far off), it seems you have enough performance even in Chrome to do most kinds of web games.

    60 FPS on an old Macbook Air

    Putting the Pieces into Place

    So within a week from starting, we had turned our Unreal Engine 3 PC game into a well-running, graphically-rich web game. But where to take it from here? Well, it’d still need: Audio, Networking, Streaming, and Storage. Let’s discuss the various techniques used for each of these systems.


    This was a no-brainer, as there is only really one robust standardized web audio system apart from Flash: WebAudio. Again, this API matched up pretty well to its mobile cousin, OpenSL, for which we already had an integration. So once we switched out the various calls, we had .

    There was an apparent issue in Mac Chrome where sounds flagged “looping” would sometimes never become destroyed, so we implemented a Chrome-specific hack to manually loop the sound, and filed a bug report with Google. Ah well, one thing we’ve seen with browser API’s is there’s not a 100% guarantee that every browser will implement the functionality to perfect specification, but it gets the job done!


    This proved a little trickier. First, we investigated WebRTC as used in the Bananabread demo, but WebRTC of course is for browser-to-browser communication which is actually not what we were looking to do. Our online game service uses a server-and-client architecture with centralized infrastructure, and so WebSockets is the API to utilize in that case. The tricky part is that we have to handle all the WebSockets incoming and outgoing data in JavaScript buffers, and then pass that along to the “C++” Emscripten-compiled game.

    With some callbacks, this worked out, but we also had to take our UDP game server code and place the WebSockets TCP-style layer onto it — some iteration was necessary to get the packets to be formatted in exactly the way that WebSockets expects, but once we did that, our browser game was communicating with our backend-hosted Linux dedicated game servers with no problems!

    Streaming & Storage

    One advantage to being on the web is easy access to the browser’s asynchronous downloading functionalities to stream-in content. We certainly made use of this with our game, with the initial download clocking in at under 10 MB. Everything else streams in on-demand as you play using standard browser http download requests: Textures, Sound Effects, Music, even Skeletal Meshes and Level Packages. But the bigger question is how to reliably store this content. We don’t want to just rely on the browser cache, since it’s not good for guaranteed immediate gameplay loading as we can’t pre-query whether something exists on disk in the regular browser cache or not.

    For this, we used the IndexedDB API, which lets us asynchronously save and retrieve data objects from a secure abstracted storage location. It works in both Chrome and Firefox, though it’s still finicky as the database can occasionally become corrupted (perhaps if terminated during async writes) and has to be regenerated. In the worst case, this simply results in a re-download of content the user already had received.

    We’re currently looking into this issue, but that aside, IndexedDB certainly works well and has the advantage of providing our application standard file IO functionality, useful to store content that we download. (UPDATE: Firefox Nightly build as of 12/10 seems to automatically reset the IndexedDB storage if this happens and it may not recur.)

    Play it Now, and Embrace the Future!

    While we still have more profiling and tweaking to, as we’re just now starting to use Firefox’s VTune support to symbolically profile the asm.js performance within the browser. Even still, we’re pretty pleased with where the things currently stand. But don’t take our word for it, please try it yourselves right here, no installation or sign-up required:

    Try our demo test anonymously In-browser Here!
    (Please bear with us if our game servers limit access under load, we’re still testing our backend scalability!)

    We at Trendy envision a day when anybody can play any game no matter where they are or what device they happen to have, without friction or gateways or middlemen. With the right combination of these cutting-edge web technologies, that day can be today. We hope other enterprising game developers will join us in reaching players directly through the web, which thanks to Emscripten & asm.js, may well become the most powerful and far-reaching “game console” of all!

  6. The Side Projects of Mozillians: JSFiddle and

    At Mozilla, we are happy to get the chance to work with a lot of talented people. Therefore, as an on-going series, we wanted to take the opportunity to highlight some of the exciting projects Mozillians work on in their spare time.


    JSFiddle is a tool to write web examples (in HTML, JavaScript and CSS) called ‘fiddles’. They can be saved and shared with others or embedded in a website which is perfect for blogs, documentation or tutorials. Created by Piotr Zalewa.


    Piotr: I wanted a tool that could help me check if my frontend code was working. I was active on the MooTools scene at the time and we needed a tool to support our users who had questions about the framework and specific bugs to solve. The community is the best motivation. There are about 2,000 developers creating and watching fiddles right now! Many big projects are using JSFiddle for docs (MooTools, HighCharts) or bug requests (jQuery).

    I’m always logged in on the #mootools IRC channel and one day we had a small competition to see who could be the first to answer support questions with only one line of JavaScript code. A user asked a non-trivial question which needed to be answered with both HTML and JavaScript. Our usual workflow was to write an HTML file, run it locally in the browser, copy the code to a Pastebin site then share the link. No one knew of a tool that could do this. The next day I had a prototype created in the evening and it was well accepted. The working but ugly version was completed shortly after. Oskar Krawczyk joined as a designer and the project was ready to be shown to the world.

    It started as Django and MySQL on the server side with MooTools as a frontend framework. Since then the only major change was adding Memcache. Currently we run JSFiddle on 12 servers sponsored by DigitalOcean. 2 database servers, 3 application servers, 2 Memcache, then static files and development servers. I would ideally like to have the database structured in a way that would be easier to scale. The database is huge and updating tables takes a lot of time.

    JSFiddle was designed in the time when most of the JavaScript libraries were running under one framework only. We want to allow users to mix frameworks and add more languages. At the moment you can write in HTML, JavaScript, Coffeescript, CSS and SCSS but I would like to support more languages. We’ve got a full hat of ideas to be implemented but I think it’s better to provide improvements than promises. is a single public channel chat app that generates animated GIFs of users from their camera once they submit a new message. Created by Jen Fong with GIF library support added by Sole Penadés.

    Jen: I’ve been working on various quirky chat apps that involved some form of embedded media so this was an idea I had about getting users to interact beyond typing by posing for the camera and doing a little movement. I also really like GIFs and the fact that they work everywhere. I had been playing with WebRTC here and there and Sole was working on her RTCamera app when I thought: “Could we combine the two worlds? Chat and GIFs?”.

    For the web server I used Nginx which proxies to a long running Node process using Express. The messages and GIFs are stored temporarily in LevelDB with a TTL (time-to-live) that deletes the message, including the GIFs stored as Base64 blobs, after 10 minutes. On the client-side, it uses jQuery, some GIF library files and updates with WebSockets with an AJAX fallback.

    The biggest challenge of the project was surprisingly not code related! It was largely keeping up with all the craziness when a flood of people started using the chat, tweeting at me and contacting me. I first mentioned it publicly at ‘RealTimeConf’ in Portland a few weeks prior then started tweeting about it. After that a bunch of people checked it out, and someone posted it on Hacker News where even more people came (around 8,000 people on the heaviest day). It was mentioned on Twitter and various sources for a few days after.

    People can be really creative during their GIF creation. It was also interesting to watch people give each other humorous ‘-bro’ nicknames; both women and men. They would always ask others what their name should be rather than giving themselves a name.

    I am now working on a similar app but for one to many GIF chatting for Firefox OS called chatspaces. Anyone who is interested in contributing can watch the repository and check the README for what to contribute.

  7. The Mozilla Developer Network has a New Face

    Last summer the Mozilla Developer Network (MDN) underwent a massive platform change, moving from a hosted third-party solution to our own custom Django application code-named Kuma. That move laid the ground work for our latest major MDN upgrade: a complete front-end redesign, included many new features as well as usability and accessibility enhancements. Let me provide you with a quick overview of what you can expect to see on the new MDN and what features we’re cooking up for the future!

    New MDN Features

    Increased Commitment to Search

    The majority of MDN users are looking to find documentation the moment they land on the MDN homepage, so we’ve placed search front and center:

    We’ve also added search filters to the mix, allowing users to narrow down search results to their specific needs:

    From a technical perspective, we’ve moved to Elasticsearch for search, allowing us to continue making indexing and filtering improvements, as well as add new search features at will. We anticipate fine-tuning search as we receive feedback so we’ll continue the push to get you to better documentation faster.

    Ease in Navigation

    Getting from document to document was a pain point in the previous design, so we’ve fixed that in two ways. The first was creating Content Zones, a method for creating navigation for a given topic. We’ve started with the most prominent parts of MDN, including App Center, Firefox, Firefox OS, Firefox Marketplace, Add-ons, and Persona:

    Content Zones

    MDN’s new Content Zones provide a complete collection of documentation about a given topic, encompassing the very basics of a topic to API details and advanced techniques. We’ll be kicking off with the following zones:

    Firefox OS

    Highlights of the Firefox OS zone include:

    • A detailed Platform Guide
    • Build and Install details
    • Hacking Firefox OS
    • App Design & Development
    Firefox Marketplace

    Highlights of this zone include:

    • App submission and review
    • App publishing and monetization
    • Marketplace API information
    App Center

    Highlights of the App Center zone include:

    • Quickstart Guide
    • Design and Build tips
    • App publishing guidelines
    • API references

    Highlights of the Persona zone include:

    • Guide to using Persona on your site
    • Becoming an identify provider
    • Details on the Persona project

    Highlights of the Firefox zone include:

    • A complete Firefox Add-on overview
    • Information on Firefox internals
    • Detailed instructions for building Firefox and contributing

    Highlights of the Add-ons zone include:

    • XUL extension information
    • Best practice tips
    • Theming
    • Add-on publishing guidelines

    “See Also” Links

    We’ve also implemented “See Also” links which may appear in any wiki page, linking to documents which may be relevant based on the document you’re currently viewing.

    Both the zone subnavigation and “See Also” link sidebar widgets are built from basic link lists in the wiki document, so adding links and shuffling navigation is easy for anyone looking to contribute to MDN. These link lists can also be built using MDN’s macro language, Kumascript, and our writing team has done a great job automating “See Also” links so that contributors can save on the manual labor of hunting down other relevant documents.

    Top level navigation

    In the top level navigation, you will have access to five distinct areas:

    • The above-mentioned Content Zones
    • Web Platform, including direct links to more information on technologies, references and guides
    • Developer Program – To be able to help developers and establish long-term relationships and channels, we have created the Mozilla Developer Program. We have a lot of plans and ideas for iteratively expanding the Program, and we want you involved as we do so! So, sign up! You will get a membership, be able to subscribe to our newsletter and get access to features over time as we roll them out.
    • Tools – more information on the Firefox Developer Tools and their features
    • Demos, being a direct link to the Demo Studio

    Enhanced Kumascript Macro Features

    Kumascript, MDN’s dynamic macro language, was also outfitted with the ability to read external RSS feeds. At present MDN is using the feed reader capability to pull forum posts from StackOverflow and blog posts from the Mozilla Hacks blog. Check out the MDN:Common macro to view the fetchJSONResource and fetchHTTPResource methods which aid in displaying feed content in wiki documents.

    Future Features

    This visual redesign is just the beginning of our push to make MDN more dynamic and usable. The MDN development and UX teams have plenty more coming in 2014. Here are a few peeks into what you can expect to see!

    Dynamic Search Filtering

    To improve the efficiency in user search, we plan to implement hashtag-prefixed text filtering which may be added in the initial search — doing so will prevent the need for additional filtering when the user lands on the search results page.

    Holly Habstritt Gaal has detailed this query system in detail on her blog. Check out her blog post to see implementation details.

    Docs Navigator

    So you’ve completed a search and you click the first link you thought would be applicable, but you want to move onward and view other results. Instead of backing out to the search results page again, the wiki page (if the user came from search) will display a doc navigator to move to the next or previous result, or you can view the entire list of results from your original search:


    Just another handy way of finding what you need faster!

    Demo Studio and Dev Derby Redesign

    A redesign to the MDN Demo Studio and Dev Derby will be coming shortly. We have an excellent design in review and we hope to roll that out in early 2014.

    If you have a suggestion or find any bugs within the new MDN, please let us know.

    Look forward to more from MDN in 2014 and beyond. The MDN platform promises to expand and improve the way we view, write, and experience documentation and web technologies!

  8. Holiday gaming competition with Mozilla and Goo Technologies

    The web has come a long way, and especially lately it is amazing what great opportunities this means for game creators. To use open technologies to reach as many users as possible across multiple web browsers and platforms.

    Looking at what WebGL, Web Audio API, Emscripten, asm.js and more have brought to the table, and what we’ve covered in articles here on Mozilla Hacks about gaming, WebGL, Audio etc, we are very excited to see the progress for gaming on the web.

    Thinking about all this, we wanted to find an interesting way to encourage you to see what kind of games you could create! Together with Goo Technologies, we’re bringing you Goo’s Game Creator Challenge.

    You will be using the Goo platform to create your games, which consists of:

    • Goo Engine – a 3D JavaScript gaming engine entirely built on WebGL/HTML5
    • Goo Create – a visual editing tool running on top of the engine


    There are three different categories you can enter in:

    • Best Amateur Interactive Game Scene – Create a visually stunning interactive game scene using only the built in object primitives (simple 3D shapes, such as cubes, spheres, and so forth, that can be manipulated and combined together to create characters or other objects in a scene). This category is for those with little to no previous experience of game creation.
    • Best Desktop Game – Create an immersive game level for the desktop browser using Goo Create in combination with the Goo Engine JavaScript API.
    • Best Mobile Game – Create an immersive game level for the mobile Web using Goo Create in combination with Goo Engine JavaScript API – extra credit will be awarded for cross-platform games that also work on desktop.

    Getting started

    If you need inspiration to get started, a good place to start is Build an interactive scene in Goo Create or look at the Creating a Goon in Goo Create video:

    Other good resources are:

    Also, if you need help, you can go to the forums for Goo Technologies.


    As with any challenge, there are prizes! For the people entering the Best Amateur Interactive Game Scene category, the top 5 contributions will win:

    • $1,000 in cash
    • 5 year access to Goo Create Pro ($2900 value)

    For the Best Desktop Game and Best Mobile Game categories, the prizes are:

    • A trip for two people to the GDC Conference in San Francisco, scheduled for March 17 – 21, 2014 or to GamesCom in Cologne, August 13-17 (maximum value $10,000) or $5,000 cash, at the winner’s option.
    • 5 year access to Goo Create Pro ($2900 value)
    • Guest post on the Mozilla Apps blog


    Judging the challenge are people from Rovio (know for Angry Birds and more), Mozilla (Brendan Eich, CTO and inventor of JavaScript, Vlad Vukicevic, Engineering Director and inventor of WebGL) and Goo Technologies (Rikard Herlitz, CTO). They will pick the winners by January 17th.

    Deadline for entry

    Deadline for submitting entries is Tuesday, January 14 at midnight PT. Submit your entry by sending the url of your finished scene or game to

    For more information:

  9. How the Manana app was built

    We saw Firefox OS as a great opportunity and a challenge to deliver a product true to the values of open web and best standards. We found it exciting to be able to deliver an app that will offer a smooth UX even for people using lower end devices. As many of the users have a very limited data plan we decided that a proper reading app offering the possibility to enjoy their favourite articles offline and without unnecessary distractions would be a key product. And so we decided to build Manana.

    Here is the story of how we did it.

    On a technological side, we decided to go vanilla but with a little help from ZeptoJS to handle the DOM manipulation. We also integrated Web Activities to hook into the sharing options in the browser, and to share the selected links via email. We are using also the Readability API to have a nice formatted version of the link. The app is simple and that’s how we wanted it to be. but we have a great plus: it is internationalized in English, Spanish, Portuguese, Polish, German, Italian. Hungarian and Greek are coming soon.

    You can install Manana from the Firefox Marketplace.

    Building the layout and managing transitions between the views

    To provide a branded UI/UX, we use a small framework built in-house. With some clever CSS properties and a few lines of JavaScript (to handle the visibility of the Views) the whole thing was quite easy to set up. Basically, we have each View arranged like cards in a deck. Every time we need one of them, we pull it out while the old one goes in the deck again (becoming hidden). When the animation is ended, we capture the animationend event, so right after that we remove the class that brings the animation properties and at the same time we add a current class, which lets the card stay in place and be visible. The old one is hidden automatically since that’s its default state.

    Below you will find a small example of how it works with a moveRight animation.

    Showing the way Views move

    Optimize CSS3 transitions

    Every smartphone comes with at least a small GPU, so that the CPU doesn’t have to do all the graphical calculations. It’s very much in fashion to take advantage of the Hardware Acceleration and so we do. There are some CSS3 properties that are automatically handled by the GPU, but others are not – usually the ones that are related to 3D. This is because the element (tied to the animated property) is promoted to a new layer that doesn’t suffer from repaints imposed by other properties (like left, for example. But this can change in the future).

    tl;dr Where you can, avoid expensive CPU work, especially on big or complicated elements. Here is a small extract of how we implemented such properties.

    /* moveLeftIn directive */
    .moveLeftIn {
        animation: 0.5s moveLeftIn cubic-bezier() forwards; /* 1 */
        backface-visibility: hidden; /* 2 */
        transform: translateY(0) translateX(99%); /* 3 */
        /* 1. `forwards` let the animation stop at the last keyframe */
        /* 2. avoid some possible glitches caused by 3D rendering */
        /* 3. take advantage of the GPU with 3D-related properties */
    /* moveLeftIn animation */
    @keyframes moveLeftIn {
        0%   { transform: translateY(0) translateX(99%); z-index: 999; }
        100% { transform: translateY(0) translateX(0);   z-index: 999; }

    Hooking to the Firefox OS specific Web Activities

    One of our favourite APIs of the WebAPIs, is Web Activities. An application emits an Activity (for example, save bookmark) then the user is prompted to chose among other applications that handles that activity. At the moment it is possible to register an application as an activity handler through the app manifest (declaration registration), but in the future this could be done inside the app itself (dynamic registration).

    Saving a link from the browser to Manana is an example of Web Activity (save-bookmark). Registering an activity is trivial:


    "activities": {
        "save-bookmark": {
          "disposition": "inline",
            "returnValue": true

    returnValue is of great importance, otherwise the handler application (Manana in our case) will never return to the caller (Browser). The handling in the app is also very easy:

    navigator.mozSetMessageHandler("activity", function(activity) {
        ... check if activity is savebookmark
        var data =;
        ... do stuff with activity data

    The applications included in your phone are part of Gaia, the UI of Firefox OS, and you can actually browse the source. They provide a lot of examples on how to use WebAPIs. If you are interested in the save-bookmark activity, have a look at the Homescreen app source code.

    Manana users can also share their resources via email, directly from the app. To achieve that, we’ve implemented the email Web Activity. It’s easy to pre-populate the email subject and body, just follow the mailto URI scheme and you are done.

    DB.Get(id, function (rs) {
        var subject       = rs.title,
            body          = rs.url,
            shareActivity = new MozActivity({
                name: "new",
                data: {
                    type: "mail",
                    url : "mailto:?body=" + encodeURIComponent(body) +
                          "&subject=" + encodeURIComponent(subject)

    Retrieving and storing data with IndexedDB

    IndexedDB is a client side NoSQL DB. It has some nice features which make it easier working with app updates and is easy to integrate in your app, even if you’re using a framework like AngularJS. Setting up models is fairly easy and extensively documented on the web and in Gaia Apps.

    You don’t have a quota limit, although the Firefox OS Simulator seems to have a limit when dealing with datasets larger than 5mb. Each database is tied to an app and a version. Only one version can run at a time, which makes it easier not to break compatibility, especially if you rely on some external API.

    Since it is asynchronous, dealing with IndexedDB operations requires having callback. Below is an example on how we deal with the action of adding a link:

    1. Call Link.Add function, passing a link object and a success callback
    2. Link.Add get a DB connection by calling getDB
      • In the case a DB does not exist, the onupgradeneeded callback is executed
        • Create DB
        • Create collections
        • Create indexes
      • getDB check if the connection is already open, otherwise it opens a new one
    3. Link.Add fills the missing property of links with default values
    4. We call the objectStore put method to save/update new data into the collection
      • If the Link object we are going to save already contains a primary key attribute, IndexedDB does an update
      • Otherwise, an insert
    5. If the put method is successful it calls a success callback, returning the primary key in

    Below is an example of DB action defined in our models: (for the sake of brevity we omitted error checking code)

    Add: function(data, onsuccess) {
        getDB(function(db) {
                var transaction = db.transaction(["links"], "readwrite"),
                    objectStore = transaction.objectStore("links"),
                    request = objectStore.put(data);
                request.onsucces = function(e) {
                    onsuccess( // is the id of the new Link

    This is how you call it from the other part of the app:

    var newLink = {url: "",
                   title: "Welcome to zombo com"};
    Link.Add(newLink, function(linkId) {
        window.location.hash = "#/read/:" + linkId;

    Enhance localization with Markdown support

    Localization is a key feature in our app. Manana currently supports 6 languages (soon it will be 8). There is no official recommendation, but after some research we decided to use the same technique that Gaia is using. This is a great feature of working with Firefox OS: the whole source code is there, and you can get inspiration by reading it.

    L10n has been used in two different cases: to translate the text content of DOM elements and to translate internal help pages. To make the Localization process as simple as possible, we avoided putting HTML tags in the strings and in the internal help pages; we used markdown instead. By design, we avoided having strings in the Javascript code, all messages and alerts are contained in the HTML.

    To support markdown we added some glue between the l10n.js library and marked.js.

    To load the help resources, Manana first does a lookup in the current installation to find the file named <resourceName>.<locale>.md. If the lookup fails, the fallback is the English version of the resource. Once the file is retrieved succesfully, the content is applied to the marked function to generate the HTML, and then added to the DOM.

    function resourceInit($oldView, $newView, resource) {
        var fallback  = "/locales/resources/" + resource + "",
            localized = "/locales/resources/" + resource + "." + getLanguage() + ".md",
            renderMd  = function (txt) {
                $(".js-subpage", $newView).html(marked(txt));
            renderError  = function (txt) {
                $(".js-subpage", $newView).text("ouch, cannot find: " + resource);
                function () { getFile(fallback, renderMd, renderError); });

    A note on retrieving local files with a XMLHttpRequest

    Retrieving files asynchronously from your local app is as easy as doing a XMLHttpRequest, but there is a case that took us some time to sort out. If the local file you are retrieving is missing, the request won’t fire the success callback (of course), but neither the error callback. It will just hang there forever.

    After some research, we noticed a try { ... } catch block in the l10n.js library. Basically, “in Firefox OS with the app:// protocol, trying to XHR a non-existing URL will raise an exception.”

    function getFile (url, success, error) {
        var xhr = new XMLHttpRequest();
    "get", url, true);
        xhr.setRequestHeader("Content-Type", "text/plain;charset=UTF-8");
        xhr.onreadystatechange = function() {
            if (xhr.readyState == 4) {
                if (xhr.status == 200 || xhr.status === 0)
                    error && error();
        xhr.onerror = error;
        xhr.ontimeout = error;
        // Here it is!
        try {
        } catch (e) {
            error && error();

    Keeping the UI synchronized with the Database

    One of the most challenging aspect of an HTML app is synchronization of state between a data source (db, file, api, etc) and the UI. Frameworks like Backbone and Angular make your life easier but they are not easy beasts to tame. Going vanilla is fun, mostly because JavaScript gives you a lot of flexibility when deciding how to do things.

    We really like OO programming by message passing, so we came up with a message based architecture. The body element acts as our global dispatcher while view root element is the local dispatcher. Global events get registered when the application starts and live as long as the app. Local events get registered when entering a view and live until we leave that view.

    An example of global events are the CRUD operations we want to perform on our model.

    Each action on the UI which changes the state of models is tied to a global event, registered on document.body. On entering a new view, we call a constructor function, which executes some initialization code.

    var events = {
            // global events are never unbinded
            global: {
                "save-link": function() { ... },
                "remove-link": function() { ... },
                "update-link-collecetion": function { ... },
            // view specific events are unbinded everytime we leave that view
            home: {
                "update-link-collection-complete": function(e) {
                    var $caller = e.detail.$caller;
    function homeInit($oldView, $newView, dispatch) {
            // $oldView is the previous view
            // $newView is the current view
            // dispatch in an helper which wrap 
            // document.body.dispatchEvent(new CustomEvent(...))

    Leaving a view calls a destructor on that view, and unbinds all the local events. At the end of the day we can open the app source code without spending hours trying to figure out how things work because of framework related black magic.

    Integration with git

    When it comes to Git, our hearts melt. We love git. Seriously. Git and Vim are the best pieces of software ever written. Love.

    Ok, lets get serious again.

    Our application is composed from two components, the app itself and an API Server. The API server is a Golang API proxy to Readability API. So our app directory layout looks like this:

     |- srv/
     |- app/ is a simple bash script which perform three simple tasks:

    • Install a post-{commit, merge, rebase} hook, if not already installed
    • Update app/js/revision.js writing the current git revision hash.
    • Create a clean zip containing the app, ready for the app store or your device.

    This makes our lives easier.

    Conclusion. What Next?

    Manana relies on the Readability API to get the stripped down version of the web page. Readability is doing a really good job, but we’d like to experiment with other solutions, like parsing the page directly in the device. It’s a hard job, but it’d be cool to do it on the client side, and some work has already been done.

    We had a great time developing for Firefox OS. The most important thing for us, techwise, is that we developed a webapp, not an OS-specific app. We can use all the know-how we gained in the past years, all the great open source libraries we want, and we can even use the browser debug tools we use every day.

    To help newcomers in building a Firefox OS app, we have created a list of resources we found indispensable.

  10. Firefox and FireCAT as a Platform for Ethical Hacking

    Some years ago – in early 2007, while working as freelancers – we were challenged to do a penetration test on a web application. It was really simple but had a condition-based methodology, and therefore was impossible to use any automated tool; we could only use a web browser.

    Our solution was to convert Firefox into a Platform for Ethical Hacking.

    How did we do it?

    We searched the Web, looking for a solution that satisfied the requirements and obligations to not use automated tools. We found many, a lot of them being add-ons and extensions. Many of them were unknown, unnoticed and unofficial.

    Having compiled some useful findings, our next challenge was to create something that maintained the essence of Mozilla Firefox: open, free and easy for everyone. The project was named FireCAT (Firefox Catalog of Auditing exTensions)

    What is FireCAT?

    FireCAT is a mind map organized into different categories and subcategories with a variety of add-ons available. These are themed around application security auditing and assessment, adding news functionality, customizing your browser and providing the ability to adapt it to different user’s need.

    Current Status

    The latest version is 2.0, and was presented at Black Hat Arsenal during 2011. From the web site it is possible to list the content and browse the categories, directly accessing the add-ons on Mozilla Add-ons; you can also download the entire mind map with the categories:

    What’s New?

    • Current Version: 2.0
    • Add-ons: > 90
    • Categories: 7
    • Subcategories: 19

    FireCAT v2.0 – Firefox Catalog of Auditing exTensions

    • Information Gathering
      • Whois
      • Location Info
      • Enumeration & Fingerprint
      • Data Mining
      • Googling & Spidering
    • Proxies & Web Utilities
    • Editors
    • Network Utilities
      • Intrusion Detection System
      • Sniffers
      • Wireless
      • Passwords
      • Protocols & Applications
    • Misc
      • Tweaks & Hacks
      • Encryption / Hashing
      • Antivirus & Malware Scanner
      • Anti Spoof
      • Anti-phishing / Pharming / Jacking
      • Automation
      • Logs / History
      • Backup & Synchronization
      • Protection
    • IT Security Related
    • Application Auditing

    What can we find in the categories?

    The 7 main categories are as follows:

    Information Gathering

    An important part of the process of conducting vulnerability assessment or penetration testing is related to obtaining information in a passive or active way about our objective, to be analyzed later.

    From the Firefox platform, we could identify IP addresses, query DNS, verify HTTP headers, generate reports of domains via Whois, use different search engines, and identify applications and versions from Web Server, modules, etc.


    “Show IP” shows the IP address(es) of the current page in the status bar. It also allows querying of custom services by IP (right mouse button) and hostname (left mouse button), like whois, netcraft, etc.

    Proxies & Web Utilities

    Sometimes it’s necessary to use proxies to connect with different hosts or through networks for exaple using TOR to hide our real IP, analyze time responses, detect load balancer, etc.


    The User Agent Switcher extension adds a menu and a toolbar button to switch the user agent of the browser:


    From the ubiquitous FireBug to different JavaScript or XML editors, the available editors can help us to visualize and modify content as required.


    The JavaScript Deobfuscator will show you what JavaScript gets to run on a web page, even if it is obfuscated and generated on the fly.

    Network Utilities

    In this section you can use and connect with applications and services such as FTP, DNS and databases in real time.


    This section contains a lot of useful add-ons, for example tools to convert your ASCII into md5, sha1, base64, hex, etc., and methods to identify the WOT (Web of Trust) in a web site, guage reputation and ratings, modify your HTTP Referer, automate actions through Macros, and make backups of your configuration and installed addons.


    The Certificate Patrol add-on reveals when certificates are updated, so you can ensure it was a legitimate change.

    IT Security Related

    Sometimes it is necessary to use search engines to find information within some Web sites, content related to errors, configurations, and news vulnerabilities by CVE.

    Application Auditing

    The HackBar is probably the best known addon in this group, but I recommend you take a deeper look because many of them are useful. For example, Exploit-Me’s suite to perform vulnerability analysis of cross-site scripting and SQL Injection.


    The SQLite Manager allows you to manage any SQLite database on your computer.

    Recommended add-ons

    The top ten recommended add-ons would be:

    Final Words

    I invite you to explore the different add-ons and extensions available, identifying which ones are most interesting and helpful for your work, and their relative performance and compatibilities. Firefox was a great help during our work!

    If you decide to install a large amount of add-ons, memory usage might be a problem: consider this carefully.

    Feel free to send us your comments and recommendations for new options to add to the mind map!