Monthly Archives: April 2011

Firefox Aurora: With Great Power Comes Great Freedom

This is a more detailed version of the article posted today on hacks, aimed at a more knowledgeable audience.

Aurora Logo
New features can only become stable and usable if you test them and push them to their limits. And you can only have fun playing with new features if it’s in a hassle- and risk-free way. You deserve better than a beta, you deserve Aurora.

What is Aurora?

Up to Firefox 4, Web authors only had limited options: either live in the quiet comfort of stable releases and wait months for new features to appear; or play Russian roulette with the nightly builds, exciting but painful. Beta releases aren’t filling the gap if we want to deliver features more often and increase their quality at the same time: we need more people to give us feedback and report bugs earlier. This implies to provide a safer environment to test features and a simpler way to switch to a more stable version of the browser (we call them channels).

Aurora is this safer environment.

6 Week Release Cycles!

New features added to Firefox are delivered on a daily basis through the nightly builds. Every six weeks, a new version of Aurora is delivered: it is roughly a nightly build, stripped of the features that are problematic or make Firefox unstable. During six weeks, Aurora will not be updated with new features, but will be updated with bug fixes on a daily basis. After six weeks, the features that are stable enough will land in the Beta channel, which receives weekly bug fixes. Another six weeks later, the features that are ready move from the Beta channel to the stable one: a new Firefox is born. The strictness of the quality control increases as features progress to later channels.

If you’re into fancy charts and technical details, have a look at the process specifics details. If you’re more into metaphors, think about the journey of a feature as the youth of a bird: engineers are our (free range) egg-laying chickens who want to see their features leave the nest, and you can help by watching over and taking care of the features during the gestation, brooding, rearing, and be as proud as we are to see them finally fly their own wings.

Switching between channels

Once you have downloaded and installed Aurora, you can switch to other channels at will. Simply click on the Help menu and open the About window.

Aurora About window

Firefox Aurora currently includes, amongst other nice improvements, CSS3 Animations, window.matchMedia and better tab-closing behavior. Give it a try and tell us what you think.

defaut display value of any DOM element

library authors have long been struggling to find a bullet proof function that will give the default display value of any DOM element. Average Web developer shouldn’t worry about it, but the solution had to be logged somewhere on the internet.

Consider the following kind of code:

The library used for animation will have to set the display value of the address to something else than none before animating it’s opacity from 0 to 1.

What should this display value be?

One way would be to use a hash object to store the default display value of elements:

var defaultDisplay = {
  div: "block",
  span: "inline",
  p: "block",
  b: "inline",
  td: "table-cell",
  ...
}

But this object would be rather large, considering the list of HTML5 elements. It can also be guaranteed that some day, other elements will be added to this list, and the library would be incompatible with it. The solution found in most libraries is similar to this one:

However, this function fails with the code found in the first snippet, as it will return “none” for any address, figcaption, mark or ruby inserted in this document, because that’s what the CSS says!

iframe to the rescue

In jQuery, we resorted to use an iframe to sandbox the dummy elements we create: the iframe hosts a completely different document, and the elements you append to it are not affected by the original CSS.

It should be noted that creating an iframe is a very expensive operation: on my 3 years old laptop running Firefox4 for Ubuntu, it takes up to 17ms to check the default display value of an element. This is mitigated by trying to use the classical code first (which executes in a fraction of that) and caching the output of the function.

navigator.onLine alternative: serverReachable()

Remy Sharp blogged recently about the issues of the navigator.onLine property and online/offline events. Let see how they can be worked around.

Getting the browser to handle it is hard

As it turns out, this property and those events can currently only be relied on to tell whether and when the user decides to turn on/off the “Work offline” feature of the browser. Indeed, some platforms have specific behaviors that make it hard for the browser to be constantly aware of the computer connectivity: Windows sometime incorrectly report its connectivity after waking up from hibernation, NetworkManager on Linux can’t be trusted because some users bypass it, etc.
This is why, as of Firefox4 and until we can find a reliable alternative, only the user can switch to offline mode.

What onLine doesn’t tell

If you are building a website with offline features, using this property to switch between online and offline mode might not be the best option. Not only can it incorrectly report the connectivity of the computer, but it also doesn’t tell anything about the actual reachability of the server: you might be connected to a network blacklisting the service; you might have no connection but be developing a website locally; or the server could be down…

In any case, it is probably more reliable to simply send a request to the server and fallback to local storage/resources/database when the request fails.

serverReachable()

Following is an example of code you can use to verify that the server is reachable

Improving the AppCache

Last week, Mark Christian & Dustin Diaz published AppCache Facts, a concise and pragmatic documentation about how to write a cache manifest to take your Web applications offline.

AppCache has the potential to benefit many websites, not only in offline scenarios but also on the performance ground. And yet, developers have struggled to use it in their projects because of the initial implementation quirks, the lack of documentation and tooling.

Now that the implementation and documentation parts are good enough, it’s time to get rid of the next papercuts. I gathered an initial list of those little things that could be fixed or improved to make the AppCache useful and convenient:

  • it should be possible to exclude the html file associated with the manifest from the cache,
  • it should be possible to cache resources from other origins on https too,
  • Firefox should stop asking for user permission and let developers see what’s in the AppCache.

What would you add to this list?
Leave a comment, and I’ll make sure the feedback is heard by Mozilla and Google engineers.