The JavaScript blog.


frameworks firefox tools backbone articles

Web Servers in Firefox OS, Marionette Inspector

Posted on .

Embedding an HTTP Web Server in Firefox OS

Justin D'Arcangelo sent in a detailed article about web servers in Firefox OS: Embedding an HTTP Web Server in Firefox OS.

... we've been looking at harnessing technologies to collectively enable offline P2P connections such as Bluetooth, NFC and WiFi Direct.

By utilizing HTTP, we would already have everything we'd need for apps to send and receive data on the client side, but we would still need a web server running in the browser to enable offline P2P communications. While this type of HTTP server functionality might be best suited as part of a standardized WebAPI to be baked into Gecko, we actually already have everything we need in Firefox OS to implement this in JavaScript today!

The article uses justindarc/fxos-web-server which is a JavaScript web server built with TCPSocket, a raw TCP socket API in JavaScript.

The possible use cases enabled by embedding a web server into Firefox OS apps are nearly limitless. Not only can you serve up web content from your device to a desktop browser, as we just did here, but you can also serve up content from one device to another. That also means that you can use HTTP to send and receive data between apps on the same device! Since its inception, FxOS Web Server has been used as a foundation for several exciting experiments at Mozilla.

So it seems like Firefox OS is getting the kind of advanced features that we've seen appear (and in some cases disappear) in Chrome OS, where you get access to native APIs to create desktop-like experiences.

Marionette Inspector

Jason Laster wrote to me about the Marionette Chrome Extension, known as the Marionette Inspector. There's a video about it, and you can download it from the Chrome web store.

It has some features that are pretty unique, like visualisations for the view hierarchy with the UI tree, and more friendly handling for inspecting Backbone models and events. Rather than seeing a complex JavaScript object, you'll see properties grouped under UI, Events, Model, and Properties.

It makes building apps with Marionette more like using the tools you might expect from an IDE, so you should try it out if you already use Marionette or are a Backbone fan that hasn't yet tried it.


firefox async ES6

Async Harmony Tests

Posted on .

Simeon Velichkov sent in async-harmony tests (GitHub: simov / async-harmony, License: MIT), which contains examples of new ES6 features. Each example is based on methods from async, but written using new features like generators, including arrow functions.

It only currently works in Firefox 29, but I thought the examples were quite interesting:

function eachSeries (items, job, done, kill=true) {  
  var results = [], errors = [];

  var it = iterator();

  function* iterator () {
    for (let item of items) {
      yield job(item, (err, result) => {
        if (kill && err) return done(err);
        if (err) errors.push(err);
        setTimeout(() => it.next(), 0);
    done((errors.length ? errors : null), results);

The corresponding usage looks like this:

async.eachSeries([0,1], (item, done) => {  
  done(new Error('error'+item));
}, (err, result) => {

Give them a read if you're interesting in seeing ES6 in action.


firefox browsers

Multiprocess Firefox

Posted on .

Multiprocess Firefox

I know a lot of DailyJS readers who use Chrome and Safari as their main browsers, partly due to iOS and Android's popularity, and partly because Chrome's initial performance gains enticed them away from Firefox. The big issue over the last few years has been the fact browsers are switching to using multiple processes, the idea being that resources can be shared better and fallout from crashes can be mitigated.

If Firefox isn't your main browser, you probably use it for testing or just try it out every few months to see what's been going on. The thing most of us have been looking for is Chrome (and apparently IE)-style multi-process support. Bill McCloskey has written a post about this very topic: Multiprocess Firefox. Bill is a programmer at Mozilla, and you may remember his post about incremental GC in Firefox.

Although the work so far sounds promising, there are some major technical hurdles. These partly relate to the nature of how JavaScript interacts with the DOM, and how Firefox handles add-ons:

JavaScript execution and layout happen on the main thread, and they block the event loop. Running these components on a separate thread is difficult because they access data, like the DOM, that are not thread-safe. As an alternative, we've considered allowing the event loop to run in the middle of JavaScript execution, but doing so would break a lot of assumptions made by other parts of Firefox (not to mention add-ons).

Like the threaded approach, Firefox is able to run its event loop while JavaScript and layout are running in a content process. But unlike threading, the UI code has no access to content DOM or other content data structures, so there is no need for locking or thread-safety. The downside, of course, is that any code in the Firefox UI process that needs to access content data must do so explicitly through message passing.

You might not realise it, but Firefox itself uses a lot of JavaScript:

Content scripts. IPDL takes care of passing messages in C++, but much of Firefox is actually written in JavaScript. Instead of using IPDL directly, JavaScript code relies on the message manager to communicate between processes.

We decided to do the message passing in JavaScript instead, since it's easier and faster to prototype things there. Rather than change every docshell-using accessor to test if we're using multiprocess browsing, we decided to create a new XBL binding that applies only to remote <browser> elements. It is called remote-browser.xml, and it extends the existing browser.xml binding.

If you're an add-on author, you'll be pleased to hear add-ons are being taken seriously. However, Mozilla may need your help in the future:

We realize that add-ons are extremely important to Firefox users, and we have no intention of abandoning or disrupting add-ons. At the same time, we feel strongly that users will appreciate the security and responsiveness benefits of multiprocess Firefox, so we're willing to work very hard to get add-ons on board. We're very interested in working with add-on developers to ensure that their add-ons work well in multiprocess Firefox.

It's hard to imagine Firefox OS not using multiple processes, and Bill mentions this early on in the post:

Firefox OS relies heavily on the multiprocessing and IPC code introduced during Electrolysis.

Electrolysis was a project to use multiple processes, but the focus was tighter than changing the desktop browser. Firefox's layout engine, Gecko, supports multiple threads, and the "Gecko platform" supports multiple processes. But, as the Electrolysis wiki page points out, the Firefox frontend does not currently use multiple processes.

Will we see a browser share increase when Firefox is updated to support multiple processes? I don't know, but as a front-end developer I'm excited about seeing this feature released sooner rather than later.


firefox firebug addons


Posted on .

FireRainbow is an add-on for Firefox and Firebug that adds themable syntax highlighting. It uses the
JavaScript library CodeMirror
to perform the highlighting, and has CSS themes. You can get the themes
firerainbow/themes on GitHub and paste them into the Colors tab within Firebug.

The performance is good, and it makes Firebug that little bit more
usable and customised.

Another useful Firebug plugin is
Eventbug. I also wrote a post about Eventbug.


firefox html5


Posted on .

Firefox 3.6 has new features from HTML5's File API. This makes it
possible for JavaScript to read the contents of local files. As an
example, that means showing thumbnails prior to uploading files is now

According to the draft HTML5 File
, browsers should provide
the following:

  • A FileList sequence, which represents an array of individually selected files from the underlying system using
  • A Blob interface, which represents raw binary data, and allows access to ranges of bytes
  • A File interface that includes details on file name, type and a URL
  • A FileReader interface, which provides methods to read a file
  • A FileError interface and a FileException exception

There are API docs for FileReader on Mozilla's developer
Mozilla also has a document called Using files from web

with example code for uploading files. Although they mention generating
thumbnails their example doesn't do any image processing -- it's
expected that an implementor would use CSS to create thumbnails to
display before and during the upload process.

Since the File API is asynchronous, files could be loaded and processed
in the background while the user does other things. This could also be
useful for creating web applications that work offline.