fidzu : Mozilla

My friend kaie made a very nice and explanative talk at fosdem on the subject. It's now available for reading in pdf at http://kuix.de/fosdem2012/fosdem-2012-talk-kaie.pdf

06 Feb 2012 12:26pm GMT

Getting Started

For this post, please welcome guest blogger and SDK developer Matteo Ferretti who has been hard at work porting the SDK to work with the new native version of Mobile Firefox.

Add-on SDK version 1.5 is due to be released on February 21st, and we're pleased to announce that this version will introduce initial support for creating addons for the new native version of Firefox Mobile (codename "fennec").
Mobile support is still experimental and is currently focused on addons using the SDK's page-mod module to alter and interact with web pages.

If you're interested in trying this support out now, you can do so by checking out the 'master' branch of the addon-sdk repository:

git clone git://github.com/mozilla/addon-sdk.git

Alternatively you can just download a zip archive of the current master:

https://github.com/mozilla/addon-sdk/zipball/master

Developing an add-on for Firefox Mobile with the Add-on SDK is very similar to the desktop. If you're not familiar with Add-on SDK development process, you can take a look here. It helps but is not mandatory for this tutorial.

Getting set up

In addition to having the correct version of the SDK, there are some additional requirements:

• you need to have an Android device connected to your computer via USB
• on the Android device, you need to install a Nightly build of Firefox Mobile.
• you need to download and install the Android SDK, including the SDK Tools. Specifically, the SDK requires that you have installed the 'adb' command-line tool.

Please see this detailed tutorial by Aaron Train for more information on installing and configuring the Android SDK.

Now you're ready to write the classic "Hello World" example!

Hello, Fennec!

Firstly, be sure that you have connected your device to your computer. You can check it running from a shell the following command:

adb devices

Then, be sure that you don't have any Firefox Mobile already running. That is important because the Add-on SDK will run your add-on using a temporary firefox profile for development, not the default one. If Firefox is already running, you can quit Firefox by opening the application menu, selecting 'More', then selecting 'Quit'.
Don't worry, if Firefox is running the Add-on SDK will clearly warn you.

Now open a shell, navigate to the Add-on SDK root directory, and execute:

source bin/activate

This will activate the SDK's environment and allow you to run the cfx tool from the current shell prompt nomatter what directory you are currently in..

Change to another directory and then create a directory called hellofennec. Keeping your add-on code outside the SDK is good practice. Navigate to that directory and run cfx init to create a new addon:

mkdir hellofennec
cd hellofennec
cfx init

With a text editor or IDE of your choice, open lib/main.js, and replace its contents with the following:

console.log("Hello, Fennec!");

Save it. You're ready to run it on your device using the following command:

cfx run -a fennec-on-device -b ~/path/to/adb --mobile-app fennec --force-mobile

And yes, compared to the desktop version the mobile version needs more arguments. You can learn about all the cfx's arguments just run it without any parameters, but let's have a quick look about what they means in this context:

• -a, -app : specify the application that runs the add-on, in this case "fennec on device".

• -b, -binary : is mandatory for fennec-on-device app. SDK needs to know where you have installed the adb tool that is installed with the Android SDK in order to communicate with your device. So, replace this value with the right path where you have installed the adb platform tool.

• -mobile-app : is the name of the Android intent. If you have only one Firefox Mobile version installed on your device, you can omit this option. The value for nightly is fennec, for aurora this is fennec_aurora, for beta this is firefox_beta and for release this is firefox.
  If you have a Fennec's custom build on your device, the intent's name is fennec_<your_username> by default.

• -force-mobile : this flag will be removed when the mobile's support will be stable and not experimental anymore.

When you execute the command the first time you'll see a message like this:

No 'id' in package.json: creating a new ID for you.
package.json modified: please re-run 'cfx run'

Run the command again, and it will run Firefox Mobile on your device with your add-on installed.

Congratulations! You have made your first step in mobile add-ons development with Add-on SDK!

Hack the web

As I said previously, Add-on SDK provide a minimal support for mobile at the moment, focused mainly on page-mod. In short, they are add-ons that can modify any - or a specific - web pages loaded by the browser.

On mobile this is very handy. For instance, you can optimize a website that it wasn't designed for mobile devices, improve the readability, or adding unique functionality.

For this tutorial I made a simple add-on that "mod" the famous penny-arcade.com website. You can check it out from github:

git clone git://github.com/ZER0/penny-arcade-comics.git

Alternatively, you can download it as zip archive.

What it does is simple: when you're on the penny-arcade.com homepage or reading a news post, switching from portrait to landscape will display the webcomics related to that news, without clicking a link and zooming (landscape fits more the format of penny-arcade comics than portrait, and portrait is more suitable to reading news). Switching back from landscape to portrait will hide it again.

A deeper look

So, how it works? The important files are data/content.css, data/content.js and main.js. The first two are the files injected into penny-arcade.com, and the last one is our add-on entry point.
Let's start with main.js.
Firstly, we require the Add-on SDK modules needed:

var PageMod = require("page-mod").PageMod;
var data = require("self").data;

The PageMod object allows us to create a page-mod; and data object provides an access to the data directory's files.

PageMod({
  // page-mod will added only on the homepage and news page of penny-arcade.com,
  // with or without www as prefix.
  include: /^http:\/\/(www\.)?penny-arcade.com(\/|\/\d{4})?.*/,
  contentScriptFile: data.url("content.js"),
  contentScriptWhen: "ready",
  onAttach: function (worker) {
    worker.port.emit("init", data.url("content.css"));
  }
});

For the main.js, that's all. The addon will load content.js into the page when the DOM is ready for any URL that matches the include property's regular expression. When the page-mod is "attached" to a document, the onAttach callback will emit a custom init event to the content script, passing the URL of content.css.

So, what happens on the other side when the init event is emitted? Let's see content.js:

self.port.on("init", function init(cssURL) {
  // We're not interested in frames
  if (window.frameElement) return;
  addStyleSheet(cssURL);
  var comicsPageURL = document.querySelector(".btnComic").href;
  var http = new XMLHttpRequest();
  http.open("GET", comicsPageURL, true);
  http.onload = addComics;
  http.send();
});

A page-mod is attached to every page that matches the include rule, so frames as well. We are not interested in frames, only in the main page, so with:

if (window.frameElement) return;

We avoid to execute code in that specific case.

Then, we add the stylesheet given using addStyleSheet function, defined in the same file, and we obtain the comics page URL by looking into the DOM.
Because the comic page and the news page are in the same domain, we can use XMLHttpRequest from the content script itself (content scripts follows the Same Origin Policy) instead of having to delegate this task to the Add-on code (that can perform Cross Domain requests).
When we receive the response, the comic page's image url is extracted and displayed in the current page. And that's all!

The behavior related to hide and display the comics image is implemented in css file using media queries:

@media (orientation:portrait) {
  #penny-arcade-addon-comics {
    display: none;
  }
}
@media (orientation:landscape) {
  #penny-arcade-addon-comics {
    display: block;
  }
}

See the results

Navigate into the penny-arcade-comics directory and run it. You should see Fennec Nightly or Aurora ( whichever you specified ) start up on your device. Next, open the Firefox menu, select 'More', then 'Addons'. You should see the list of default addons installed into Firefox, as well as two additions: 'Mobile Addon-SDK utility addon' and 'penny-arcade-comics'.

You can now see how it works at first hand by opening the Penny Arcade site ( http://penny-arcade.com/ ) in Firefox Mobile:

Portrait

Landscape

If you do not have an Android device to test this on, you can still see the effect by installing this addon on Firefox Desktop and re-sizing the window to trigger the media queries we've used in our customer css.

When running the addon on your deivce, you will notice that your shell will be full of javascript warnings; this is because cfx will dump all of Firefox's log messages there. They can be useful, but especially when you work with page-mod it's easy lost your add-on's logging information in this flow. What I usually do instead is open a new shell, and execute a command like that:

adb logcat | grep info:

So, in the shell where cfx is executing I will get all the messages, and in the other one I filtered out only the messages from the add-on.

Conclusion

We're very excited about the possibilities around mobile addons and would love any feedback you might have. Working with the Android SDK currently is a bit awkwards, admittedly. If you do get started creating your own addons for Fennec Nightly, please keep in mind that not all SDK modules work properly.
The modules that currently work are:

• page-mod
• page-worker
• request
• self
• simple-storage
• timers

There are additional modules that mostly work; we are currently working on providing as much support for mobile as possible and will keep you up to date on our progress.

06 Feb 2012 12:07pm GMT

In this post I round-up my first time at FOSDEM and the two talks I gave during my time there; one on open Web apps and the other on creating games with HTML5.

This past weekend I have been in Brussels at FOSDEM, and absolutely massive free event for the open source software community. I hear there were over 5,000 people there this weekend, that's a lot of people.

Mozilla had a great presence there this year and hosted two full days of talks in the Mozilla DevRoom.

The Developer Engagement team also had a presence this weekend and put on a variety of talks ranging from hacking the Web with Jetpack, to Mozilla's new perspectives for 2012, to creating open Web documentation.

All in all, FOSDEM is a pretty awesome event absolutely crammed full of developers who care immensely about open software. It is very much a Linux-fest but the talks on Web technologies seemed to go down well. And aside from a few cases of anti-Apple/Microsoft/HTML5 sentiment the event was very successful and well-behaved.

Open Web Apps and the Mozilla Labs Apps project

The first talk that I had the opportunity to give at FOSDEM was on open Web apps and the Mozilla Labs Apps project. It's a very interesting topic that has been encouraging developers to think beyond the concept of Web apps being something that is just in the browser.

Open Web Games with HTML5 & JavaScript

The second talk that I gave was on open Web game development with HTML5 & JavaScript. During this talk I highlighted a selection of recent events within the HTML5 game industry as well as the key technologies that are involved. I also demoed the Gamepad API working in Firefox with a wireless xBox 360 controller.

06 Feb 2012 10:11am GMT

Now that Firefox 10 has been released, none of the major browsers send the Accept-Charset HTTP header.

During the Firefox 4 development cycle, I noticed that IE, Chrome and Safari were not sending the Accept-Charset HTTP header in their HTTP requests. This meant that the Web had to work even without browser sending that header.

It was already obvious that Accept-Charset was obsolete as a feature and was a waste of bytes in each HTTP request. If your server has the capability to vary what character encoding it uses, it could use UTF-8. All browsers support UTF-8. There is no way for any non-UTF-8 encoding to represent something more, since everything gets converted to UTF-16 internally. Thus, the browser and the server negotiating a suitable encoding is pointless.

There was indication that Opera was going to drop Accept-Encoding and indeed they have dropped it by now. In the case of Firefox, the change was not allowed in Firefox 4. Ms2ger removed Accept-Charset and landed the code for Firefox 6.

However, it turned out that Yahoo! Search and Yahoo! Babelfish malfunctioned when the browser identified itself as Firefox but did not send Accept-Charset. Since the sites worked in IE, Chrome and Safari, they obviously had to have code paths that functioned without Accept-Charset. However, the code paths were conditional on the UA string instead of the presence of Accept-Charset. Sigh.

To give Yahoo! time to fix their stuff, the change was backed out before release from Firefox 6. And then Firefox 7. And Firefox 8. And Firefox 9. The change was finally shipped in Firefox 10. Yahoo! Search had been fixed. Yahoo! Babelfish is still broken as of 2012-02-06.

Anyway, now none of Firefox, Opera, Safari, Chrome or IE send the Accept-Charset header. Yay for smaller HTTP requests.

What Can We Learn?

• As a server talking to a browser, always use UTF-8. No exceptions. Use the lang attribute for CJK disambiguation.
• It is hard to take cruft out of the HTTP request boilerplate. Resist the urge to put new cruft there.
• It is a bad idea to assume that a certain feature is present because the UA string looks a certain way. Check for the presence of the feature instead!
• If you defer a browser change in order to give a site the time to make a trivial adjustment, you may end up deferring the change many times.

06 Feb 2012 9:39am GMT

Serge Gautherie, alias sgautherie, est un utilisateur et un contributeur de longue date. Son parcours est emblématique de celui d'un contributeur acharné, jamais découragé par les changements opérés par le Panda Roux. Serge a commencé sur Mosaic ! est passé pas Netscape 2, puis 3, puis 4… Avant d'arriver à la suite d'applications Mozilla 0.9.5 (ou quelque chose comme ça) en octobre 2001. 2002 marque le début de ses aventures sur Bugzilla : d'abord il commente un bug, puis en signale, et finalement, en 2004, il se retrouve avec son premier bug assigné ! En fait, ses contributions, dit-il, ont évolué en même temps que ses moyens (et que ses machines). Aujourd'hui, Serge multiplie les patches (pas toujours compliqués, mais souvent très, très utiles), à la grande joie des développeurs de Mozilla qui l'apprécient énormément, et il collabore également à l'assurance qualité de Firefox. Mais actuellement, ce qui lui tient vraiment à cœur est SeaMonkey… Sinon, dans la vie, Serge est ingénieur en informatique, il a travaillé 7 ans avec des technologies JEE et Oracle avant de passer à des jeux internet en PHP/MySQL. Et il possède une petite collection d'anciennes consoles et ordinateurs.

Bonjour Serge !

Serge Gautherie, aka sgautherie, is a user and a long-time contributor. His career is emblematic of a hard working contributor, never discouraged by the changes made ​​by the Red Panda. Serge started on Mosaic! used Netscape 2, then 3, then 4… All that before coming to the Mozilla Application Suite 0.9.5 (or something like that) in October 2001. 2002 marks the beginning of his adventures on Bugzilla: first he posts a comment on a bug, then reports one, and finally, in 2004, he finds himself with his first assigned bug! In fact, his contributions, he said, have evolved along with his resources (and machines). Now, Serge makes several patches (not always complicated, but often very, very useful), to the delight of Mozilla developers who are very grateful, and he also works in quality assurance of Firefox. But now, what is the most important to him is SeaMonkey… Otherwise, Serge is a computer engineer, he worked 7 years with Oracle and JEE technologies before moving on to Internet games in PHP/MySQL. And he owns a small collection of old consoles and computers.

Bonjour Serge!

06 Feb 2012 9:00am GMT

We're building a new service at Services called the Token Server - The idea is simple : give us a Browser ID assertion and a service name, and the Token Server will send you back a token that's good for 30 minutes to use for the specific service.

That indirection makes our live easier to manage user authentication and resource allocation for our services . A few examples:

• when a new user wants to use Firefox Sync, we can check which server has the smallest number of allocated users, and tell the user to go there
• we can manage a user from a central place
• we can manage a user we've never heard about before without asking her to register specifically to each service - that's the whole point of Browser ID

I won't get into more details because that's not the intent of this blog post. But if you are curious the full draft spec is here - https://wiki.mozilla.org/Services/Sagrada/TokenServer

What's this post is really about is how to build this token server.

The server is a single web service that gets a Browser ID assertion and does the following:

1. verify the assertion
2. create a token, which is a simple JSON mapping
3. encrypt and sign the token

The GIL, Gevent, greenlet and the likes

Implementing this using Cornice and a crypto lib is quite simple, but has one major issue : the crypto work is CPU intensive, and even if the libraries we can use have C code under the hood, it seems that the GIL is not released enough to let your threads really use several cores. For example, we benched M2Crypto and it was obvious that a multi-threaded app was locked by the GIL.

But we don't use threads in our Python servers - we use Gevent workers, which are based on greenlets. But while greenlets help on I/O bound calls, it won't help on CPU bound work : you're tied into a single thread in this case and each greenlet that does some CPU work blocks the other ones.

It's easy to demonstrate - see http://tarek.pastebin.mozilla.org/1476644 If I run it on my Mac Book Air, the pure Python synchronous version is always faster (huh, the gevent version is *much* slower, not sure why..)

So the sanest option is to use separate processes and set up a messaging queue between the web service that needs some crypto work to be done and specialized crypto workers.

We're back in that case to our beloved 100% I/O bound model we know how to scale using NGinx + GUnicorn + GEvent

For the crypto workers, we want it to be as fast as possible, so we started to look at Crypto++ which seems promising because it uses CPU-specific calls in ASM. There's the pycryptopp binding that's available to work with Crypto++ but we happen to need to do some tasks that are not available in that lib yet - like HKDF.

Yeah, at that point it became obvious we'd use pure C++ for that part, and drive it from Python.

Message passing

Back to our Token server - we need to send crypto work to our workers and get back the result. The first option that comes in mind is to use multiprocessing to spawn our C++ workers and to feed them with work.

The model is quite simple, but now that we have one piece in C++, it's getting harder to use the built-in tools in multiprocessing to communicate with our workers - we need to be lower level and start to work with signals or sockets. And well, I am not sure what would be left of multiprocessing then.

This is doable but a bit of a pain to do correctly (and in a portable way.) Moreover, if we want to have a robust system, we need to have things like a hearbeat, which requires more inter-process message passing. And now I need to code it in Python and C++

Hold on - Let me summarize my requirements:

• inter-process communication
• something less painful than signals or sockets
• very very very fast

I got tempted by Memory Mapped Files, but the drawbacks I've read here and there scared me.

ZeroMQ

It turns out zeromq is perfect for this job - there are clients in Python and C++, and defining a protocol to exchange data from the Python web server to the crypto workers is quite simple.

In fact, this can be done as a reusable library that takes care of passing messages to workers and getting back results. It has been done hundreds of times, there are many examples in the zmq website, but I have failed to find any Python packaged library that would let me push some work to workers transparently, via a simple execute() call - if you know one tell me!.

So I am building one since it's quite short and simple - The project is called PowerHose and is located here : https://github.com/mozilla-services/powerhose.

Here is its descriptions/limitations:

• Powerhose is based on a single master and multiple workers protocol
• The Master opens a socket and waits for workers to register themselves into it
• The worker registers itself to the master, provides the path to its own socket, and wait for some work on it.
• Workers are performing the work synchronously and send back the result immediatly.
• The master load-balances on available workers, and if all are busy waits a bit before it times out.
• The worker pings the master on a regular basis and exits if it's unable to reach it. It attempts several time to reconnect to give a chance to the master to come back.
• Workers are language agnostic and a master could run heterogeneous workers (one in C, one in Python etc..)
• Powerhose is not serializing/deserializing the data - it sends plain strings. This is the responsibility of the program that uses it.
• Powerhose is not responsible to respawn a master or a worker that dies. I plan to use daemontools for this, and maybe provide a script that runs all workers at once.
• Powerhose do not queue works and just rely on zeromq sockets.

The library implements this protocol and gives two tools to use it:

• A JobRunner class in Python, you can use to send some work to be done
• A Worker class in Python and C++, you can use as a base class to implement workers

Here's an example of using Powerhose:

• The Server - https://github.com/mozilla-services/powerhose/blob/master/examples/square_master.py
• The Python worker - https://github.com/mozilla-services/powerhose/blob/master/examples/square_worker.py
• The C++ worker (don't look at the code - https://github.com/mozilla-services/powerhose/blob/master/examples/square_worker.cpp

For the Token server, we'll have:

• A JobRunner in our Cornice application
• A C++ worker that uses Crypto++

The first benches look fantastic - probably faster that anything I'd have implemented myself using plain sockets

I'll try to package Powerhose so other projects at Mozilla can use it. I am wondering if this could be useful to more people, since I failed to find that kind of tool. How do you scale your CPU-bound web apps ?

Filed under: mozilla, python

06 Feb 2012 8:03am GMT

Mozilla QA is looking for passionate and talented interns to take on the challenging position of Software Engineer in Test to help us test and deliver the highest quality Mozilla products and services. In this role you will dive into functionality of Firefox and cutting edge Mozilla web technologies with the goal of developing novel ways to ensure it all works as designed for our 500+ million users.

WebQA's chief role is to ensure that Mozilla websites are running smoothly and operating flawlessly. To help us achieve that, we are looking for talented interns to be immersed in:

• Developing and executing complex manual tests (using multiple browsers, and alongside a plethora of tools) that discover the hard-to-find defects of functionality, security and availability in Mozilla's web sites such as AMO (https://addons.mozilla.org), SUMO (http://support.mozilla.com) and Mozilla.org: http://mozilla.org
• Work with the top contributors of the Selenium test framework project to develop the best automated test solutions to ensure high-quality releases of Mozilla web sites and new cutting-edge Open Web Apps (OWA) project
• Contributing to the design and implementation of distributed automated tests and continuous-integration frameworks, such as Hudson/Jenkins. Along the journey, you'll have the opportunity to involve yourself with and contribute to other great open-source projects, in true Mozilla fashion.

Understanding and extending, Python-based plugins that our team relies on for its testing infrastructure, namely Pytest-MozWebQA (https://github.com/davehunt/pytest-mozwebqa) and Moz-Grid-Config (https://github.com/mozilla/moz-grid-config), among others

Requirements:

• Enrollment in a BS/MS in Computer Science or equivalent.
• Programming experience in one or more of the following languages; C, C++, Java, Python, JavaScript, and/or Perl.
• Expertise in Python and JavaScript a real plus.
• Exemplary oral and written communication skills
• Have demonstrated a high degree of initiative, self-motivation, and organizational savvy
• Clear analytical and problem-solving skills

How to Apply?

Please apply online at: http://bit.ly/xZQmkT

05 Feb 2012 9:26pm GMT

I just added 572 new free HTML+CSS templates to the One-Click Templates add-on for BlueGriffon, for a current total of 1030 available templates !

05 Feb 2012 10:06am GMT

about:memory and the memory reporter infrastructure that powers it are amazing. They provide an explicit hierarchy that breaks down the memory use in the system to the subsystems and increasingly the causes of allocation. about:memory looks like this (if you stand a few feet back from your monitor and take off your glasses):

If you are going to look at about:memory, it is probably for one of two reasons:

1. You are Nicholas Nethercote or one of his merry band of MemShrink hackers kicking ass and taking names (of inefficient uses of memory). In this case, about:memory is exactly what you need.
2. You suspect some tab in Firefox has gone crazy and you want to figure out which one it is and take your vengeance upon it. Vengeance can take the form of thinking mean thoughts, closing the tab, or writing a snarky tweet. about:memory will let you do this, but you have to look at a lot of text and you may already be too late to find the culprit! If only there was an easier way…

Enter about:nosy:

It can show us a list of all the open tabs and their memory usage sans JS for now, as per the above screenshot. If you expand the tab capsules, you get to see the list of all the inner windows/iframes that live in the hierarchy of that page. In most cases the list is either really short and boring or really long and boring. In the case of www.cnn.com I end up with 26 inner windows.

It can also show us memory aggregated by origin. We do show JS for this case because JS is currently only trackable on a per-origin basis. When Bug 650353 gets fixed or the memory reporters get more specific we should be able to apportion JS usage to pages directly.

It also attempts to aggregate extension JS compartments back to their owning extension. We ask the add-on manager for a list of the installed extensions to find their filesystem roots, ask the resource protocol to explain resource mappings, and from there are able to translate such paths. Just keep in mind that traditional overlay-based extensions do not create their own compartments and so are invisible for tracking purposes.

In the screenshot above, you can see that about:nosy keeps the charts exciting by generating a ridiculous amount of garbage all by itself. Much of this is just the about:memory tree-building code that we are reusing. If you refreshed about:memory once a second you would probably see similar garbage creation from the main system JS compartment.

You can install a restartless XPI of the state of the now that will not auto-update. It wants a recent nightly build of Firefox because it makes assumptions about the structure of the memory reporters in order to better serve you.

You can find the source repo on github. It requires the add-on SDK to build. It might seem a little overkill for just graphing memory history, but if you're looking at the repo you will notice my goal is to use Brian Burg's jsprobes work aided by Steve Fink and now de-bitrotted by me (but still a bit crashy) to be able to graph CPU usage, including raw JS, layout/reflow, and paint (eventually, after adding probe points). It's also possible for those statistics to be gathered via static mechanisms, but the probes are fun and I want to see them work.

05 Feb 2012 5:25am GMT

This is very retro, but I like the idea. From Norman Walsh's blog:

"Grab the nearest book, open it to page 23, find the 5th sentence, and post its text along with these instructions. Point back to where you got the idea so that we can follow the threads."

So, I did and funny things, the nearest book was Bible (honestly!). So, it is "Připravil jim hostinu, dal napéci nekvašené chleby a pojedli." For those who don't understand my beautiful native language, it is Genesis 19:3, which is in NASB translation: "[…] he prepared a feast for them, and baked unleavened bread, and they ate." Nice text, thinking about it. I am getting hungry.

05 Feb 2012 12:18am GMT

This past Friday we had a testday for Firefox 11.0b1. I would like to thank everyone who made the event a success.Throughout the day we had 8 testers and 16 moderators working hard to test, confirm bugs, and provide garbage and cycle collector data using the Memchaser add-on. I personally want to thank Aleksej, gaby2300, lcamacho, Swarnava, and everyone else for their hard work.

Stay tuned for details about next week's Firefox 11.0b2 Mobile testday.

04 Feb 2012 11:51pm GMT

Over the past several months BrowserID adoption by sites both inside and outside of Mozilla has started to take off. We have received a lot of feedback from site operators, some good, some bad. Far and away the biggest complaint from site operators is that completing the new user flow in BrowserID is causing drop off in potential users converting to verified users. Because of this, our own User Researcher Mary Trombley and UX guru Crystal Beasley have made it their mission to make this experience as smooth as possible.

Mary user tested our current sign up flow with people who had never used BrowserID. The results were eye opening. Users are doing things we suspected may cause problems, but we did not realize the extent of the confusion we were witnessing.

The core problem is that users get lost once they verify their email with BrowserID. No clear indication is given for how to return to the original site being signing up to. Sometimes users close the original site, sometimes they open the verification page in a new window, sometimes they start on mobile and finish on their desktop, sometimes they do everything we expect but don't realize the original site is still open in another tab. All users see after completing the new user flow is some text that says (paraphrased) "You have finished signing up to BrowserID…. You may now close this window."

Clearly, we have to do better.

Lloyd Hilaiel came up with some initial ideas outlined in the GitHub Tracking Issue. Skinny (Crystal) took these ideas and ran. She's got UX talent. The changes she suggested were so obvious it was like "duh, how did we not think of this before?" But then again, it's easy to say that in retrospect - the process for coming up with a smooth flow is anything but smooth.

Lloyd and Skinny's initial suggestion was to use some browser trickery to get the user back to the initial site once they have completed the verification step.

If the original site is still open, we can use a window.alert to return focus to its tab. This works in Firefox, Chrome and Safari - neither Opera nor IE play nicely. Mobile browsers universally show the alert message, but fail to return the user to the correct tab.

If the original site is no longer open, we can redirect the verification tab back to the original site. Overall this offers a much better experience, but still leaves a huge hole - if we have to redirect the current tab to the original site, currently we have no way of indicating to that site that the user is now logged in. We think we have a solution to this using DOM events. I did a quick proof of concept on this last night and will post a video once something more concrete is available.

These simple changes boosted our conversion rates quite a bit. Skinny then took the flow and made it even smoother. She thought "why not enter the password inside the dialog?" Brilliant - when the user opens the verification link from their email, they have no additional work to do - all they have to do is worry about logging in.

BrowserID New User Verification Flow Experiments Screencast from Shane Tomlinson on Vimeo.

Both of these flows can be tried with right now. This is experimental work made for user testing and feedback - these flows should not even be considered alpha quality.

Flow 1 - https://feature385.myfavoritebeer.org/ - window.alert if original site is still open or redirect to original site if closed.

Flow 2 - https://feature1000.myfavoritebeer.org/ - Same as flow 1 with initial password entry inside the dialog.

Note, for these experiments we are using "hacksign.in" as our test version of "browserid.org" - you are not being hacked. Both domains are running in separate environments, so you will have to create an account on each.

I will be continue hacking on these flows over the next couple of weeks. Additional user tests will be done. We are going to keep refining until we get it right. Any and all feedback is welcomed and encouraged.

Check it out, see what you think.

Want to get involved?

• Check out the code on GitHub.
• Message our mailing list at dev-identity@lists.mozilla.org or sign up to receive daily updates.
• Come see what we are up to in the Identity group or visit us on IRC in the #identity channel on irc.mozilla.org.

We'd love to hear from you about how we can make this better!

04 Feb 2012 9:25pm GMT

Tablets have so much potential, we're only just scratching the surface…

04 Feb 2012 6:11pm GMT

Timelapse, London, Ontario.

04 Feb 2012 5:33pm GMT

Mozilla's schedule for FOSDEM is quite busy:

1. There is an online streaming that can be watched from here

2. Follow #mozilla tag to follow what is going on right now at Fosdem - including nice quotes, slides and some hacks like this one:

Hacking the #Fosdem's "O" - Hack it and tag it with #fosdem-hack and get nice #Mozilla t-shirt (draw). - See more here

3. if you are here, please stop by our booth and get some buttons and join our effort to make the web better.

04 Feb 2012 4:15pm GMT

Le Fosdem a ouvert ses portes, dans la joie et la bonne humeur. Et Mozilla a dressé son stand… Pas à l'emplacement habituel. Alors, armez-vous de courage, mettez votre bonnet et votre écharpe (et des bonnes chaussures pour affronter la neige gelée), et venez nous retrouver au bâtiment K. On vous attend avec plein de jolis goodies :-)

Bonjour le Fosdem !

Fosdem opened, amongst joy and happiness. And Mozilla set up its booth… Not at the usual location. So be courageous, put your hat and your scarf (and good shoes to face the frozen snow), and come find us in the K building. We are waiting for you with lots of nice swag :-)

Bonjour Fosdem!

04 Feb 2012 3:19pm GMT