Archives For devtools

Crypton Logo

Since I left Mozilla last year, I have been working on Crypton ( ), an HTML5 application framework that places privacy above all else. Last month, my team was invited to the ‘Hack In The Box’, Malaysia security conference to lead a Lab Session on Crypton.

We were required to write a whitepaper for HiTB to publish, which was a great exercise, as my team has been meaning to write a paper for some time. It was a long trip, but worth it. We led a group of engineers through most of the Crypton API in about 2 hours.

I lived-coded the ‘skeleton’ of a messaging application in 74 lines of JavaScript. The coolest thing about this session was using Firefox’s Scratchpad for all of the live-coding. It worked so well, we plan on doing more sessions like this.

Crypton is intended for use inside of mobile and desktop applications (FirefoxOS, too). Our initial target for development is via Cordova and node-webkit. The API hides all of the complexity of cryptography from the developer. Developers use APIs that look like any other hosted API, for instance, account creation looks something like this:

var myAccount; 
crypton.generateAccount('alice', 'password', function callback(error, successResult){
  if (error) { console.error(err); return;}
  myAccount = successResult;

Beneath this elegant, every-day-looking API call, a set of encryption keys are generated for encryption, signing and HMAC as well as a stretched key via the password that wraps all other keys. This keyring is then stored on the server making multiple-device operations easy.

As we move forward with the Crypton framework, we are building a “private backend service” which will make using Crypton trivially easy to use and require no system administration. More on this in a future post.

>Console ideas

2011/02/22 — 2 Comments

>I recently filed bugs 635504 and 635502 in order to make Firefox’s Web Console customizable via the new Addon SDK and to create a global ‘Browser Console’ that lets you peek at all of the activity going on under the hood in Firefox.

The interesting exercise will be cannibalizing the Web Console to create a global console that displays all errors, css parse warnings, network activity and other events. The filtering interface will need even more options to cut through the density of messages. The cool part will be making commands – and perhaps APIs – that give you access to all of the services, observers, browser tabs and other Gecko bits currently running.

Live inspection of these objects will be a powerful tool for those interested in hacking on Firefox, but don’t know how to start.

The first customization of the Web Console we are planning is integration with Rob Campbell’s ‘Workspace’. I would like to see a console and workspace either side-by-side or be able to toggle between them, with the current console automatically providing a logging API.

I find the Workspace is already an essential tool when I start hacking something together – especially in the  ‘chrome’ context. The Workspace can save your snippets to files, so any commonly used tools and functions can be used as templates.

If you think of anything that would automate or make easier repeated tasks or techniques you use when hacking web apps or Firefox, let me know.

>Wow, it is August already…


Many feedback reviews again this week, mainly on Console UI.
Landed patch for bug 579954 – “sometimes gBrowser cannot be accessed”


Working on bug 568629 “Small footprint, efficient global console service” with jst – we are making a console api that can be attached to all windows as needed, lazily. This is a component that will broadcast all console.log/info/warn/error calls to WebConsole, Firebug, etc…


Would like to know if recent e10s landings like bug 569227 will get activated in Firefox 4 betas at some point.
Still need to get some coordination on bug 567165 – would be great if this bug, or some semblance of this bug blocked a beta.

All in all, the UI is looking great thanks to Patrick Walton, and Julian and  Mihai are producing patches at an alarming rate. The integration of Firefox and Labs DevTools teams is exciting. Still a lot of work to do.


>Firefox 4.0 Beta 1 includes some new web developer tools, “Console” and “Inspector”.

This post will cover the Console, what it does now and the direction we  are headed with it. The developer tools team would like feedback from  web developers and others who might use these tools, so please try it out and either comment in Bugzilla, through one of our feedback tools (such as ) or in the comments of this blog.

The Meta Bug for this Console work has a list of blocking bugs, for those who are interested.


What is the “Console”?

The console displays log messages, warnings and errors that originate in web pages. The current Error Console in Firefox displays messages that originate in any open web page, Firefox itself and the underlying Gecko platform code. One of the main changes we wanted to make with the new Console was to pre-filter all of the messages so you are  only seeing messages that originate in the current browser tab. You can activate the Console though Tools menu -> Heads Up Display. (The “Heads Up Display” name will be changing soon to something like “Console”).

The existing Error Console is displayed in it’s own window, the new Console is initiated per browser tab, and is displayed (by default) as a panel that drops down over the corresponding tab’s web page. You can open the console for each tab if you want to. Each will funnel console messages about that document to the correct console.

The existing Error Console:

The new Console:

Now that we are tying the log messages directly to each tab, there is a lot higher signal to noise. This is, of course, a work in progress. There are a couple of bugs that need to be fixed before all of the messages are properly identified as being from a particular tab: bug 568034 and bug 567165.

Another goal is a rich, interactive (command line) interface that allows quick introspection of JS Objects you might be interested in.  You can execute functions, write code directly into the console command line and the output displays the result of the executed commands. We want the command line to be a very powerful tool for users to quickly find out the state of variables and the effects of function execution.
There are several bugs on tab-completion, JS object inspection and helper functions, which are under heavy development right now and should be available in upcoming betas.

Tab completion in the command line interface will allow you to easily introspect the properties of various JS and DOM objects.

Helper functions in the command line will allow developers to have a “$” function regardless of whether a “$” function is already defined. If defined, nothing happens and the developer can use her existing function. If not,  we provide a “$” that does document.querySelectAll, among other things.

The console work is just getting started. The recent addition of some additional engineers means we will be iterating quickly, so please check it out and give feedback often. You may want to use a nightly build for bleeding edge features. I will post additional “branch” builds to this blog as they are available.

Read more about this beta release on the Official Mozilla Blog

>Today, the web console code attached to bug 534398 landed on mozilla-central. This means that starting with tomorrow’s  nightly, you will have a new “Heads Up Display” console to tinker with:

If you are interested, the Meta bug is here

There are a number of followup bugs that need to be addressed, the list is here:

Console Bugs

There is a lot of work to do yet, including some platform work. Two glaring bugs are:

“When reporting errors, warnings, etc… to the consoleService, report the originating window or context

The existing errorConsole in Firefox has messages sent to it that do not know what tab the error originated in. We really want to isolate all messages you see to the tab you care about as a web developer. It becomes tedious to try and watch the scrolling messages at times if a “noisy” page is loaded in one of your 200 open tabs. So you will notice that not all errors are displayed in the console.


“create event or method to determine the source contentWindow of loading images and media”

In Firefox, images are loaded differently than script, css and html pages, so much so, that it is difficult to trace these image loads back to the originating tab as well.

Once these two bugs are fixed, your console messages will be very accurately focused to the tab you care about.

The console itself has the standard API: console.log,, console.warn and console.error.

This initial landing into Minefield nightly will hopefully generate some valuable feedback from web developers and Mozilla developers alike. Please do not hesitate to comment here or even better in bugzilla.



>As part of the “Developer Tools” we are working on for Firefox 4, the console is coming along nicely. The latest “try builds” are here for Linux, Windows and MacOS:

Windows and Mac Builds

Linux build

The UI has not been worked on at all at this point. There are several bugs on mock ups and implementation. The current UI was implemented by me, an engineer, so you will be underwhelmed.

There are several broken features like image urls not logging properly and not all exceptions and CSS errors are logged to the tab’s console.

Here is the list of currently open bugs:

Here is a screen shot:

Feel free to download it and take it for a test run, file bugs. This is still at an early point, but feedback is valuable, so don’t hesitate to comment here or in Bugzilla.

>Much more work on bug 534398 – Found some issues with correlating network traffic with correct HeadsUpDisplay, mostly network traffic where the request is an ImgRequest. I have been getting advice from bz and dougt. This means that the console does not log any network traffic where an image or favicon is loaded.
Also, have an issue where nsIConsoleMessages cannot be correlated with the correct (or any) HeadsUpDisplay. This will need some Platform work, see bug 567165
I have most of the filtering working, there are some bugs with the “binary” on/off filters and I am almost there with the string filter. I should have those sewn up on Monday, and a patch for review by Tuesday midday.


Nail down filtering, ask for review, (any takers?), fix all tests and write a few new ones.
New try build and a blog post.


Platform attention on bug 567165. It would be great to be able to get the “contentWindow ID” in each content JS and CSS consoleMessage. That would make message isolation (to a tab) “easy”.

>My work was interrupted last week by this handsome young man’s birth:

I left off with a review request on the code in hand for bug 534398. Started work on the “global console” data and “placeholder” output UI. I tried using a separate window, but it was a bit disjointed.

Also got some work done on the “global console” storage and various listeners. needs work, but approach is visible.


Add a JSTerm “input” element to the regular console with output directed to the regular console. Fix exception listener so all global messages are written to the “global console”


I was going to try and parallelize the reviews for this work, but, after speaking with Rob Strong about the review process on EM rewrite, he recommended that the review this console work should be comprehensive from a single reviewer. Mossop agrees as well. I have asked vlad for review – until he begins review I will be doing some more test writing and cleanup.

Update: Latest try Build:

>Still plugging away on bug 534398 “Heads Up Display – console”:

Implemented DOM Mutation logging as well as more concise network logging.

Removed all programmatic CSS and started using the css service.

Tweaked the UI to make it more “usable” while under such heavy development.

Implemented a ConsoleStorage module to keep all logging data, as well as make it easily iterable. This is mainly for the “global console”

More work on “JSTerm” or “Javascript Workspaces”




Everything is up to date in the repo:


Need to make each logged message “updatable” by asynchronous but related log messages.

Also need to add an exception listener that can log to the corresponding tab’s “Display”.
Should be straight forward.

Add preferences for turning on and off functionality, etc.

Slowly breaking things out into smaller, stand-alone and tested modules or additional services (maybe) – to make review easier.


Need to get feedback and start reviews on the various bits: HUDService, HeadsUpDisplay module, storage module, JSTerm module.

Update: Latest Try Builds are here:

> Closed bug 545266 and bug 546708 – toolkit and browser “scaffolding”

Heads Up Display, console (bug 534398): I have gotten a try-server build to work. It is not pretty, but it works. You can call console.log(“I am a log message”); from content and it works. The API follows Firebug: console.log, console.warn, console.error,

I am re-factoring things right now to move most functionality into toolkit as well as isolating things out of a jsm and into 2 components.
Setup a user repo at:


Pretty current try build is here:

Url to test try build is here:


More refactoring, hoping to ask for a review on monday from Mr. Mossop.