Articles for March 2010

For more information about this, have a look at David Baron’s post, the bug and the post on the security blog.

For many years the CSS :visited selector has been a vector for querying a user’s history. It’s not particularly dangerous by itself, but when it’s combined with getComputedStyle() in JavaScript it means that someone can walk through your history and figure out where you’ve been. And quickly – some tests show the ability to test 210,000 URLs per minute. At that rate, it’s possible to brute force a lot of your history or at least establish your identity through fingerprinting. Given that browsers often keep history for a long time it can reveal quite a bit about where you’ve been on the web.

At Mozilla we’re serious about protecting people’s privacy, so we’re going to fix this problem for our users. To do so we’re making changes to how :visited works in Firefox. We’re not sure what release this will be part of yet and the fixes are still making their way through code review, but we wanted to give a heads up to people as soon as we understood how we wanted to approach fixing this.

These changes will have some impact on web sites and developers, so you should be aware of them. At a high level here’s what’s changing:

• getComputedStyle (and similar functions like querySelector) will lie. They will always return values as if a user has never visited a site.
• You will still be able to visually style visited links, but you’re severely limited in what you can use. We’re limiting the CSS properties that can be used to style visited links to color, background-color, border-*-color, and outline-color and the color parts of the fill and stroke properties. For any other parts of the style for visited links, the style for unvisited links is used instead. In addition, for the list of properties you can change above, you won’t be able to set rgba() or hsla() colors or transparent on them.

These are pretty obvious cases that are used widely. There are a couple of subtle changes to how selectors work as well:

• If you use a sibling selector (combinator) like :visited + span then the span will be styled as if the link were unvisited.
• If you’re using nested link elements (rare) and the element being matched is different than the link whose presence in history is being tested, then the element will be drawn as if the link were unvisited as well.

These last two are somewhat confusing, and we’ll have examples of them up in a separate post.

The impact on web developers here should be minimal, and that’s part of our intent. But there are a couple of areas that will likely require changes to sites:

• If you’re using background images to style links and indicate if they are visited, that will no longer work.
• We won’t support CSS Transitions that related to visitedness. There isn’t that much CSS Transition content on the web, so this is unlikely to affect very many people, but it’s still worth noting as another vector we won’t support.

We’d like to hear more about how you’re using CSS :visited and what the impact will be on your site. If you see something that’s going to cause something to break, we’d like to at least get it documented. Please leave a comment here with more information so others can see it as well.

There have been a bunch of posts about the JägerMonkey (JM) post that we made the other day, some of which get things subtly wrong about the pieces of technology that are being used as part of Mozilla’s JM work. So here’s the super-quick overview of what we’re using, what the various parts do and where they came from:

1. SpiderMonkey.This is Mozilla’s core JavaScript Interpreter. This engine takes raw JavaScript and turns it into an intermediate bytecode. That bytecode is then interpreted. SpiderMonkey was responsible for all JavaScript handling in Firefox 3 and earlier. We continue to make improvements to this engine, as it’s still the basis for a lot of work that we did in Firefox 3.5, 3.6 and later releases as well.

2. Tracing. Tracing was added before Firefox 3.5 and was responsible for much of the big jump that we made in performance. (Although some of that was because we also improved the underlying SpiderMonkey engine as well.)

This is what we do to trace:

1. Monitor interpreted JavaScript code during execution looking for code paths that are used more than once.
2. When we find a piece of code that’s used more than once, optimize that code.
3. Take that optimized representation and assemble it to machine code and execute it.

What we’ve found since Firefox 3.5 is that when we’re in full tracing mode, we’re really really fast. We’re slow when we have to “fall back” to SpiderMonkey and interpret + record.

One difficult part of tracing is generating code that runs fast. This is done by a piece of code called Nanojit. Nanojit is a piece of code that was originally part of the Tamarin project. Mozilla isn’t using most of Tamarin for two reasons: 1. we’re not shipping ECMAScript 4 and 2. the interpreted part of Tamarin was much slower than SpiderMonkey. For Firefox 3.5 we took the best part – Nanojit – and bolted it to the back of SpiderMonkey instead.

Nanojit does two things: it takes a high-level representation of JavaScript and does optimization. It also includes an assembler to take that optimized representation and generate native code for machine-level execution.

Mozilla and Adobe continue to collaborate on Nanojit. Adobe uses Nanojit as part of their ActionScript VM.

3. Nitro Assembler. This is a piece of code that we’re taking from Apple’s version of webkit that generates native code for execution. The Nitro Assembler is very different than Nanojit. While Nanojit takes a high-level representation, does optimization and then generates code all the Nitro Assembler does is generate code. So it’s complex, low-level code, but it doesn’t do the same set of things that Nanojit does.

We’re using the Nitro assembler (along with a lot of other new code) to basically build what everyone else has – compiled JavaScript – and then we’re going to do what we did with Firefox 3.5 – bolt tracing onto the back of that. So we’ll hopefully have the best of all worlds: SpiderMonkey generating native code to execute like the other VMs with the ability to go onto trace for tight inner loops for even more performance.

I hope this helps to explain what bits of technology we’re using and how they fit into the overall picture of Firefox’s JS performance.

In August 2008, Mozilla introduced TraceMonkey. The new engine, which we shipped in Firefox 3.5, heralded a new era of performance to build the next generation of web browsers and web applications. Just after the introduction of our new engine Google introduced V8 with Chrome. Apple also introduced their own engine to use in Safari, and even Opera has a new engine that they’ve introduced with their latest browser beta.

As a direct result of these new engines we’ve started to see new types of applications start to emerge. People experimenting with bringing Processing to the web, people experimenting with real-time audio manipulation, games and many other things. (For some good examples have a look at our list of Canvas demos.)

We’ve learned two things at Mozilla about how our JavaScript engine interacts with these new applications:

1. That the approach that we’ve taken with tracing tends to interact poorly with certain styles of code. (That NES game example above, for example, tends to perform very badly in our engine – it’s essentially a giant switch statement.)
2. That when we’re able to “stay on trace” (more on this later) TraceMonkey wins against every other engine.

Mozilla’s engine is fundamentally different than every other engine: everyone else uses what’s called a “method-based JIT”. That is, they take all incoming JS code, compile it to machine code and then execute it. Firefox uses a “tracing JIT.” We interpret all incoming JS code and record as we’re interpreting it. When we detect a hot path, we turn that into machine code and then execute that inner part. (For more background on tracing, see this post on hacks from last year.)

The downside of the tracing JIT is that we have to switch back and forth between the interpreter and the machine code whenever we reach certain conditions. When we have to jump back from machine code to the interpreter this is what we call being “knocked off trace.” The interpreter is, of course, much slower than running native machine code. And it turns out that happens a lot – more than anyone expected.

So what we’re doing in our 2nd generation engine is to combine the best elements of both approaches:

1. We’re using some chunks of the WebKit JS engine and building a full-method JIT to execute JavaScript code. This should get us fast baseline JS performance like the other engines. And most important, it will be consistent – no more jumping on and off trace and spending a huge amount of time in interpreted code.
2. We’ll be bolting our tracing engine into the back of that machine code to generate super-fast code for inner loops. This means that we’ll be able to still have the advantages of a tracing engine with the consistency of the method-based JIT.

This work is still in the super-early stages, to the point where it’s not even worth demoing, but we thought it would be worth posting about so people understand the basics of what’s going on.

You can find more information about this on David Mandelin‘s and David Anderson‘s weblogs as well as the project page for the the new engine.

We’ve posted a new release of our Mozilla developer preview series as a way to test new features that we’re putting into the Mozilla platform. These features may or may not make it into a future Firefox release, either for desktops or for mobile phones. But that’s why we do these releases – to get testing and feedback early so we know how to treat them.

Note that this release does not contain two things that have gotten press recently: D2D or the new JavaScript VM work we’ve been doing.

Since this is a weblog focused on web developers, I think that it’s important to talk about what’s new for all of you. So we’ll jump right into that:

Out of Process Plugins

We did an a1 release about three weeks ago in order to get testing on some of the new web developer features (which we’ll list here again.) The biggest change between that release and this one is the inclusion of out of process plugins for Windows and Linux. (Mac is a little bit more work and we’re working on it as fast as our little fingers will type.)

There are a lot of plugins out there on the web, and they exist to varying degrees of quality. So we’re pushing plugins out of process so that when one of them crashes it doesn’t take the entire browser with it. (It also has lots of other nice side effects – we can better control memory usage, CPU usage and it also helps with general UI lag.)

If you want to know more about it, have a look at this post by Ben Smedberg who goes over how it works, what prefs you can set and how you can help test it. It would help us a lot of you did.

(If you really want to get on the testing train we strongly suggest you start running our nightly builds which are the ultimate in bleeding edge but are generally stable enough for daily use.)

Anyway, on to the feature list and performance improvements taken from the release announcement:

Web Developer Features

• Support for Content Security Policy. This is largely complete, minus the ability to disable eval().
• The placeholder attribute for <input/> and <textarea> is now supported.
• Support for SMIL Animation in SVG. Support for animating some SVG attributes is still under development and the animateMotion element isn’t supported yet.
• Support for CSS Transitions. This support is not quite complete: support for animation of transforms and gradients has not yet been implemented.
• Support for WebGL, which is disabled by default but can be enabled by changing a preference. See this blog post and this blog post for more details.
• Support for the getClientRects and getBoundingClientRect methods on Range objects. See bug 396392 for details.
• Support for the setCapture and releaseCapture methods on DOM elements. See bug 503943 for details.
• Support for the HTML5 History.pushState() and History.replaceState() methods and the popstate event. See bug 500328 for details.
• Support for the -moz-image-rect() value for background-image. See bug 113577 for more details.

For the full list of new web developer features please visit our page on Upcoming Features for Web Developers.

Performance Improvements

• We’ve removed link history lookup from the main thread and made it asynchronous. This results in less I/O during page loads and improves overall browser responsiveness.
• Loading the HTML5 spec no longer causes very long browser pauses.
• A large number of layout performance improvements have been made, including work around DOM access times, color management performance, text area improvements and many other hot spots in the layout engine.
• The JavaScript engine has many improvements: String handling is improved, faster closures, some support for recursion in TraceMonkey to name a few.
• Improvements to the performance of repainting HTML in <foreignObject>.
• Strings are not copied between the main DOM code and web workers, improving performance for threaded JavaScript which moves large pieces of data between threads.

We are inviting developers to give us feedback through quarterly surveys so we can better understand your needs. Your feedback is crucial to help us build the best platform, tools, and content.

Last November, we asked web developers to take a 20 question survey to help build the Mozilla Developer Network (MDN). Thanks to the feedback from 5,054 developers reached via this blog, twitter, the Firefox 3.6 beta first run page, and word of mouth, we’ve drafted detailed plans for the MDN and we are now executing on them.

In this post, you will find our new survey. Please take it and keep the feedback coming.

We also want to share the results from the November survey.

New Survey: Firefox 3.6 and Firebug 1.5

Our March survey picks up from some of the themes we heard you say in the November survey. Many of you stressed the importance of development tools and expressed how it can be difficult to understand the Firefox development process and to give input. We designed this quarter’s (much shorter) survey specifically to ask for your feedback on Firefox 3.6 and on Firebug 1.5, both released in January.

Here’s where you can take this new survey. We would also be very thankful if you could help us spread the word about it.

November 09 Survey Results

Here are some results from the November 09 survey:

• Web developers’ technology preferences
• Browser usage
• Development tools: Firefox add-ons
• Development tools: others
• Learning more about the current Firefox development work
• Firefox feature requests
• Mozilla Developer Center comments
• Providing feedback to Mozilla
• Profiles of survey respondents

Web Developers’ Technology Preferences

Browser usage

“Firefox is a developer’s best friend”: it is most likely to be the first browser used by developers because it helps them be most productive. The combination of great tools (add-ons, in particular Firebug, but also the console) and standard compliance means that it’s faster to develop on Firefox first, then tweak the code to make sure it works everywhere. The open source nature of Firefox was also frequently cited as a reason to use it.

Here is a word cloud generated from the praise for Firefox (thanks to wordle.net).

Once a project is built, developers spend a lot of time testing their work in an average of 5 browsers. At the time of this survey (Nov 09), the top browsers tested for compatibility were Firefox 3.5, IE8, IE7, Chrome, and Safari. IE6 only came in 6th place with less than 50% of developers still testing against it. With more sites dropping support for IE6 each day, we expect this number to continue to decrease over time.

At home, developers used on average 2 browsers, with the majority (80%) using Firefox, and a smaller number using Chrome (38%), or Safari (27%).

A small portion of respondents (7%) mentioned Webkit browsers as a good alternative for development because of its speed and ease of use, of its standards implementation, and of the inspector tool, with the frequent caveat that it still felt too limited for complex projects.

On the other hand, Internet Explorer (in particular IE6) was seen as slowing down web innovation and wasting developers’ time unnecessarily.

Development Tools: Firefox Add-ons

Firefox web development add-ons are cited as invaluable tools for development work. In fact, add-ons are seen by some respondents as the main reason to use Firefox. However, some blame them for slowing down Firefox. If this is happening to you, consider investigating which add-on is causing an issue, or using multiple profiles, one for development work, and one for every day browsing.

While Firefox is often referred to as a developer’s best friend, Firebug is called “a must-have tool” and “essential”. Some even go as far as saying that “developing Websites without Firefox and Firebug is unimaginable” and “Firebug has changed the way I develop with CSS and Javascript.”
Firebug plugins FirePHP, Page Speed, and FireCookie were often mentioned as great complements.

In addition to Firebug, the most frequently praised add-ons were the Web Developer Toolbar and YSlow. Other add-ons mentioned include Live HTTP Headers, HttpFox, MeasureIt, ColorZilla, and GreaseMonkey.

We’re working on improving developer tools for Firefox, for more details and to join the conversation, see Johnathan Nightingale‘s post on this topic.

Development Tools: Others

Learning more about the current Firefox development work

The Hacks blog, @mozhacks twitter account, and about:hacks newsletter should be your primary sources of information for any Mozilla work that impacts web developers. However, if you wish to follow the Firefox development work even more closely, you can take a look at the list of current Firefox projects, test the latest developer preview, or even run the nightly builds.

Firefox Feature Requests

While there was much praise for Firefox throughout the survey responses, there were also many voices asking for performance and stability improvements. These improvements are currently under way, as you can see for example with the ongoing work on Firefox startup time and stability, and on JavaScript performance.

There were also many requests to continue implementing HTML5 and CSS3 features. You can already enjoy some of the new features by trying out the latest developer preview build.

Mozilla Developer Center Comments

The Mozilla Developer Center was highly praised in the open comments. It is perceived as a key resource for web developers, especially for JavaScript, CSS, and DOM documentation. There were also quite a few requests to improve the site’s organization and search, add tutorials, and enable forums and comments, among other things. These are all being addressed in building the MDN.

Providing Feedback to Mozilla

Some of the comments in the November survey pointed out that it can be difficult to find the right place to give feedback to Mozilla and know that you’ve been heard. There are actually many ways to do so:

In addition to the surveys we post, the Hacks team reads all comments on the hacks blog and all incoming tweets for @mozhacks. This is the best way for web developers to give feedback and ask questions. We’re here to help you and to relay your concerns to the appropriate team.

Besides Hacks, here are some of the other feedback channels at Mozilla:

• Hendrix is a general feedback form
• Reporter keeps track of sites flagged through “Report broken website” in the Firefox Help menu
• Bugzilla is the place to file specific issues or requests for improvement
• Mozilla also has many developer forums you can join

Profiles of Survey Respondents

We received responses from 119 countries.

Respondents worked in a variety of environments, but the majority were freelance developers, followed by in-house teams and agencies. Most worked both as front-end and back-end web developers.

An overwhelming majority of respondents learned the skills they use for their web development work on their own: most were self-taught online, but 2/3 also learned offline through books and conferences.

Many of the respondents are currently contributing to the Mozilla project by spreading the word about Mozilla, Firefox, or open standards, by running betas and nightly builds, and by supporting Firefox users. Many thanks for your participation!

This concludes the November survey results, we look forward to your comments to this post, and to your feedback on Firefox 3.6 and Firebug 1.5 through our new survey.