Articles for September 2011

Based on a blog post originally posted here by Nicholas Nethercote, Firefox Developer.

tl;dr
Firefox 7 now uses much less memory than previous versions: often 20% to 30% less, and sometimes as much as 50% less. This means that Firefox and the websites you use will be snappier, more responsive, and suffer fewer pauses. It also means that Firefox is less likely to crash or abort due to running out of memory.

These benefits are most noticeable if you do any of the following:
- keep Firefox open for a long time;
- have many tabs open at once, particularly tabs with many images;
- view web pages with large amounts of text;
- use Firefox on Windows
- use Firefox at the same time as other programs that use lots of memory.

Background
Mozilla engineers started an effort called MemShrink, the aim of which is to improve Firefox’s speed and stability by reducing its memory usage. A great deal of progress has been made, and thanks to Firefox’s faster development cycle, each improvement made will make its way into a final release in only 12–18 weeks. The newest update to Firefox is the first general release to benefit from MemShrink’s successes, and the benefits are significant.

Quantifying the improvements
Measuring memory usage is difficult: there are no standard benchmarks, there are several different metrics you can use, and memory usage varies enormously depending on what the browser is doing. Someone who usually has only a handful of tabs open will have an entirely different experience from someone who usually has hundreds of tabs open. (This latter case is not uncommon, by the way, even though the idea of anyone having that many tabs open triggers astonishment and disbelief in many people. E.g. see the comment threads here and here.)

Endurance tests
Dave Hunt and others have been using the MozMill add-on to perform “endurance tests“, where they open and close large numbers of websites and track memory usage in great detail. Dave recently performed an endurance test comparison of development versions of Firefox, repeatedly opening and closing pages from 100 widely used websites in 30 tabs.

[The following numbers were run while the most current version of Firefox was in Beta and capture the average and peak “resident” memory usage for each browser version over five runs of the tests. “Resident” memory usage is the amount of physical RAM that is being used by Firefox, and is thus arguably the best measure of real machine resources being used.]

The measurements varied significantly between runs. If we do a pair-wise comparison of runs, we see the following relative reductions in memory usage:

Minimum resident: 1.1% — 23.5% (median 6.6%)
Maximum resident: -3.5% — 17.9% (median 9.6%)
Average resident: 4.4% — 27.3% (median 20.0%)

The following two graphs showing how memory usage varied over time during Run 1 for each version. Firefox 6′s graph is first, with the latest version second. (Note: Compare only to the purple “resident” lines; the meaning of the green “explicit” line changed between the versions and so the two green lines cannot be sensibly compared.)
Firefox 7 is clearly much better; its graph is both lower and has less variation.

MemBench
Gregor Wagner has a memory stress test called MemBench. It opens 150 websites in succession, one per tab, with a 1.5 second gap between each site. The sites are mostly drawn from Alexa’s Top sites list. I ran this test on 64-bit builds of Firefox 6 and 7 on my Ubuntu Linux machine, which has 16GB of RAM. Each time, I let the stress test complete and then opened about:memory to get measurements for the peak resident usage. Then I hit the “Minimize memory usage” button in about:memory several times until the numbers stabilized again, and then re-measured the resident usage. (Hitting this button is not something normal users do, but it’s useful for testing purposes because causes Firefox to immediately free up memory that would be eventually freed when garbage collection runs.)

For Firefox 6, the peak resident usage was 2,028 MB and the final resident usage was 669 MB. For Firefox 7, the peak usage was 1,851 MB (a 8.7% reduction) and the final usage was 321 MB (a 52.0% reduction). This latter number clearly shows that fragmentation is a much smaller problem in Firefox 7.
(On a related note, Gregor recently measured cutting-edge development versions of Firefox and Google Chrome on MemBench.)

Conclusion
Obviously, these tests are synthetic and do not match exactly how users actually use Firefox. (Improved benchmarking is one thing we’re working on as part of MemShrink, but we’ve got a long way to go. ) Nonetheless, the basic operations (opening and closing web pages in tabs) are the same, and we expect the improvements in real usage will mirror improvements in the tests.

This means that users should see Firefox 7 using less memory than earlier versions — often 20% to 30% less, and sometimes as much as 50% less — though the improvements will depend on the exact workload. Indeed, we have had lots of feedback from early users that the latest Firefox update feels faster, is more responsive, has fewer pauses, and is generally more pleasant to use than previous versions.

Mozilla’s MemShrink efforts are continuing. The endurance test results above show that the Beta version of Firefox already has even better memory usage, and I expect we’ll continue to make further improvements as time goes on.

We have just released Aurora 9 (download and test Aurora 9), which is planned to be the upcoming Firefox 9. In it, we have a number of new things that we hope will get you excited!

Continued…

Today we’re releasing Firefox Update 7. This update contains work that’s been stabilizing over the last 3 months and there are quite a few interesting things to talk about.

To be clear, this is not the canonical list of changes, just highlights. As always, we’ve created a page to track the changes that web developers will care about. For the full list please see the Firefox 7 for developers page.

Firefox now supports text-overflow: ellipsis

Firefox now supports the ellipsis mode for the text-overflow property. This property is supported in other browsers which means developers should be able to start using it in the wild. Here’s an example of how text-overflow ellipsis works:

HTML:

<html>
<body>
      <div class="inner">I am some very long text!</div>
</body>
</html>

CSS:

div.inner {
    width: 120px;
    text-overflow: ellipsis;
    white-space:nowrap;
    overflow:hidden;
 
    color: red;
    border: 1px dashed #333;
    margin: 20px;
    padding: 10px;
}

Result:

As you can see, it’s pretty easy to make text that cuts off in a sane way with this new property. Our developer page for the property also contains sample syntax for other browsers.

WebSockets: Updated protocol and available on mobile

First, WebSockets is now enabled by default for Firefox for Mobile. For mobile networks that are high-latency and have high connection setup-up costs, WebSockets offers an opportunity to create a much better experience than is available with polling HTTP.

Second, we’ve updated to the most recent draft version of the WebSockets protocol from the IETF. Somewhat confusingly, this is version 8 of the protocol, but is draft version 10. This will be mostly of interest to people who are building applications on top of WebSockets and tool vendors, but is worth calling out since it affects backwards compatibility.

Since the WebSockets work is ongoing, the namespace for WebSockets remains moz-prefixed to indicate that it’s not yet finalized.

An even faster Canvas element

The canvas element in Firefox 7 is even faster. We’ve revised our code for Canvas based on what we learned in previous Firefox releases and how people are using Canvas in the wild. Based on that you are likely to see much snappier performance on many demos when drawing to canvas elements. For an example, see our Runfield demo.

Web sites can no longer resize your main browser window

It’s no longer possible for a web site to change the default size of a window in a browser, according to the following rules:

1. You can’t resize a window or tab that wasn’t created by window.open.
2. You can’t resize a window or tab when it’s in a window with more than one tab.

Support for the new Navigation Web Timing Spec

Firefox Update 7 now supports the Navigation Timing spec. This allows a web page author to monitor parts of web page performance in the page itself. For people who are interested in page load and navigation performance, they can send that back to the server which can give them a better view into real-world performance.

There are a couple of other specs in this space – the User Timing and Resource Timing – but those are still under discussion in working groups and as such we have not yet implemented them.

Based on a blog post originally posted here by Taras Glek, Firefox Developer.

Firefox 7 marks a turning point in how we measure Firefox performance. Traditionally we measured Firefox performance on individual developer machines and our build & release infrastructure. However it turns out synthetic benchmarks do not correspond to real-world Firefox usage: it is difficult to model a “typical” computer in a lab environment. Surprisingly slow consumer hardware, changes in usage patterns, preinstalled bloatware all affect Firefox performance in surprising ways.

Firefox 7 telemetry will prompt users to opt-in to reporting performance data to Mozilla. This data will supplement our existing benchmarking infrastructure to help us optimize future Firefox releases. Telemetry performance metrics are very lightweight and will not negatively impact Firefox performance.

In addition to transmitting data via SSL, Mozilla privacy team worked tirelessly to ensure that no personally-identifiable information is sent via telemetry. Whereas many other software projects stamp this kind of data with a unique per-user id, we opted for a per-session id which is reset every time the browser restarts. Telemetry is also disabled while in private-browsing mode.

The following telemetry data will be gathered in Firefox 7:

Memory usage
CPU core count
Cycle collection times
Startup speed

Use the about:telemetry extension to check on your browser performance. The following screenshot shows how to enable telemetry:

I’m very excited that Firefox finally joins the ranks of cars, airplanes and other software projects in making performance decisions based on real evidence gathered in the wild.

When writing of the hypnotic spiral demo the issue appeared that I wanted to use CSS animation when possible but have a fallback to rotate an element. As I didn’t want to rely on CSS animation I also considered it pointless to write it by hand but instead create it with JavaScript when the browser supports it. Here’s how that is done.

Testing for the support of animations means testing if the style attribute is supported:

var animation = false,
    animationstring = 'animation',
    keyframeprefix = '',
    domPrefixes = 'Webkit Moz O ms Khtml'.split(' '),
    pfx  = '';
 
if( elm.style.animationName ) { animation = true; }    
 
if( animation === false ) {
  for( var i = 0; i < domPrefixes.length; i++ ) {
    if( elm.style[ domPrefixes[i] + 'AnimationName' ] !== undefined ) {
      pfx = domPrefixes[ i ];
      animationstring = pfx + 'Animation';
      keyframeprefix = '-' + pfx.toLowerCase() + '-';
      animation = true;
      break;
    }
  }
}

[Update - the earlier code did not check if the browser supports animation without a prefix - this one does]

This checks if the browser supports animation without any prefixes. If it does, the animation string will be ‘animation’ and there is no need for any keyframe prefixes. If it doesn’t then we go through all the browser prefixes (to date :)) and check if there is a property on the style collection called browser prefix + AnimationName. If there is, the loop exits and we define the right animation string and keyframe prefix and set animation to true. On Firefox this will result in MozAnimation and -moz- and on Chrome in WebkitAnimation and -webkit- so on. This we can then use to create a new CSS animation in JavaScript. If none of the prefix checks return a supported style property we animate in an alternative fashion.

if( animation === false ) {
 
  // animate in JavaScript fallback
 
} else {
  elm.style[ animationstring ] = 'rotate 1s linear infinite';
 
  var keyframes = '@' + keyframeprefix + 'keyframes rotate { '+
                    'from {' + keyframeprefix + 'transform:rotate( 0deg ) }'+
                    'to {' + keyframeprefix + 'transform:rotate( 360deg ) }'+
                  '}';
 
  if( document.styleSheets && document.styleSheets.length ) {
 
      document.styleSheets[0].insertRule( keyframes, 0 );
 
  } else {
 
    var s = document.createElement( 'style' );
    s.innerHTML = keyframes;
    document.getElementsByTagName( 'head' )[ 0 ].appendChild( s );
 
  }
 
}

With the animation string defined we can set a (shortcut notation) animation on our element. Now, adding the keyframes is trickier. As they are not part of the original Animation but disconnected from it in the CSS syntax (to give them more flexibility and allow re-use) we can’t set them in JavaScript. Instead we need to write them out as a CSS string.

If there is already a style sheet applied to the document we add this keyframe definition string to that one, if there isn’t a style sheet available we create a new style block with our keyframe and add it to the document.

You can see the detection in action and a fallback JavaScript solution on JSFiddle:

Quite simple, but also a bit more complex than I originally thought. You can also dynamically detect and change current animations as this post by Wayne Pan and this demo by Joe Lambert explains but this also seems quite verbose.

I’d love to have a CSSAnimations collection for example where you could store different animations in JSON or as a string and have their name as the key. Right now, creating a new rule dynamically and adding it either to the document or append it to the ruleset seems to be the only cross-browser way. Thoughts?

I’m currently attending the Frontend Conference in Zurich, Switzerland and this morning I gave a presentation about mobile possibilities offered through CSS3 and HTML5.

Continued…

MindTouch, the developer of the software that powers the Mozilla Developer Network‘s documentation center, spent this week sponsoring a competitive battle, pitting MDN up against the Microsoft Developer Network (MSDN) site in the areas of user experience, social features, engagement, and findability. They offered their thoughts on the comparison between the two developer network sites in each of those categories, as well as overall, and then let their readers cast their votes on which they found superior in each area.

Today, MindTouch announced the result of their voting, and the Mozilla Developer Network site won in all categories (albeit by a slender margin in the “social” arena), as well as overall.

That serves as an affirmation that our open documentation model works, and works well. We have big plans for the future that will help make our content even better. Watch this space for news!

CSS animations are hot and a lot of experimentation is going on. A cool new feature of animations is the steps() option which allows you to cut an animation into steps instead of a transition from one state to another in one go. While this seems counterproductive on first glance there is a lot you can do with it.

Inspired by the making the perfect listing web site Lea Verou created a Pure CSS3 typing animation.

Which then inspired @simurai to use the steps() feature to create a sprite animation.

Especially the latter is very interesting as it allows for a scripted animation without JavaScript – remember when you had to re-animate GIFs in Photoshop and re-optimise them every time a client wanted them faster or slower?

For now the steps only divide the full length of the animation up. If you want different timings for different steps you still will need to create keyframes for each. Right now the steps feature works in Firefox and Webkit. Let’s hope others will follow, too.

Update 2011-09-09: Oh noes! We had a double dose of technical difficulties during this webinar. The BigBlueButton server froze and required a couple of reboots to get it working. It worked fine for the remainder of the session. Thanks to those who stuck around, and apologies to everyone for the problem.

On top of that, we had another recording failure. That is, we have a recording, but it has no audio. And as Remy demoed code rather than slides, there are no slides to share. We can post the recording if there’s interest, but it’s sadly lacking Remy’s narration. Double apologies for that.

Please join us on on Friday, September 9th at 16:00 UTC (convert to your local time), for a webinar on the Geolocation API, with Remy Sharp. Remy is well-known in web development circles, and was one of the first folks interviewed for our People of HTML5 series.

Geolocation is the topic for the September Dev Derby. Remy has indicated that this session will be light on slides and heavy on code, so get ready for some meaty stuff! Then whip up an awesome way to use geolocation and submit it to the Dev Derby.

Once again, we’re using BigBlueButton, thanks to Blindside Networks. (The recording issues with last month’s webinar were independent of BBB.)

Add this event to your calendar:

We’d like to get a rough estimate of how many people will be attending. If you happen to use Plancast and you expect to attend the webinar, please join the event on Plancast.

To join the webinar:

1. Go to the BigBlueButton server for Mozilla.
2. For Full Name, enter your name.
3. Select “Mozilla Developer Network” in the Room list.
4. For Password, enter MDNHacks.

Note: Big Blue Button uses Flash, so make sure you have the latest version installed, especially if you are running Mac OS X Lion.

We are planning to record the webinar and make it available for those who can’t attend to view later.