Articles for June 2011

Today, three months after the release of Firefox 4, we release Firefox 5, thanks to our new development cycle. Developers will be able to create richer animations using CSS3 Animations. This release comes with various improvements, performance optimization and bug fixes.

CSS3 Animations

CSS Animations (check out the documentation) are a new way to create animations using CSS. Like CSS Transitions, they are efficient and run smoothly (see David Baron’s article), and the developers have a better controls over the intermediate steps (keyframes), and can now create much more complex animations.

Notable changes

• You can now pass an image as a parameter to createImageDatato copy its dimensions.
• setTimeout and setInterval will only be able to execute callbacks once per second in inactive tabs. This follows the behavior of requestAnimationFrame to save CPU and power consumption.

Other Bug Fixes and Performance Improvements:

It always amazes me just how fast modern browsers and their JavaScript engines are. And how creative people get when trying to make things work inside a browser instead of relying on a plugin that our end users would have to install (and more importantly constantly keep up to date).

The latest thing that make me go “wow” is jsmad (source on GitHub) by Amos Wenger, Jens Nockert and Matthias Georgi. JSMad is an MP3 decoder in JavaScript!

“So what”, you say? Well, having JSMad means that now Firefox can play MP3 files without any Flash. It also means that you can listen to MP3 in the browser without the 64bit issues on Linux. With JSMad we can dive deep into the MP3 format and not only play the song but also get information about it. It allows us to build a lot of native dj-mixers, samplers and sequencers in the nearer future.

Right now JSMad works in Firefox 4+ and on Chrome 13.0+, if you enable the Web Audio API in ‘about:flags’.

I remember when MP3 came out and my computer back then was too slow to encode it without locking up in WinAmp. Back then a scene player also helped me out. Now we do the same inside a browser rather than desktop applications.

Starting from June, Mozilla runs a monthly competition to showcase newest web technologies. In an international competition individuals can submit demos that show the world just how much is possible using open and free technologies in a modern browser.

The Mozilla Dev Derby happens every month and revolves around a certain technology. A panel of judges will pick the winners and give out prizes including awesome laptop bags, Android phones and exclusive MDN T-Shirts. Above all, however, you can see your name pimped by Mozilla on here, on the Derby site and we will do short interviews with all the winners.

Many companies spend a lot of time and effort to create showcase demos to promote their browser, development environment or platform. Whilst this is great we think it makes for a much better learning experience to concentrate on one technology at a time and build smaller, more focused and better documented demos. This is why we want you to be in the driver seat and show us what you can do. There is no better way to learn a new technology than by playing with it.

The rules of the Mozilla Dev Derby are simple:

• Your demo must work in a current version of Firefox, Firefox Beta or Firefox Aurora, without requiring plug-ins.
• You must include all source code, including for any binary components.
• The description of the entry must be clear and accurate.
• The demo must be mainly your own work, and must not include unauthorized intellectual property of someone else.
• The name of your entry must not include any Mozilla trademarks.
• The entry must use open web technologies, such as HTML, CSS, and standard JavaScript APIs
• Libraries and modules that are freely available are allowed; proprietary ones are not.

To start off we chose CSS3 Animations as the first challenge. Use CSS to animate page content and create movie-style intros (remember the AT-AT walker demo?) and show us how designers can animate without the need for plugins or scripting knowledge. NOTE: Firefox 5 will introduce support for CSS3 Animations. You should use the Firefox Beta or Aurora channel for this Dev Derby. Your demo will not work in Firefox 4. ;-)

So, Ladies and Gentlemen, start your engines and head over to the Mozilla Dev Derby site.

Firefox offers users complete control over the look and functionality of their Web browser with a gallery of hundreds of thousands of add-ons. With the launch of Add-on SDK and Add-on Builder Beta, web developers  need only knowledge of HTML, JavaScript and CSS to create great add-ons for Firefox that are restartless by default.

The Add-on SDK enables local development of add-ons through a command line interface, while the Firefox Add-on Builder Beta provides a hosted online build environment.

To find out more, head over to the Add-ons blog or the new Add-on SDK & Add-on Builder page.

Update: We had a doubt whether this port of the Open Source Doom respected its term of use. We decided to remove it from our Website before taking an informed and definitive decision.

This is a guest post written by Alon Zakai. Alon is one of the Firefox Mobile developers, and in his spare time does experiments with JavaScript and new web technologies. One of those experiments is Emscripten, an LLVM-to-JavaScript compiler, and below Alon explains how it uses typed arrays to run the classic first-person shooter Doom on the web.

As a longtime fan of first-person shooters, I’ve wanted to bring them to the web. Writing one from scratch is very hard, though, so instead I took the original Doom, which is open source, and compiled it from C to JavaScript using Emscripten. The result is a version of Doom that can be played on the web, using standard web technologies.

Doom renders by writing out pixel data to memory, then copying that pixel data to the screen, after converting colors and so forth. For this demo, the compiled code has memory that is simulated using a large JavaScript array (so element N in that array represents the contents of memory address N in normal native code). That means that rendering, color conversion, and copying to the screen are all operations done on that large JavaScript array. Basically the code has large loops that copy or modify elements of that array. For that to be as fast as possible, the demo optionally uses JavaScript typed arrays, which look like normal JavaScript arrays but are guaranteed to be flat arrays of a particular data type.

// Create an array which contains only 32-bit Integers
var buffer = new Int32Array(1000);
for ( var i = 0 ; i < 1000 ; i++ ) {
    buffer[i] = i;
}

When using a typed array, the main difference from a normal JavaScript array is that the elements of the array all have the type that you set. That means that working on that array can be much faster than a normal array, because it corresponds very closely to a normal low-level C or C++ array. In comparison, a normal JavaScript array can also be sparse, which means that it isn't a single contiguous section of memory. In that case, each access of the array has a cost, that of calculating the proper memory address. Finding the memory address is much faster with a typed array because it is simple and direct. As a consequence, in the Doom demo the frame rate is almost twice as fast with typed arrays than without them.

Typed arrays are very important in WebGL and in the Audio Data API, as well as in Canvas elements (the pixel data received from getImageData() is, in fact, a typed array). However, typed arrays can also be used independently if you are working on large amounts of array-like data, which is exactly the case with the Doom demo. Just be careful that your code also works if the user's browser does not support typed arrays. This is fairly easy to do because typed arrays look and behave, for the most part, like normal ones — you access their elements using square brackets, and so forth. The main potential pitfalls are:

• Typed arrays do not have the slice(). Instead they have the subarray(), which does not create a copy of the array — instead it's a view into the same data.
• Don't forget that the type of the typed array is silently enforced. If you write 5.25 to an element of an integer-typed array and then read back that exact same element, you get 5 and not 5.25.

The <progress> element just landed in Firefox Aurora (to be Firefox 6).

As its name indicate, this element can be used to give visual clues of anything in progress on a Web page:

• a set of ressources being downloaded,
• a file being uploaded,
• a computing Web Worker,
• a WebGL scene being initialized…

Following is a simple demonstration of how the progress element can be used in conjunction with the FileReader API to create an ajax file uploader.

Don’t forget to click on result to see the code in action.

In Firefox 5, it is no longer possible to use cross-domain elements as the source for WebGL textures. We made this change in response to security concerns around the possibility of cross domain information leakage. Unfortunately, that means that some WebGL-using pages are no longer working. We are working with the WebGL WG on a solution to allow such pages to resume working as soon as possible — read on for details.

The security rules about cross-domain images

A cross-domain image is an image coming from a different domain than the canvas. A basic rule of Web security is that scripts must not be able to read pixel data from cross-domain images — they can only “blindly” display them. In more concrete terms, imagine that you currently have a session open on your bank’s website, allowing you to download scanned copies of cheques you’ve written. You don’t want scripts loaded in other tabs, from other websites, to be able to read your scanned cheques! Similarly, when you draw a cross-domain image onto a 2D canvas, using drawImage(), the canvas becomes “tainted” so that it’s no longer possible for scripts to read its pixels. This prevents a loophole whereby a canvas would be used as a proxy to read cross-domain images.

The problem with cross-domain images as WebGL textures

When a cross-domain image was used as a WebGL texture, the WebGL canvas was “tainted” so that reading from it was no longer possible. Theoretically, that eliminated the concern. But a while ago, a researcher wrote to the public WebGL list with a possible attack that could still allow reading pixels from WebGL textures. The idea was to paint the texture one pixel at a time with a WebGL fragment shader crafted to take an amount of time proportional to its brightness, and then time how long it takes: that would conceivably allow to get an approximation of the original image. Initially this attack seemed difficult to execute practically, but since then further research, including a proof-of-concept has been published which shows the attack to be more realistic than initially expected.

The response

The WebGL spec has been updated to disallow using cross-domain images as WebGL textures, and Mozilla’s implementation in Firefox 5 has been updated accordingly. A non-normative section has also been added allowing cross-domain images that have CORS approval. Using CORS in this case is a way for servers to explicitly say when an image is OK to be read by cross-domain scripts. CORS support for WebGL is a high priority for us and will be implemented very soon.

A wiki page explains some more details. Affected scripts will generate a DOM_SECURITY_ERR exception and, just before that, a JS warning explaining what happened and linking to that wiki page.

Last week the Converge SE conference in Columbia, South Carolina attracted about 400 designers, developers and product managers to attend workshops and hear keynotes about all that is new and great in web development.

As you can see on the conference schedule the conference covered a lot of topics, ranging from building communities and providing great end user service over creating engaging video demos up to using CSS pseudo selectors, web fonts and responsive design.

It was especially refreshing to see that instead of showing theoretical examples or demos most of the speakers showed the new technologies as they used them in real products. Ethan Marcotte for example previewed the upcoming Boston Globe redesign to the audience.

Mozilla’s involvement (apart from sponsoring the event) was a keynote on the why of HTML5. In 96 slides and just above 30 minutes I explained:

• How HTML5 came to be
• Why it is not about selling browsers or hardware or comparing yourself with the competition
• That HTML5 is part of a larger world of new technologies
• That HTML5 means first and foremost improving the infrastructure for web applications and using the hardware and software people use to their full potentials
• That using HTML5 means a shift in our thinking as web developers and needs re-evaluation of some of our “best practices”
• That everybody should start using it and help us make it really work instead of being amazed by cool demos but failing to use these new technologies in day to day products

The slides are available on Slideshare:

There is an audio recording of the talk on archive.org:

Converge SE was filmed, so I am quite sure the videos will be out soon and you will find more of the presentations using the convergese tag.