Here are highlights from the topics covered in this new issue:

• Firefox 3.6 released: what’s new, how to give feedback
• Firefox for the Nokia N900 with Weave Sync released
• Developer Tools: Firebug 1.5
• Demos: an HTML5 image editor and uploader, a WebGL demo
• Behind the Scenes: Firefox release timeline, experimenting with sound and light
• New on MDC: Firefox.next, WebGL docs
• Hacks blog redesign

If you do not subscribe to about:hacks, you will find the second issue in the archives. If you enjoy the content, consider subscribing to make sure you receive the third issue, coming in March.

Finally, we’d love to get your feedback on the newsletter: what do you like, what would you change, what topics would you like us to cover. Please take a minute to fill out the feedback form.

We hope that you took the time to test Firefox 3.6 on your web sites before the release. If you didn’t, it’s not too late to let us know about issues. Here are a few problems that we’ve seen in the wild so far:

• We’ve seen a couple of issues with the FCKEditor component, used widely on the web. It apparently doesn’t handle dates after 2009 properly (this is the first major browser release in 2010, a new decade!) and it also has some problems with document.readyState.
• People who had the YSlow extension installed saw crashes with Firefox 3.6. YSlow has been updated to version 2.0.6 to fix the issue
• Some Facebook apps were broken by a change we made to comply with the upcoming HTML5 standard. We updated element.getElementsByTagNameNS and document.getElementsByTagNameNS to no longer case-fold when doing tag name lookups. (We strongly suggest that you only use lower-case for tag names for many reasons, including this.) For more information, please see this note from Henri Sivonen about what’s changed. Facebook has since fixed the issue in their code, but other sites may also be tripping over this.

We’re looking for feedback on any developer-facing regressions you’ve seen in 3.6 from 3.5. Please comment on this post if you have feedback.

Firefox 3.6 offers many new Open Web features to web developers, including even more HTML5 support. This post describes how to create a sophisticated image editor and uploader built using Open Web technologies.

See below for a video of the demo with some background.

Hosted on hacks, publishes to twitpic

Our web application uploads pictures to twitpic, an image hosting service for Twitter.

Note that code for this application is actually hosted on the hacks web server but can still upload to Twitpic. Uploading to Twitpic is possible because they opened up their API to Cross Domain XMLHttpRequests for applications like this. (Thank you twitpic!).

Web Features

The demo uses the following features from HTML5 included in Firefox 3.6:

• HTML5 Drag and Drop: You can drag and drop items inside of the web page and drag images from your desktop directly into the browser.
• HTML5 localStorage: to store the image data across browser restarts
• HTML5 Application Cache: This allows you to create applications that can be used when the browser isn’t connected to the Internet. It stores the entire app in the browser and also gives you access to online and offline events so you know when you need to re-sync data with a server.
• HTML5 Canvas: The HTML5 Canvas element is used through this demo to edit and render images.
• Cross-Origin Resource Sharing to host an application at one site and publish data to another.

What’s in the demo?

See the live demo to try the image uploader for yourself. You will need Firefox 3.6 and a twitter account.

Here’s a full list of the things that this application can do:

• You can drag images from your desktop or the web into the application.
• You can see a preview of each image you want to upload.
• You can drag previews to the trash to delete an image.
• Images are automatically made smaller if they are bigger than 600px wide.
• You can edit any of the images before uploading. This includes being able to rotate, flip, crop or turn an image black and white.
• If you edit an image it’s saved locally so you can still edit when you’re offline. If you close the tab, restart Firefox or your computer they will be there when you load the page again so you can upload when you’re re-connected.
• It will upload several files at once and provide feedback as the upload progresses.
• The HTML5 Offline Application Cache makes the application load very quickly since it’s all stored offline.

Under the Hood

Let’s quickly go over all of the technology that we’re using in this application.

Cross-XMLHttpRequest

Twitpic was nice enough to open their API to allow XMLHttpRequests from any other domain. This means that you can now use their API from your own website and offer your own image uploader.

If you’re running a web site with an API you want people to use from other web sites, you can do that with Cross-site HTTP requests. In order for you to support it you will need to add an HTTP header to responses from your web server that says which domains you allow. As an example, here’s how twitpic allows access from all domains:

Access-Control-Allow-Origin: *

It’s important to note that opening your API does have security implications so you should be careful to understand those issues before blindly opening an API. For more details, see MDC documentation on CORS.

Drag and Drop

Drag and Drop is a mechanism with two important features:

• Dragging files from your Desktop to your web page.
• Native Drag and Drop inside your web page (not just changing the coordinates of your elements).

The image uploader uses Drag and Drop to allow the user the add files from the Desktop, to remove files (drag them to the trash) and to insert a new image into a current image.

For more on Drag and Drop, see previous hacks articles, in particular how to use Drag and Drop in your application.

Canvas to Edit Images

Once images have been dragged and dropped into the web page, the image uploader lets you edit them before uploading. This is possible because images are actually copied to canvas elements via the File API.

In this case, the editing process is really basic: rotate, flip, add text, black and white, crop. However, you can imagine offering many other features in your version of the editor (see Pixastic for example, or this inlay feature here).

Using canvas and the File API also let you resize the image before sending it. Here, every image is converted to a new image (canvas) that is less than 600px.

localStorage: Save Local Data

It’s possible to store local data persistently in a web page using localStorage, up to 5Mb of data per domain.

In the image uploader, localStorage is used to store images and credentials. Since images are actually canvas, you can store them as data URLs:

var url = canvas.getContext("2d").toDataURL("image/png");
localStorage.setItem("image1", url);

LocalStorage support means that you can edit an image, close Firefox, switch off your computer, and the edited image will still be there when you restart Firefox.

Offline

If you add a manifest file listing all remote files needed to display your web application it will work even when you aren’t connected to the Internet. A nice side effect is that it will also make your application load much faster.

Here, the html element refers to a manifest file:

<html manifest="offline.manifest">

And the manifest file looks like:

CACHE MANIFEST

# v2.4
index.xhtml
fonts/MarketingScript.ttf
css/desktop.css
css/fonts.css
css/mobile.css
[...]

You can also catch offline and online events to know if the connection status changes.
For more information see our last article about offline.

Conclusion

Firefox 3.6 allows millions of people to take advantage of modern standards, including HTML5.
The image uploader described here shows how a web page should really be considered as an application since it interacts with your Desktop and works offline.

Here are a few tips for writing your next application using Open Web technologies:

Allow Cross-XMLHttpRequest:
If it makes sense for your service, allow people to access your API from a different domain, you’ll be amazed at the apps people will come up with.

Allow multiple input:
Let people Drag files to your application and use <input type="file" multiple=""> so they can select several files at once. In this demo, we use a multiple input which is visible only in the mobile version, but for accessibility consideration, don’t forget to use it to propose an alternative to Drag’n Drop.

Use native Drag and Drop:
Drag and Drop mechanisms are usually simulated (updating coordinates on the mousemove event.) When you can, use the native mechanism.

Use the File API
To pre-process a file before even talking to a server.

Support offline
Store data and use a manifest to make your application data persistent while offline.

Use Canvas
Canvas is the most widely implemented HTML5 element. It works everywhere (even if it has to be simulated), use it!

Think “Client Side”: HTML5, CSS3 and the new powerful JavaScript engines let you create amazing applications, take advantage of them!

We look forward to seeing the great new applications you’ll come up with using Open Web technologies!

Why you need classList

A dynamic web application usually needs visual feedback from its inner mechanism or needs to display different visual elements based on users’ actions.

To change the user interface easily, you can add/remove/edit elements through the DOM API (document.createElement, div.removeChild, elt.style.color, …) but it’s easier to just update the elements’ class attribute to change how they are displayed and styled by CSS.

Let’s take an example. Suppose you want to display a form with two modes: a basic mode, and an expert mode with extra options.

This can be done with CSS rules: each mode has its own class and set of CSS code.

#anexpertinput.basic {
  display: none;
}
#anexpertinput.expert {
  display: inline;
}

To dynamically change the classes of elements, you can use element.className. However, you may want to add, remove, or toggle just one class. There used to be two ways to do this, by using a library or by writing complex code with regular expressions. There is now another way with the new HTML5 API called classList, which is implemented in Firefox 3.6.

Let’s see how it can simplify your code and improve performance at the same time.

The classList API

Here is an example to show you what the classList API looks like:

// By default, start without a class in the div: <div class=""/>
 
// Set "foo" as the class by adding it to the classList
div.classList.add('foo'); // now <div class="foo"/>
 
// Check that the classList contains the class "foo"
div.classList.contains('foo'); // returns true
 
// Remove the class "foo" from the list
div.classList.remove('foo'); // now <div class=""/>
 
// Check if classList contains the class "foo"
div.classList.contains('foo'); // returns false: "foo" is gone
 
// Check if class contains the class "foo",
// If it does, "foo" is removed, if it doesn't, it's added
div.classList.toggle('foo'); // class set to <div class="foo"/>
div.classList.toggle('foo'); // class set to <div class=""/>

Demo

Let’s go back to our initial example of a form with both a basic and an expert mode – check out the live demo to see it in action.

As you can see in the code below, you can switch between the two modes with one line of JavaScript.

<button onclick="document.getElementById('box').classList.toggle('expert');">
  Toggle expert mode
</button>
<div id="box">
  <label for="nick">Name: <input type="text" id="nick" /></label>
  <label for="status">Status: <input type="text" id="status" /></label>
  <p id="help"> Blablablablabla...</p>
  <label for="postpone">Postpone: <input type="checkbox" id="postpone" /></label>
  <label for="lang">Lang: <input type="text" id="lang" /></label>
</div>

#box.expert > #help,
#box.expert > label[for="postpone"],
#box.expert > label[for="lang"] {
   display: none;
}

See the Mozilla documentation and the HTML5 specification for more details on classList.

Performance

Using the classList API is not only easier, it’s also more powerful. Take a look at what we observed using Firefox 3.6.

Interoperability

Since other browser vendors have not yet implemented the HTML5 classList API, you still need fallback code. You can use this sample code as fallback.

To know more about the current implementation of classList in well-known JavaScript libraries, see:

• YUI
• Prototype
• jQuery (and here)
• Base2

WOFF has received wide support from the type community and we’re starting to see the results of that. There are a couple of specific instances that we’d like to point out on day zero of our release:

1. FontFont, one of the largest type foundries in the world, announced a free-as-in-beer demo font in the WOFF format called FF Nuvo Medium Demo. This is part of FontFont’s commitment to support the new format and to start to give people the tools to start to adopt it.

2. Typekit, a commercial hosting provider for fonts, announced that they will start serving up WOFF fonts to Firefox 3.6 users.

It’s great to see commercial support already ramping up to support the new format. It’s going to really improve the experience for users on the web.

Firefox 3.6 has some cool consumer facing features like Personas and a better Plug-in Updater, but developers have a lot to be excited about too.  Developers will appreciate the increased stability, especially the work done to prevent crashes with third party software.  There are also enhancements like improved JavaScript performance and optimizations to speed up everyday Web tasks to make web applications snappier.  However, what developers will be most interested in are all the new features around CSS3 and HTML5 that bring the future of the Web to Firefox 3.6 today. 

This is an exciting release because we have built on the progress we made with Firefox 3.5 just a few months ago and have implemented even more cutting-edge features that will make the Web experience more engaging and interactive than ever before.

Today’s Firefox 3.6 release and the upcoming mobile release of Firefox for Maemo are both based on Gecko 1.9.2 and bring a number of big features including:

• New CSS3 features: Improve your style with support for gradients, multiple backgrounds, pointer-events and more.
• Drag and Drop: It has never been easier to move files from your desktop to the Web.  You can now drag content into the browser window and leverage the FileAPI for instant access to that content.
• File API: Support for the latest HTML5 specification allows Web applications to access local files and interact with them in new ways.
• Web Open Font Format (WOFF): Add a touch of typography to the Web with WOFF support, which makes even more possible than the existing support for OpenType and TrueType fonts.
• Device orientation: Discover new ways to manipulate and interact with Web content with access to the orientation of supported laptops and devices.
• XMLHttpRequest improvements and more…

For a more in-depth look at all the changes that developers will want to know about please check out Firefox 3.6 for Developers on MDC. And if you haven’t already, go get Firefox 3.6 now!

If you’d like to take a more in-depth look at what’s new in Firebug 1.5, here’s a series of articles written by Firebug contributor Jan Odvarko (aka Honza):

• Break On Next: breaking on the next executed script, HTML mutation, XHR execution, or JavaScript error.
• XHR breakpoints: creating conditional breakpoints in XMLHttpRequest execution.
• Debugging cookies: using the Firecookie extension to break JS execution on cookie changes.
• Page load analysis: 6 examples analyzing data provided by the Net panel.
• HTTP Time Monitor: using Network Activity Observer for more accurate timing.
• XML Response Explorer: inspecting XML based responses received from the server.
• Network info header and column customization: specifying what information to display within the Net panel.

If you’ve had a chance to try the new Firebug, comment here or in the Firebug newsgroup and tell the team what you think!

I am very happy to be able to announce the release of Firebug 1.5.0 on addons.mozilla.org. This release represents a significant effort by the Firebug Working Group which saw the addition of some new faces over the last few months.

Here’s a quick run-down of some of the new features:

• Enhanced Inspector
• More accurate Net panel timings
• Break on HTML mutation
• MathML and SVG namespace support
• Break on XHR
• Improved HTML editing
• Persist buttons on Console and Net panel
• Separate Computed CSS and Style subpanels
• Many many bugfixes and stability improvements

This is a huge release and these are just some of the highlights you’ll see in this new version. Please feel free to read the Firebug 1.5 release notes and John Barton’s blog post for more details.

As always, if you encounter any problems, don’t be shy about filing a bug! We’ll be following up with quick point-releases if and when you find issues.

Special shout-outs and thanks to Mike Ratcliffe for the Inspector improvements, Steven Roussey for HTML editor improvements, SVG and MathML namespace patches, Honza for being awesome and John Barton for his tireless contributions.

If you’re new to Firebug, you might want to check out my introduction to Firebug screencast.

Firefox 3.5 introduced TraceMonkey, our new JavaScript engine that traces loops and JIT compiles them to native (x86/ARM) code. Many JavaScript programs ran 3-4x faster in TraceMonkey compared to Firefox 3. (See our previous article for technical details.)

For JavaScript performance in Firefox 3.6, we focused on the areas that we thought needed further improvement the most:

• Some JavaScript code was not trace-compiled in Firefox 3.5. Tracing was disabled by default for Firefox UI JavaScript and add-on JavaScript, so those programs did not benefit from tracing. Also, many advanced JavaScript features were not trace-compiled. For Firefox 3.6, we wanted to trace more programs and more JS features.
• Animations coded with JavaScript were often choppy because of garbage collection pauses. We wanted to improve GC performance to make pauses shorter and animations smoother.

In this article, I’ll explain the most important JS performance improvements that come with Firefox 3.6. I’ll focus on listing what kinds of JS code get faster, including sample programs that show the improvements Fx3.6 makes over Fx3.5.

JIT for Browser UI JavaScript

Firefox runs JavaScript code in one of two contexts:content and chrome (no relation to Google Chrome). JavaScript that is part of web content runs in a content context. JavaScript that is part of the browser UI or browser add-ons runs in a chrome context and has extra privileges. For example, chrome JS can alter the main browser UI, but content JS is not allowed to.

The TraceMonkey JIT can be enabled or disabled separately for content and chrome JS using about:config. Because bugs affecting chrome JS are a greater risk for security and reliability, in Firefox 3.5 we chose to disable the JIT for chrome JS by default. After extensive testing, we’ve decide to enable the JIT for chrome JS by default, something we did not have time to fully investigate for Fx3.5. Turning on the JIT for chrome should make the JS behind the Firefox UI and add-ons run faster. This difference is probably not very noticeable for general browser usage, because the UI was designed and coded to perform well with the older JS engines. The difference should be more noticeable for add-ons that do heavy JS computation.

Garbage Collector Performance

JavaScript is a garbage-collected language, so periodically the JavaScript engine must reclaim unused memory. Our garbage collector (GC) pauses all JavaScript programs while it works. This is fine as long as the pauses are “short”. But if the pauses are even a little too long, they can make animations jerky. Animations need to run at 30-60 frames per second to look smooth, which means it should take no longer than 17-33 ms to render one frame. Thus, GC pauses longer than 40 ms cause jerkiness, while pauses under 10 ms should be almost unnoticeable. In Firefox 3.5, pause times were noticeably long, and JavaScript animations are increasingly common on the web, so reducing pause times was a major goal for JavaScript in Firefox 3.6.

Demo.
The spinning dial animation shown here illustrates pause times. Besides animating the dial, this demo creates one million 100-character strings per second, so it requires frequent GC. The frame delay meter gives the average time between frames in milliseconds. The estimated GC delay meter gives the average estimated GC delay, based on the assumption that if a frame has a delay of 1.7 times the average delay or more, then exactly one GC ran during that frame. (This procedure may not be valid for other browsers, so it is not valid for comparing different browsers. Note also that the GC time also depends on other live JavaScript sessions, so for a direct comparison of two browsers, have the same tabs open in each.) On my machine, I get an estimated GC delay of about 80 ms in Fx3.5, but only 30 ms in Fx3.6.

But it’s a lot easier to see the difference by opening the demo in Fx3.5, watching it a bit, and then trying it in Fx3.6.
In Fx3.5, I see frequent pauses and the animation looks noticeably jerky. In Fx3.6, it looks pretty smooth, and it’s hard for me even to tell exactly when the GC is running.

How Fx3.6 does it better. We’ve made many improvements to the garbage collector and memory allocator. I want to give a little more technical details on the big two changes that really cut our pause times.

First, we noticed that a large fraction of the pause time was spent calling free to reclaim the unused memory. We can’t do much to make freeing memory faster, but we realized we could do it on a separate thread. In Fx3.6, the main JS thread simply adds unused memory chunks to a queue, and another thread frees them during idle time or on a separate processor. This means machines with 2 or more cores will benefit more from this change. But even when one core, freeing might be delayed to an idle time when it will not affect scripts.

Second, we knew that in Fx3.5 running GC clears out all the native code compiled by the JIT as well as some other caches that speed up JS. The reason is that the tracing JIT and GC did not know about each other, so if the GC ran, it might reclaim objects being used by a compiled trace. The result was that immediately after a GC, JS ran a bit slower as the caches and compiled traces were built back up. This would be experienced as either an extended GC pause or a brief hiccup of slow animation right after the GC pause. In Fx3.6, we taught the GC and the JIT to work together, and now the GC does not clear caches or wipe out native code, so it resumes running normally right after GC.

Tracing More JavaScript Constructs

In my article on TraceMonkey for the Fx3.5 release, I noted that certain code constructs, such as the arguments object, were not traced and did not get performance improvements from the JIT. A major goal for JS in Fx3.6 was to trace more stuff, so more programs can run faster. We do trace more stuff now, in particular:

• DOM Properties. DOM objects are special and harder for the trace compiler to work with. For Fx3.5, we implemented tracing of DOM methods, but not DOM properties. Now we trace DOM properties (and other “native” C++ getters and setters) as well. We still do not trace scripted getters and setters.
• Closures. Fx3.5 traced only a few operations involving closures (by which I mean functions that refer to variables defined in lexically enclosing functions). Fx3.6 can trace more programs that use closures. The main operation that is still not traced yet is creating an anonymous function that modifies closure variables. But calling such a function and actually writing to the closure variables are traced.
• arguments. We now trace most common uses of the arguments keyword. “Exotic” uses, such as setting elements of arguments, are not traced.
• switch. We have improved performance when tracing switch statements that use densely packed numeric case labels. These are particularly important for emulators and VMs.

These improvements are particularly important for jQuery and Dromaeo, which heavily use arguments, closures, and the DOM. I suspect many other complex JavaScript applications will also benefit. For example, we recently heard from the author that this R-tree library performs much better in Fx3.6.

Here is a pair of demos of new things we trace. The first sets a DOM property in a loop. The second calls a sum function implemented with arguments I get a speedup of about 2x for both of them in Fx3.6 vs. Fx3.5.

function sum() {
  var ans = 0;
  for (var i = 0; i < arguments.length; ++i)
    ans += arguments[i];
  return ans;
}

function runTracingTests() {
  var t0 = new Date;

  var domObj = document.getElementById('dom_time');
  for (var i = 0; i < 600000; ++i)
    domObj.x = 10;

  var t1 = new Date;

  for (var i = 0; i < 30000; ++i)
    sum(1, 2, 3, 4, 5);

  var t2 = new Date;

  document.getElementById('dom_time').innerHTML = (t1-t0) + ' ms';
  document.getElementById('sum_time').innerHTML = (t2-t1) + ' ms';
}

String and RegExp Improvements

Fx3.6 includes several improvements to string and regular expression performance. For example, the regexp JIT compiler now supports a larger class of regular expressions, including the ever-popular \w+. We also made some of our basic operations faster, like indexOf, match, and search. Finally, we made concatenating sequences of several strings inside a function (a common operation in building up HTML or other kinds of textual output) much faster.

Technical aside on how we made string concatenation faster: The C++ function that concatenates two strings S1 and S2 does this: Allocate a buffer big enough to hold the result, then copy the characters of S1 and S2 into the buffer. To concatenate more than two strings, as in JS s + "foo" + t, Fx3.5 simply concatenates two at a time from left to right.

Using the Fx3.5 algorithm, to concatenate N strings each of length K, we need to do N-1 memory allocations, and all but one of them are for temporary strings. Worse, the first two input strings are copied N-1 times, the next one is copied N-2 times, and so on. The total number of characters copied is K(N-1)(N+2)/2, which is O(N^2).

Clearly, we can do a lot better. The minimum work we can do is to copy each input string exactly once to the output string, for a total of KN characters copied. Fx3.6 achieves this by detecting sequences of concatenation in JS programs and combining the entire sequence into one operation that uses the optimal algorithm.

Here are a few string benchmarks you can try that are faster in Fx3.6:

function words() {
  var text_unit = 'word ';
  var text = '';
  for (var i = 0; i < 1000; ++i)
    text += text_unit;

  var t0 = new Date;
  for (var i = 0; i < 300; ++i)
    text.match(/\w+/g)
  return new Date - t0;
}

function indexOf_foo() {
  var text_unit = 'bar baz quux ';
  var text = '';
  for (var i = 0; i < 1000; ++i)
    text += text_unit;
  text += 'foo';

  var t0 = new Date;
  for (var i = 0; i < 3000; ++i)
    text.indexOf('foo')
  return new Date - t0;
}

function match_foo() {
  var text_unit = 'bar baz quux ';
  var text = '';
  //for (var i = 0; i < 1000; ++i)
  //  text += text_unit;
  //text += 'foo';
  text = 'bar baz qux quux foo';

  var t0 = new Date;
  for (var i = 0; i < 100000; ++i)
    text.search('foo')
  return new Date - t0;
}

function runStringTests() {
  var dt1 = words();
  var dt2 = indexOf_foo();
  var dt3 = match_foo();
  var dt4 = buildHTML();

  document.getElementById('words_time').innerHTML = dt1 + ' ms';
  document.getElementById('indexOf_foo_time').innerHTML = dt2 + ' ms';
  document.getElementById('match_foo_time').innerHTML = dt3 + ' ms';
  document.getElementById('buildHTML_time').innerHTML = dt4 + ' ms';
}

function buildHTML(url, text, style) {
  var t0 = new Date;
  for (var i = 0; i < 100000; ++i)
    var q = '' + text + '';
  return new Date - t0;
}

Final Thoughts and Next Steps

We also made a lot of little improvements that don't fit into the big categories above. Most importantly, Adobe, Mozilla, Intel, Sun, and other contributors continue to improve nanojit, the compiler back-end used by TraceMonkey. We have improved its use of memory, made trace recording and compiling faster, and also improved the speed of the generated native code. A better nanojit gives a boost to all JS that runs in the JIT.

There are two big items that didn't make the cut for Fx3.6, but will be in the next version of Firefox and are already available in nightly builds:

• JITting recursion. Recursive code, like explicit looping code, is likely to be hot code, so it should be JITted. Nightly builds JIT directly recursive functions. Mutual recursion (g calls f calls g) is not traced yet.
• AMD x64 nanojit backend. Nanojit now has a backend that generates AMD x64 code, which gives the possibility of better performance on that plaform.

And if you try a nightly build, you'll find that many of these demos are already even faster than in Fx3.6!

Yet having offline support for web applications can be very useful to users. Imagine, for example, a webmail application that allows users to read emails already in their inbox and write new messages even when they are not connected.

The mechanism used to support offline web applications can also be used to improve an application’s performance by storing data in the cache or to make data persistent between user sessions and when reloading and restoring pages.

Demo: a To Do List Manager

To see an offline web application in action, watch Vivien Nicolas’ demo, which shows a to do list manager working online and offline on an N900 running Firefox:

You can also check out the live demo of the application.

Creating your Own Offline Application

For a web application to work offline, you need to consider three things:

• Store user inputs through localStorage
• Define which files should be cached via a manifest file
• Manage connection changes with online and offline events

Let’s see how to use each of these components.

Storage: Persistent Data

DOM storage lets you store data between browser sessions, share data between tabs and prevent data loss (for example from page reloads or browser restarts). The data are stored as strings (for example a JSONified JavaScript object) in a Storage object.

There are two kinds of storage global objects: sessionStorage and localStorage.

• sessionStorage maintains a storage area that’s available for the duration of the page session. A page session lasts for as long as the browser is open and survives over page reloads and restores. Opening a page in a new tab or window causes a new session to be initiated.
• localStorage maintains a storage area that can be used to hold data over a long period of time (e.g. over multiple pages and browser sessions). It’s not destroyed when the user closes the browser or switches off the computer.

Both localStorage and sessionStorage use the following API:

window.localStorage and window.sessionStorage {
  long length; // Number of items stored
  string key(long index); // Name of the key at index
  string getItem(string key); // Get value of the key
  void setItem(string key, string data); // Add a new key with value data
  void removeItem(string key); // Remove the item key
  void clear(); // Clear the storage
};

Here is an example showing how to store and how to read a string:

// save the string
function saveStatusLocally(txt) {
  window.localStorage.setItem("status", txt);
}
 
// read the string
function readStatus() {
   return window.localStorage.getItem("status");
}

Note that the storage properties are limited to an HTML5 origin (scheme + hostname + non-standard port). This means that window.localStorage from http://foo.com is a different instance of window.localStorage from http://bar.com. For example, http://google.com can’t access the storage of http://yahoo.com.

Are We Offline?

Before storing data, you may want to know if the user is online or not. This can be useful, for example, to decide whether to store a value locally (client side) or to send it to the server.

Check if the user is online with the navigator.onLine property.
In addition, you can be notified of any connectivity changes by listening to the online and offline events of the window element.

Here is a very simple piece of JavaScript code, which sends your status to a server (à la twitter).

• If you set your status and you’re online, it sends the status.
• If you set your status and you’re offline, it stores your status.
• If you go online and have a stored status, it sends the stored status.
• If you load the page, are online, and have a stored status, it sends the stored status.

function whatIsYourCurrentStatus() {
  var status = window.prompt("What is your current status?");
  if (!status) return;
  if (navigator.onLine) {
    sendToServer(status);
  } else {
    saveStatusLocally(status);
  }
}
 
function sendLocalStatus() {
  var status = readStatus();
  if (status) {
    sendToServer(status);
    window.localStorage.removeItem("status");
  }
}
 
 
window.addEventListener("load", function() {
   if (navigator.onLine) {
     sendLocalStatus();
   }
}, true);
 
window.addEventListener("online", function() {
  sendLocalStatus();
}, true);
 
window.addEventListener("offline", function() {
  alert("You're now offline. If you update your status, it will be sent when you go back online");
}, true);

Offline Resources: the Cache Manifest

When offline, a user’s browser can’t reach the server to get any files that might be needed. You can’t always count on the browser’s cache to include the needed resources because the user may have cleared the cache, for example. This is why you need to define explicitly which files must be stored so that all needed files and resources are available when the user goes offline: HTML, CSS, JavaScript files, and other resources like images and video.

The manifest file is specified in the HTML and contains the explicit list of files that should be cached for offline use by the application.

<html manifest="offline.manifest">

Here is an example of the contents of a manifest file:

CACHE MANIFEST
fonts/MarketingScript.ttf
css/main.css
css/fonts.css
img/face.gif
js/main.js
index.xhtml

The MIME-Type type of the manifest file must be: text/cache-manifest.

See the documentation for more details on the manifest file format and cache behavior.

Summary

The key components you should remember to think about when making your application work offline are to store the user inputs in localStorage, create a cache manifest file, and monitor connection changes.

Visit the Mozilla Developer Center for the complete documentation.

Thanks go out to Chris Howse for his design expertise, Craig Cook and Matt Harris for their development work, and everyone else that helped out.  What a difference a redesign like this can make:

Hacks v1.0

Chris Blizzard started the Hacks blog back in June 2009 as part of the “35 days of Firefox” campaign to give developers a look at the latest features and web technology upgrades that were coming in Firefox 3.5.  Since then, we have continued to reach out to web developers and collaborate with them to put together amazing posts.

With a collection of helpful tutorials, updates on web standards, and technology demos, Hacks has become a popular destination for anyone interested in keeping up with innovation on the web.  We cover a wide range of topics, including everything from new possibilities with HTML5 to the latest version of Firebug. Developers get to see what is possible on the web today, while everyone gets a glimpse of what the future holds for Firefox and the open web.

Hacks has ignited a renewed focus on web developer outreach and collaboration. In addition to the blog, you can follow us on Twitter, watch videos and demos on YouTube, and even subscribe to the about:hacks newsletter. Our goal is to inform and inspire web developers to help us establish a strong Mozilla Developer Network (MDN).

We have big plans for MDN in 2010, and Hacks v2.0 is just the beginning!  Enjoy the new website and please share your thoughts and feedback with us…

Happy New Year!

About:hacks will be published monthly, and will include demos, tutorials, Firefox release information, the latest on web standards and developer tools, and updates on the Mozilla Developer Network.

This first issue includes, among other things, a demo that combines Processing and multi-touch, an HTML5 video tutorial, a preview of Firebug 1.5 and Eventbug, and a sneak peek at what’s going on behind the scenes at Mozilla.

We know you may already be reading the hacks blog, following @mozhacks on Twitter, and maybe even subscribing to mozhacks on YouTube, so we’ll make sure the newsletter is a good mix of original content and a recap of some of the most important things that happened in the previous month.

This is why your feedback is very important: what did you like? what would you change? what would you like to see in the next issue? Let us know and we’ll make sure to write the newsletter you want to read!

If you haven’t seen about:hacks, check it out, and if you like it, subscribe to get the next issue in January.

He’s mostly upset that browsers don’t respect the autobuffer attribute. Or, really, that browsers autobuffer by default. Safari and Chrome do apparently autobuffer by default, but he incorrectly says that Firefox does as well. Just to be clear: Firefox does not autobuffer by default, nor does it autoplay by default. I’m not sure how his testing led him to believe that it does, but I wrote up some examples to show that it does not. Here are three examples:

• Video test without the autobuffer attribute. (Load this first to avoid caching issues!)
• Video test with the autobuffer attibute.
• Video test with one of each.

The best way to test this is to load your favorite browser and clear its cache. Then load your favorite network monitor. Then load the page without the autobuffer attribute set. You can see how much bandwidth the browser is actually using via your external tool.

Of the browsers I tried, only Firefox gives useful feedback on how much is actually buffered as part of its native control set so you have to go to external tools to be able to tell what’s going on with anything else. If you load the page with two videos – one with autobuffer set and one without - you can mouse over them in Firefox and see how one has buffered and one hasn’t.

The video on that test page is pretty big – around 115mb – so you can really tell when it’s buffering even on a fast network.

Here’s what my testing shows:

• Safari for desktops downloads a lot of data. (I don’t have an iPhone so I can’t test that.)
• Chrome downloads a lot of data.
• Firefox loads a small amount of data and then stops.
• Update: According to Philip Jägenstedt, Opera will also do what Firefox does when they include open video support.

This is consistent with what I know about Safari. I talked with one of the Apple WebKit engineers a few months ago and he said that Safari for desktops buffered by default and said that Safari for mobile does not.

There might be some confusion because Firefox does make a couple of network requests when you include a video tag. This is done for two reasons:

• To get the first frame of the video and it’s size. It will only download a small part of the beginning of the video to get the first frame and then stop downloading.
• If your server supports byte range requests, it seeks to the end of the video to try and determine the duration of the video. If your server doesn’t support byterange requests, we don’t get the duration. (Ogg was originally designed as a format for streaming, not static files and as such doesn’t include duration information in the header of the file, although there is work underway to add this functionality.)

If you want to get a sense of how Firefox uses bandwidth, try this bandwidth test I wrote a few months ago. It uses a Firefox-only feature to read progress information on a video as it’s downloaded and give you a rough sense of the amount of bandwidth that particular video element is using. It shows a little traffic when you load the video and then shows how it starts using bandwidth once you press the play button.

But this shows that we understand John’s point of view and we made the decision not to auto buffer by default for the very reasons he points out.

Demo

If you’re running the latest beta of Firefox 3.6, check out our file upload demo.

Uploading

XMLHttpRequest will send a given file to the server as a binary array, so you first need to read the content of the file as a binary string, using the File API. Because both Drag and Drop and the input tag allow you to handle multiple files at once, you’ll need to create as many requests as there are files.

var reader = new FileReader();
reader.onload = function(e) {
  var bin = e.target.result;
  // bin is the binaryString
};
reader.readAsBinaryString(file);

Once the file is read, send it to the server with XMLHttpRequest:

var xhr = new XMLHttpRequest();
xhr.open("POST", "upload.php");
xhr.overrideMimeType('text/plain; charset=x-user-defined-binary');
xhr.sendAsBinary(bin);

You can choose to be notified when specific events, such as error, success, or abort, occur during the request (see the MDC documentation for more details).

Following the Upload Progress

The progress event provides the size of the uploaded portion of the binary content. This allows you to easily compute how much of the file has been uploaded.

Here’s an example showing the percentage of the file that has been uploaded so far:

xhr.upload.addEventListener("progress", function(e) {
  if (e.lengthComputable) {
    var percentage = Math.round((e.loaded * 100) / e.total);
    // do something
}, false);

Demo

If you’re running the latest Firefox 3.6 beta, check out our interactive demo of drag and drop. It showcases two technologies: the Drag and Drop API and the File API.

Drag and Drop Events

To use drag and drop, you first need to tell the browser that a given element can handle dropped objects and will respond to a drop action, using the dragover and drop events.

You also need to prevent the browser’s default behavior, which is to simply load the dropped object in the browser window.

dropzone.addEventListener("dragover", function(event) {
  event.preventDefault();
}, true);
dropzone.addEventListener("drop", function(event) {
  event.preventDefault();
  // Ready to do something with the dropped object
}, true);

You may also want to use the dragenter and dragleave events to be notified when a drag session starts or stops.

Your element is now ready to receive files with the drop event.

Manipulating the Files

On the drop event, you can access the files with the files property of the DataTransfer object:

dropzone.addEventListener("drop", function(event) {
  event.preventDefault();
  // Ready to do something with the dropped object
  var allTheFiles = event.dataTransfer.files;
  alert("You've just dropped " + allTheFiles.length + " files");
}, true);

Once you’ve accessed the files, the File API lets you do much more, like parsing files as a binary array, or displaying a preview of an image by reading the file as a DataURL.

Of course, you can still drag and drop data other than files (e.g. text, URLs, remote images …) using the drag and drop API.

For one thing, it means more developers can get involved in the evolution of WebGL. There’s a public mailing list set up, so that you can engage directly with members of the WebGL Working Group, as well as a web forum. It’s important to note that the specification is not yet finalized. Participation from the web community is essential towards finalizing the specification, which we hope to do in the first quarter of 2010.

It also means that there are implementations of the draft specification that you can begin to test. You can obtain a Firefox nightly that implements the WebGL draft specification, and can turn on WebGL support in that build by following these steps:

• Type “about:config” in your browser’s URL bar
• Do a search for “webgl” in the Filter field
• Double-click the “enabled_for_all_sites” preference to change it to “true”

Other browsers that support the draft WebGL specification are listed on the WebGL Wiki.

Now of course, this is hardware-accelerated 3D graphics in an early beta, and for now requires an OpenGL 2.0-capable GPU and drivers. In particular, most flavors of Intel’s integrated GPUs will not work straight out of the box (such as the GMA900/GMA950 often found in laptops). Developers who build nightly builds of the browser can induce software rendering using Mesa, and should check out Vlad’s blog post for doing this on Windows. Caveat emptor: building software rendering using Mesa into a Firefox nightly is likely to yield slower performance, and is only for the intrepid.

WebGL is a royalty-free, cross-platform API that brings OpenGL ES 2.0 to the web as a 3D drawing context within HTML5’s Canvas element, exposed as low-level interfaces within the Document Object Model.

Developers familiar with the Canvas 2D context will recognize that WebGL is another context for Canvas:

// get the canvas element in the DOM
var canvas = document.getElementById("canvas3D");
var gl = canvas.getContext("experimental-webgl");

Note that till the specification is finalized, the context is called experimental-webgl.

WebGL uses the OpenGL shading language, GLSL ES, and can be cleanly combined with other web content that is layered on top or underneath the 3D content. It is an emerging web standard, and is designed to be used with other parts of the web platform. The release of the draft specification is one step in bringing about a plugin free 3D API to the web, usable straight out of the box. People have already begun using it to create compelling libraries. Check out X3DOM, which is a JavaScript library using WebGL that allows users to author content in X3D. We expect developer ingenuity to surprise and awe us, as it always has.

References

• Review the WebGL draft specification
• Get involved! WebGL Homepage on Khronos
• Read articles and contribute on the WebGL Wiki
• A blog about learning WebGL
• Find 3D recipes in the learning WebGL Cookbook

The input tag

To let your user select a local file, use the input tag on your Web page. This will show the file picker to the user:

<input type="file"/>

In Firefox 3.6, the input tag has been expanded to support multiple files:

<input type="file" multiple=""/>

The user will still see the same file picker, but will be able to select more than one file.

The form tag

You can still use the classic form mechanism:

<form method="post" action="upload.php" enctype="multipart/form-data">
  <input name='uploads[]' type="file" multiple=""/>
  <input type="submit" value="Send">
</form>

If the server side code is in PHP, don’t forget to make sure that the value of the name attribute has brackets. The brackets are not from the HTML specification, but are required to manipulate the result of the request as an array (see PHP documentation).

Here’s an example, which goes through the file list and prints each file name:

foreach ($_FILES['uploads']['name'] as $filename) {
    echo '<li>' . $filename . '</li>';
}

Using File API

Firefox 3.6 also supports FileAPI. This allows you to do extra processing on the client slide before sending the files to the server. You can access the selected files with the files property of the input DOM element and then manipulate the files using the FileAPI.

For example, here’s how to get the name of each file selected by the user. This is done on the client side, unlike the previous PHP example.

  var input = document.querySelector("input[type='file']");
  // You've selected input.files.length files
  for (var i = 0; i < input.files.length; i++) {
    // input.files[i] is a file object
    var li = document.createElement("li");
    li.innerHTML = input.files[i].name;
    ul.appendChild(li);
  }

Demo

See this mechanism in action in our multiple file input demo. You’ll need Firefox 3.6 (beta).

Documentation

To learn more about multiple file input, check out the documentation on MDC.

If you have the Firefox 3.6 beta, you can view the demo or you can just watch the video below.

It is important to note that even before the advent of the W3C File API draft (which only became a Working Draft in November 2009), Firefox 3 and later provide the ability to read files into memory synchronously but that capability should be considered deprecated in favor of the new implementation in Firefox 3.6 of the asynchronous File API. The deprecated API allowed you synchronously access a file:

// After obtaining a handle to a file
// access the file data
var dataURL = file.getAsDataURL();
img.src = dataURL;

While Firefox 3.6 will continue to support code usage of the sort above, it should be considered deprecated since it reads files synchronously on the main thread. For large files, this could result in blocking on the result of the read, which isn’t desirable. Moreover, the file object itself provides a method to read from it, rather than having a separate reader object. These considerations informed the technical direction of the new File API in Firefox 3.6 (and the direction of the specification). The rest of this article is about the newly introduced File API.

Accessing file selections

Firefox 3.6 supports multiple file selections on an input element, and returns all the files selected using the FileList interface. Previous versions of Firefox only supported one selection of a file using the input element. Additionally, the FileList interface is also exposed to the HTML5 Drag and Drop API as a property of the DataTransfer interface. Users can drag and drop multiple files to a drop target within a web page as well.

The following HTML spawns the standard file picker, with which you can select multiple files:

<input id="inputFiles" type="file" multiple="" />

Note that if you don’t use the multiple attribute, you only enable single file selection.

You can work with all the selected files obtained either through the file picker (using the input element) or through the DataTransfer object by iterating through the FileList:

var files = document.getElementById("inputFiles").files;
 
// or, for a drag event e:
// var dt = e.dataTransfer; var files = dt.files
 
for (var i = 0; i < files.length; i++) {
  var file = files[i];
  handleFile(file);
 
}

Properties of files

Once you obtain a reference to an individually selected file from a FileList, you get a File object, which has name, type, and size properties. Continuing with the code snippet above:

function handleFile(file) {
    // RegExp for JPEG mime type
    var imageType = /image\/jpeg/;
 
    // Check if match
    if (!file.type.match(imageType)) {
        return false;
    }
   // Check if the picture exceeds set limit
   if(file.size > maxSize) {
      alert("Choose a smaller photo!");
      return false;
   }
  // Add file name to page
  var picData = document.createTextNode(file.name);
  dataGrid.appendChild(picData);
  return true;
}

The size attribute is the file’s size, in bytes. The name attribute is the file’s name, without path information. The type attribute is an ASCII-encoded string in lower case representing the media type of the file, expressed as an RFC2046 MIME type. The type attribute in particular is useful in sniffing file type, as in the example above, where the script determines if the file in question is a JPEG file. If Firefox 3.6 cannot determine the file’s type, it will return the empty string.

Reading Files

Firefox 3.6 and beyond support the FileReader object to read file data asynchronously into memory, using event callbacks to mark progress. The object is instantiated in the standard way:

var binaryReader = new FileReader();

Event handler attributes are used to work with the result of the file read operation. For very large files, it is possible to watch for progress events as the file is being read into memory (using the onprogress event handler attribute to set the event handler function). This is useful in scenarios where the drives in question may not be local to the hardware, or if the file in question is particularly big.

The FileReader object supports three methods to read files into memory. Each allows programmatic access to the files data in a different format, though in practice only one read method should be called on a given FileReader object:

• filereader.readAsBinaryString(file); will asynchronously return a binary string with each byte represented by an integer in the range [0..255]. This is useful for binary manipulations of a file’s data, for example to look for ID3 tags in an MP3 file, or to look for EXIF data in a JPEG image.
• filereader.readAsText(file, encoding); will asynchronously return a string in the format solicited by the encoding parameter (for example encoding = "UTF-8"). This is useful for working with a text file, for example to parse an XML file.
• filereader.readAsDataURL(file); will asynchronously return a Data URL. Firefox 3.6 allows large URLs, and so this feature is particularly useful when a URL could help display media content in a web page, for example for image data, video data, or audio data.

An example helps tie this all together:

if (files.length > 0) {
    if (!handleFile(files[0])) {
        invalid.style.visibility="visible";
        invalid.msg = "Select a JPEG Image";
     }
}
 
var binaryReader = new FileReader();
binaryReader.onload = function(){
   var exif = findEXIFInJPG(binaryReader.result);
   if (!exif) {
      // ...set up conditions for lack of data
   }
   else {
    // ...write out exif data
   }
 
binaryReader.onprogress = updateProgress;
binaryReader.onerror = errorHandler;
 
binaryReader.readAsBinaryString(file);
 
function updateProgress(evt){
   // use lengthComputable, loaded, and total on ProgressEvent
   if (evt.lengthComputable) {
          var loaded = (evt.loaded / evt.total);
          if (loaded < 1) {
            // update progress meter
            progMeter.style.width = (loaded * 200) + "px";
          }
   }
}
 
function errorHandler(evt) {
  if(evt.target.error.code == evt.target.error.NOT_FOUND_ERR) {
   alert("File Not Found!");
  }
}

In order to work with binary data, the use of the charCodeAt function exposed on strings will be particularly useful. For instance, an utility of the sort:

function getByteAt(file, idx) {
    return file.charCodeAt(idx);
}

allows extraction of the Unicode value of the character at the given index.

An example of similar code in action in Firefox 3.6, including use of the readAsDataURL method to render an image, as well as binary analysis of a JPEG for EXIF detection (using the readAsBinaryString method), can be found in Paul Rouget’s great demo of the File API..

A word on the specification

The existence of a W3C public working draft of the File API holds the promise of other browsers implementing it shortly. Firefox 3.6’s implementation is fairly complete, but is missing some of the technology mentioned in the specification. Notably, the urn feature on the File object isn’t yet implemented, and neither is the ability to extract byte-ranges of files using the slice method. A synchronous way to read files isn’t yet implemented as part of Worker Threads. These features will come in future versions of Firefox.

References

• The W3C File API Specification
• MDC: Using files within web applications
• MDC: FileList
• MDC: File
• MDC: FileReader
• MDC: Drag and Drop

Custom Background Size

In Firefox 3.6, you can specify the size of a background image to scale it as a percentage of the element’s size, or to a specific length, using -moz-background-size.

-moz-background-size:  <bg-size>[, <bg-size>]*

Percentages. In this example, you can see the effect of setting a size using percentages. On the left, size is set to auto, which maintains the original size of the background image. In the center, size is set to 100%, which scales the background image to 100% of the area (horizontally), even if the original image was smaller than the background positioning area. On the right, size is set to 10%, which scales the image to 10% of the area. The background image is repeated by default.

 .bg_example_left {
  background: url(http://demos.hacks.mozilla.org/openweb/resources/images/logos/firefox-48.png);
  -moz-background-size: auto;
}
 .bg_example_center {
  background: url(http://demos.hacks.mozilla.org/openweb/resources/images/logos/firefox-48.png);
  -moz-background-size: 100%;
}
 .bg_example_right {
  background: url(http://demos.hacks.mozilla.org/openweb/resources/images/logos/firefox-48.png);
  -moz-background-size: 10%;
}

Here’s the same example (auto – 100% – 10%) using a different background image. In this case, the original is larger than the background area. As a result, specifying “auto” shows only a portion of the original, and you need to set a size of 100% to make the full image visible.

Horizontal and Vertical Scaling. It it possible to define a size for both horizontal and vertical scaling. Specifying only one size sets horizontal scaling (as in the examples above) and vertical defaults to “auto”. If a second size is specified, it is used for vertical scaling, as in the example below. On the left you can see an image with horizontal scaling of 100% and vertical defaulting to “auto”. On the right, horizontal is set to 100% and vertical is 30%, changing the original appearance of the image because of the change in proportions.

  -moz-background-size: 100%;
  -moz-background-size: 100% 30%;

Custom Size Demo. Try our interactive demo: select the size of a background on the fly. You’ll need the latest beta of Firefox 3.6.

Multiple Backgrounds

Firefox 3.6 also enables you to stack multiple backgrounds. This allows you to create cool effects by stacking a gradient on top of an image for example.

Defining. To define multiple backgrounds, simply list them as follows, using the background CSS property:

.foo {
  background: background1, background2, ..., backgroundN;
}

The order in which you list the backgrounds matters: the first in the list will appear as the top layer, the last one as the bottom layer.

Setting Properties. For multiple backgrounds, you can set the same properties you would for a single background, such as background-position or background-repeat. Define each background’s behavior by specifying a value for each property. The values need to be listed in the order in which you initially listed the backgrounds.

So if you defined:

  background: background1, background2, background3;

List the values in the same order for each property:

  background-position: background1_position, background2_position, background3_position;
  background-repeat: background1_repeat, background2_repeat, background3_repeat;

Example. Here’s how to stack three different backgrounds: the Firefox logo, a linear gradient, and an image with flowers. If you’re running Firefox 3.6 beta, you can turn on and off any or all of the three backgrounds in our interactive demo.

 .multi_bg_example {
  background: url(http://demos.hacks.mozilla.org/openweb/resources/images/logos/firefox-48.png), -moz-linear-gradient(left, rgba(255, 255, 255, 0),  rgba(255, 255, 255, 1)), url(http://demos.hacks.mozilla.org/openweb/resources/images/patterns/flowers-pattern.jpg);
  background-repeat: no-repeat, no-repeat, repeat;
  background-position: bottom right, left, right;
}