Mozilla Hacks - the Web developer blog » Christopher Blizzard

Introducing Aurora 9

Christopher Blizzard — Fri, 30 Sep 2011 22:22:45 +0000

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!

JavaScript Type Inference

We’ve improved JavaScript performance once again with type inference. We’ve made significant improvements on both the V8 and Kraken benchmarks, and you should see real-world improvements to JavaScript performance as well.

JavaScript Interface for Do Not Track

Firefox 4 introduced Do Not Track, and now there is a way to detect a users’prefence through JavaScript as well:

mouseenter and mouseleave events

For some time now, web developers have been struggling with handling mouseover and mouseout events on elements, since when child elements have gained focus, the event has bubbled up and triggered mouseout on the parent element – something you would in most cases not like to happen.

Therefore, we are now happy to introduce support for mouseenter and mouseleave events:

Camera UI for Mobile

You can now use an input element to trigger a native app to take pictures. Please try the Camera UI for Mobile demo.

Support for chunked XMLHttpRequest

When doing XMLHttpRequest requests with large data sets, you can now get partial data as it arrives instead of waiting for it all to show up. You can use this to build more responsive and more efficient web sites.

Other changes

We’ve also got support for a bunch of other changes as well. These will be added to the Firefox 9 for Developers page over the next few weeks.

What’s new for Web Developers in Firefox 7

Christopher Blizzard — Tue, 27 Sep 2011 14:30:22 +0000

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:



      I am some very long text!

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:

You can’t resize a window or tab that wasn’t created by window.open.
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.

Firefox 4 Beta 9 – a huge pile of awesome

Christopher Blizzard — Fri, 14 Jan 2011 18:47:06 +0000

Hello, and welcome to the post for Firefox 4 beta 9. If you’re reading this then you’re interested in what we’ve got coming down the pipe for the latest beta for the wonderful browser known as Firefox 4. We’re starting to reach the end of our development cycle for the next release of Firefox and I thought it might be worth it to give a full overview of everything that we’ve got in store for web developers vs. Firefox 3.6. So if you’ve read previous releases, some of this will look familiar. But this is a new beta and we’ve been busy, so there’s something new in here for everyone.

Performance

One of Firefox 4′s main themes is Performance. As such, we’ve done a huge amount of work to improve browser performance across the board, from startup time, to JavaScript performance, to interactive performance and making the user interface easier and more efficient to drive. That being said, here are some of the things we’ve done to improve performance up to Beta 9.

The JaegerMonkey has landed.

And you might have noticed that it’s really fast. This is the world’s first third-generation JavaScript engine, using Baseline JIT technology similar to engines found in other browsers and kicked up a level with the Tracing engine found in Firefox 3.6. As such, we’re competitive on benchmarks such as Sunspider and V8, but we’re also fast at a whole mess of things that we expect to see in the set of next-generation web applications, hence Kraken.

Hardware Acceleration

Firefox 4 supports full hardware acceleration on Windows 7 and Windows Vista via a combination of D2D, DX9 and DX10. This allows us to accelerate everything from Canvas drawing to video rendering. Windows XP users will also enjoy hardware acceleration for many operations because we’re using our new Layers infrastructure along with DX9. And, of course, OSX users have excellent OpenGL support, so we’ve got that covered as well.

Compartments

Compartments, added in Beta 7, is infrastructure that we’ve added to Firefox to improve performance, give us a better base for security and, over the long term, give us better responsiveness because of its positive effects on garbage collection. (Note that there are some parts of Compartments that still have not landed.) If you want to learn about why Compartments are so important, have a look at Andreas Gal’s great post on the topic. He does a great job of explaining what they are and how they work.

Improved DOM performance and style resolution

We’ve made a huge number of improvements to our overall DOM and style resolution performance as well. Although JavaScript gets much of the focus these days, it turns out that in page load and interactive performance, the DOM and style resolution (usually as part of reflowing a document) often affect page performance more than JavaScript. And as such we’ve seen improvement across the board in this area with Firefox 4. In some tests we’re a solid 2x faster than Firefox 3.6.

JavaScript typed arrays

If you’re doing processing with JavaScript and you want to process low-level data, Firefox now supports native typed arrays in JavaScript. This can make a gigantic difference in how fast items are processed if you’re doing WebGL or image manipulation.

In addition, if you’re getting data from an XHR request, you can get that data as a JavaScript native typed array for fast processing with mozResponseArrayBuffer.

JavaScript animation scheduling APIs

We now support events that let you schedule animations from JavaScript. Doing this means you aren’t wasting CPU and battery by running your animations as fast as possible when the underlying rendering engine isn’t going to draw them anyway. (Gecko now has an internal timer for all drawing and will render at a maximum of 60fps, the edge of human perception. It will also turn this timer down to 1fps for tabs that aren’t in the foreground. Use it.) This is most useful for people building libraries, but you should be aware that there’s a better way to animate in Gecko.

Retained layers

As mentioned above, Firefox now has an internal Layers system for improved drawing performance for many types of web pages. Images, fixed backgrounds, inline video, etc. are now rendered to an internal layer and then composited with other parts of a web page in a way that can take advantage of hardware acceleration. This improves the page load time and interactive performance of many web pages.

Asynchronous plug-in painting

On Windows and Linux we now paint plug-ins asynchronously. In previous releases when we wanted to paint a web page that included a plug-in, we would have to ask the plug-in for the data to paint. If a plug-in was slow or was hung, it would make the browser feel slow. Now we’re able to get that data asynchronously, which means that the overall responsiveness of the browser should be improved.

Vastly improved cache

Firefox 4 has a vastly improved disk cache. This disk cache should result in faster start-up performance and runtime performance. But why mention this here? Our expectation is that site owners should see much higher cache hit rates with Firefox 4 as we dynamically set the cache size based on how much space is free on an end-user’s hard drive.

WebGL

Firefox 4 now has WebGL enabled by default. Based on the original 3-D Canvas work by Vladimir Vukićević, this is being widely implemented in browsers. The WebGL spec is on the short path to a 1.0 release and we’re very excited to see this be used in the wild.

Want a demo? Try the amazing Flight of the Navigator where we combine WebGL with a number of other technologies in Firefox 4 — HTML5 video, the Audio API, all remixed with live data from the web.

JavaScript

The new JaegerMonkey engine in Firefox 4 isn’t just faster, it’s also got some new tricks as well. Our goal is to bring new tools to developers and that includes evolving the JavaScript language. Here are two examples of where we’ve made other improvements:

ECMAScript 5

Firefox 4 Beta 9 contains much of the new version of the JavaScript language. Our goal with Firefox 4 is to have industry-leading support for ECMAScript 5, including the new strict mode. You can track our progress on the ES5 bug.

Web Console

Firefox 4 will include the Web Console. This is a new tool that will let you inspect a web page as it’s running, see network activity, see messages logged with console.log, see warnings for a page’s CSS, and a number of other things.

Note this that is something that we’ll be including with Firefox 4 directly. It’s not an add-on.

(Also Firebug will be ready for the final Firefox 4 release.)

HTML5

Firefox has always had excellent support for HTML5, even as far back as Firefox 3.5. Firefox 4 builds on that history with a bunch of new HTML5-related features.

Forms

We’ve started to implement much of HTML5 forms. We include support for new input types, datalist support, new input attributes like autofocus and placeholder, decoupled forms, form options, validation mechanisms, constraint validation and new CSS selectors to bind them all together. There’s a great post up on the Hacks site covering our HTML5 forms support in Firefox 4. If you want more information, check it out.

Parser

Firefox 4 includes an HTML5-ready parser. This parser brings with it some new capabilities, most notably inline SVG, but also improves performance by running the parsing algorithm on its own processor. It also brings our parser algorithm closer to the standard and lays the foundation for consistent parsing across browsers.

Support for WebM

Firefox 4 includes support for WebM, the new royalty-free format for video on the web. It works on YouTube if you join their HTML5 beta. It also works with embedded YouTube videos if you use their new iframe embedding API. (Join the beta and see an example at the bottom of this post.)

Video Buffer API

We now support the buffered attribute for HTML5 video. This means it’s possible to give users an accurate measure of how much video has been buffered instead of having to guess from the download rate and your current position in the stream.

Video “preload” support

We’ve replaced the “autobuffer” attribute for HTML5 video with the new “preload” attribute. This attribute gives you much better control over how videos are pre-buffered if they are included on a page rather than the old on/off system that was included with Firefox 3.5.

History pushState and replaceState

Firefox 4 now supports the HTML5 pushState and replaceState history modification calls. These allow you to create or modify the browser navigation history. These are extremely useful for applications that might want to generate history entries using the hash after the URL (useful for HTML-based slides, for example.) Other sites have been using these APIs to hide history information so that site-internal navigation aids aren’t revealed as part of HTTP-referrers.

Audio sampling and generation API

Firefox 4 includes the Firefox Audio Data API. This API allows you read, modify and write data from audio and video elements. This is now being widely experimented with and people are building some very beautiful things with it.

DOM

Firefox 4 includes a bunch of new DOM functionality, in addition to the performance improvements I mentioned before.

Added support for .click() to the File upload control

You can now call .click() on a hidden File control in order to bring up the platform file upload widget. This means you don’t have to expose the (ugly) file upload control; instead you can build your own. If you combine this with the new File APIs and progress events and you’ve got a recipe for a very nice file upload experience.

Support for .slice in the File API

We now support the Blob API and the .slice APIs that come with it. This is useful for people who want to want to process small parts of an otherwise large File object from JavaScript. You no longer have to load the entire file into memory.

It’s also useful for people who want to reliably upload large files. With some server and JS code you can now split a large file into small sections and upload those chunks, including re-retrying failed sections, or even uploading several sections in parallel.

Support for File API URLs

We now support the .url attribute for the File API. This lets you take objects that you’ve gotten through the File API and use them for images, video, HTML or other URL-powered objects.

Touch and multi-touch events

Firefox 4 supports both touch and multi-touch events, exposed to the DOM. Support for this functionality is available on Windows 7 systems.

Detect click-to-touch

You can now tell if a mouse or finger generated an event with the mozInputSource property. This is useful with the touch and multi-touch events and makes it possible to build apps that treat touch and mouse input differently.

IndexedDB

Firefox 4 will include a super-early version of IndexedDB. This emerging standard for local storage is still undergoing change and will be private-prefixed until it’s stable. We have some early API docs on IndexedDB, but the spec and implementation we have in Firefox 4 have both changed since the docs were last updated. As we get closer to release time we’ll be updating the docs and talk more about the implementation. Meanwhile, you can read the IndexedDB primer for an overview of using the IndexedDB API.

FormData

Firefox 4 includes support for the new FormData object, which makes it easier to interact with HTML forms. It also enables some new capabilities, like making it easy to upload a file as part of a form accessed via the File API.

SVG Animation and SMIL

In Firefox 4 you can now animate SVG with SMIL.

SVG as Images and CSS backgrounds

You can now use SVG as the source of an tag. You can even animate them with SMIL. And you can also use SVGs as backgrounds in CSS.

Get a Canvas as a File object

Many people wanted a Canvas accessible as a file object for uploads and other purposes. You can now use the mozGetAsFile() method on a canvas and it will return an image file.

Resizable text areas

If you’ve been using a beta, you’ve noticed that text areas are now resizable by default. You can disable that with the new resize CSS property.

CSS

Firefox 4 includes a huge pile of new CSS properties and promotions from the private CSS namespace into the final namespace due to the maturation of some of the standards in this space.

CSS Transitions

Firefox 4 will include support for CSS Transitions. Since the spec is still early, these are still -moz prefixed extensions.

calc()

We now support an early version of calc private-namespaced as -moz-calc. This will let you use simple expressions anywhere you would normally want to use a length. This can make the CSS layout of pages much simpler. (No more divs for spacing!)

-moz-any()

We now support a new extremely useful CSS extension: -moz-any() selector grouping. This will be very useful in HTML5 contexts. Please read the post for more information.

-moz-element()

The -moz-element is an extension to the background-image property that lets you use any element as the background for another element. This is hugely useful & powerful and we hope that other browsers will adopt it as well.

-moz-placeholder()

The :-moz-placeholder allows you to change the attributes of background text that’s a placeholder in an HTML5 form. This allows you to change the color or other attribute of the text. This can be very useful if you’ve changed the style of the actual text box and you want the background text to match.

border-radius

The border-radius attribute is now supported, replacing the old -moz-border-radius attribute.

box-shadow

box-shadow has replaced -moz-box-shadow.

-moz-font-feature-settings

Firefox 4 will include support for exposing much more of the capabilities of TrueType fonts with the -moz-font-feature-settings property. It’s possible to take advantage of all kinds of font capabilities — kerning, ligatures, alternates, real small caps, and stylistic sets, to name just a few.

Consistent CSS units

We’ve changed our handling of pixel sizes to match Internet Explorer, Safari and Chrome so that 1 inch always equals 96 pixels. See Robert’s post for more information on these changes.

Support for a physical CSS unit

We’ve introduced a new CSS unit, mozmm for the rare instance where you actually want a physical size to be used. Once again, see Robert’s post for more information on this new unit.

device-pixel-ratio

Firefox now supports the -moz-device-pixel-ratio media query that gives you the number of device pixels per CSS pixel.

resize

As mentioned above, we now have a resize CSS property that lets you disable resizable input text areas.

-moz-tab-size

We now support the -moz-tab-size property that lets you specify the width in space characters of how to render a tab character (U+0009) when rendering text.

-moz-focusring

The new CSS pseudo-selector, -moz-focusring lets you specify the appearance of an element when it’s focused and it would have a focus ring drawn around it. Different operating systems have different conventions for when to draw a focus ring or not and this lets you control the look of form controls while keeping to platform conventions.

-moz-image-rect

The new -moz-image-rect lets you use a sub-rectangle of an image as part of a background or background-image.

Security

Last but not least, Firefox 4 supports a huge number of new security tools, useful for both users and web developers alike. Here’s a quick overview of the new technologies we’re delivering:

Content Security Policy

Content Security Policy (CSP) is a set of tools that web developers can use to help prevent a couple different classes of attacks. In particular, it offers tools to mitigate cross-site scripting attacks, click-jacking and packet sniffing attacks.

Another important piece of CSP is that when one of the rules is violated, Firefox can send back information about that violation to the web site, making it a useful canary to improve security for other browsers too.

X-Frame-Options

Firefox 4 now supports the X-Frame-Options header, one defense against clickjacking. This response header is supported by other browsers as well. (This was also delivered as part of a Firefox 3.6 update, but is worth calling out since it’s new since the original 3.6 release.)

HSTS (ForceTLS)

Firefox 4 supports the obtusely-named HTTP Strict Transport Security (HSTS) headers. You can use these headers to tell the browser that it should never, ever contact a site over unencrypted HTTP.

Firefox users can also use the STS UI add-on to add and remove sites from the HSTS list, even sites that don’t natively support HSTS.

CORS Improvements

We’ve fixed some bugs in our CORS implementation.

:visited changes

Firefox 4 includes the changes required to help improve your privacy online by closing a decade-old hole in CSS rules that let any website query your browsing history. These changes have also been picked up by WebKit-based browsers and we’ve heard rumors that IE 9 might pick up this important change as well.

That’s a lot of stuff

Yes, it really is! We hope that you like it.

Fun With Fast JavaScript

Christopher Blizzard — Mon, 02 Aug 2010 19:07:47 +0000

This post is by Vladimir Vukićević and is a re-post from his personal weblog.

Fast JavaScript is a cornerstone of the modern web. In the past, application authors had to wait for browser developers to implement any complex functionality in the browser itself, so that they could access it from script code. Today, many of those functions can move straight into JavaScript itself. This has many advantages for application authors: there’s no need to wait for a new version of a browser before you can develop or ship your app, you can tailor the functionality to exactly what you need, and you can improve it directly (make it faster, higher quality, more precise, etc.).

Here are two examples that show off what can be done with the improved JS engine and capabilities that will be present in Firefox 4. The first example shows a simple web-based Darkroom that allows you to perform color correction on an image. The HTML+JS is around 700 lines of code, not counting jQuery. This is based on a demo that’s included with Google’s Native Client (NaCl) SDK; in that demo, the color correction work is done inside native code going through NaCl. That demo (originally presented as “too slow to run in JavaScript”) is a few thousand lines of code, and involves downloading and installing platform-specific compilers, multiple steps to test/deploy code, and installing a plugin on the browser side.

I get about 15-16 frames per second with the default zoomed out image (around 5 million pixels per second — that number won’t be affected by image size) on my MacBook Pro, which is definitely fast enough for live manipulation. The algorithm could be tightened up to make this faster still. Further optimizations to the JS engine could help here as well; for example, I noticed that we spend a lot of time doing floating point to integer conversions for writing the computed pixels back to the display canvas, due to how the canvas API specifies image data handling.

The Web Darkroom tool also supports drag & drop, so you can take any image from your computer and drop it onto the canvas to load it. A long (long!) time ago, back in 2006, I wrote an addon called “Croppr!”. It was intended to be used with Flickr, allowing users to play around with custom crops of any image, and then leave crop suggestions in comments to be viewed using Croppr. It almost certainly doesn’t work any more, but it would be neat to update it: this time with both cropping and color correction. Someone with the addon (perhaps a Jetpack now!) could then visit a Flickr photo and experiment, and leave suggestions for the photographer.

The second example is based on some work that Dave Humphrey and others have been doing to bring audio manipulation to the web platform. Originally, their spec included a pre-computed FFT with each audio frame delivered to the web app. I suggested that there’s no need for this — while a FFT is useful for some applications, for others it would be wasted work. Those apps that want a FFT could implement one in JS. Some benchmark numbers backed this up — using the typed arrays originally created for WebGL, computing an FFT in JS was approaching the speed of native code. Again, both could be sped up (perhaps using SSE2 or something like Mono.Simd on the JS side), but it’s fast enough to be useful already.

The demo shows this in action. A numeric benchmark isn’t really all that interesting, so instead I take a video clip, and as it’s playing, I extract a portion of the green channel of each frame and compute its 2D FFT, which is then displayed. The original clip plays at 24 frames per second, so that’s the upper bound of this demo. Using Float32 typed arrays, the computation and playback proceeds at around 22-24fps for me.

You can grab the video controls and scrub to a specific frame. (The frame rate calculation is only correct while the video is playing normally, not while you’re scrubbing.) The video source uses Theora, so you’ll need a browser that can play Theora content. (I didn’t have a similar clip that uses WebM, or I could have used that.)

These examples are demonstrating the strength of the trace-based JIT technique that Firefox has used for accelerating JavaScript since Firefox 3.5. However, not all code can see such dramatic speedups from that type of acceleration. Because of that, we’ll be including a full method-based JIT for Firefox 4 (for more details, see David Anderson’s blog, as well as David Mandelin’s blog). This will provide significantly faster baseline JS performance, with the trace JIT becoming a turbocharger for code that it would naturally apply to.

Combining fast JavaScript performance alongside new web platform technologies such as WebGL and Audio will make for some pretty exciting web apps, and I’m looking forward to seeing what developers do with them!

Edit: Made some last-minute changes to the demos, which ended up pulling in a slightly broken version of jQuery UI that wasn’t all that happy with Safari. Should be fixed now!

Brendan Eich at JSConf 2010 – what’s coming in ECMAScript 5 and more

Christopher Blizzard — Mon, 19 Jul 2010 17:28:19 +0000

Note: We at Mozilla wholeheartedly approve of Brendan’s use of Bruce Campbell.

Firefox 4 – FormData and the new File.url object

Christopher Blizzard — Thu, 08 Jul 2010 01:58:20 +0000

This is a guest post from Jonas Sicking, who does much of the work inside of Gecko on content facing features. He covers FormData, which we’ve talked about before, but shows how it can connect to an important part of the File API we’ve added for Firefox 4: File.url.

In Firefox 4 we’re continuing to add support for easier and better file handling. Two features that are available in Firefox 4 Beta 1 are File.url and FormData. In this post I’ll give a short introduction to both of them.

Starting with Firefox 3.6 we supported a standardized way of reading files using the FileReader object. This object allowed you to read the contents of a file into memory to analyze its content or display the contents to the user. For example to display a preview of an image to a user, you could use the following script

var reader = new FileReader();
reader.onload = function() {
  previewImage.src = reader.result;
}
reader.readAsDataURL(myFile);

There are two unfortunate things to note here. First of all, reader.result is a data url which contains the whole contents of the file. I.e. the full file contents is kept in memory. Not only that, data urls are often base64 encoded, and each base64 encoded character is stored in a javascript character, which generally uses 2 bytes of memory. The result is that if the above code is used to read a 10MB image file, reader.result is a 26.7MB large string.

The other unfortunate thing is that the above code is somewhat complicated since it needs to use asynchronous events to read from disk.

In Firefox 4 Beta 1 you can instead use the following code

previewImage.src = myFile.url;

This uses the File.url property defined by the File API specification. The property returns a short, about 40 characters, url. The contents of this url you generally won’t have to care about, but for the interested it contains a randomly generated identifier prefixed by a special scheme.

This can url can then be used anywhere where generic urls are used, and reading from that url directly reads from the file. The example above makes the image element read directly from the file and display the resulting image to the user. The load works just like when loading from a http url, normal ‘load’ events and ‘error’ events are fired as appropriate.

You can also display HTML files by using an and setting its src to the value returned by File.url. However you have to watch out for that relative url in the HTML file won’t work as the relative urls are resolved against the generated url returned from File.url. This is intentional as the user might have only granted access to the HTML file, and not to the image files.

Other places where this URL can be useful is for CSS background images, to set the background of an element to use a local file. Or even read from the url using XMLHttpRequest if you have existing code that uses XMLHttpRequest and which you don’t want to convert to use FileReader.

The other feature that we are supporting in Firefox 4 Beta 1 is the FormData object. This object is useful if you have existing server infrastructure for receiving files which uses multipart/form-data encoding.

In Firefox 3.6, sending a file to a server using multipart/form-data encoding using XMLHttpRequest required a a bit of manual work. You had to use a FileReader to read the contents of the file into memory, then manually multipart/form-data encode it, and then finally send it to a server. This both required more code, as well as required that the whole file contents was read into memory.

In Firefox 4, you’ll be able to use the FormData object from the XMLHttpRequest Level 2 specification. This allows the following clean code

var fd = new FormData();
fd.append("fileField", myFile);
var xhr = new XMLHttpRequest();
xhr.open("POST", "file_handler.php");
xhr.send(fd);

This will automatically multipart/form-data encode the file and send it to the server. The contents of the file is read in small chunks and thus doesn’t use any significant amounts of memory. It will send the same contents as a form with the following markup:

<form enctype="multipart/form-data" method="post">
  <input type="file" name="fileField">
</form>

If you want to send multiple files, simply call fd.append for each file you want to submit and the files will all be sent in a single request. You can of course still use the normal progress events, both for upload and download progress, that XMLHttpRequest always supplies.

However FormData also has another nice feature. You can also send normal, non-file, multipart/form-data values. For example

var fd = new FormData();
fd.append("author", "Jonas Sicking");
fd.append("name", "New File APIs");
fd.append("attachment1", file1);
fd.append("attachment2", file2);
var xhr = new XMLHttpRequest();
xhr.open("POST", "file_handler.php");
xhr.send(fd);

You can even get a FormData object which contains all the information from a

Firefox 4 beta 1 is here – what’s in it for web developers?

Christopher Blizzard — Thu, 01 Jul 2010 22:33:14 +0000

Today we’re releasing the first beta-quality version of Firefox 4, which starts us down the path to a final release of Firefox 4. We’re handling this beta differently than we’ve done other releases. In previous betas we’ve made milestone-like releases. For this beta we’ll be making more frequent updates during the beta program. So if you download the beta build and run it you’ll likely get updates every two to three weeks, instead of a couple of months apart. We believe that this will give us the ability to reply to people’s feedback quickly and get fixes and changes tested earlier. This, in turn, will mean we’ll be able to release a much higher quality browser as a result.

First, let’s talk about feedback. This beta includes two ways to give us feedback.

The Feedback Button – Pictured above and included with the beta is a Feedback Add-on. This puts a big Feedback button on the right hand side of the browser that lets you give quick and easy feedback about something you like or something you don’t. We’ll be reviewing this feedback through the beta process, so please leave comments. The Add-On also uses Test Pilot to figure out how people use the browser – menus, how people use passwords, etc. But through this beta process we’ll also be using it to measure things like platform performance and other interesting data we need to build a great browser. Just like Test Pilot, no data will be collected without you knowing about it, you’ll always be asked before any collected data is sent from your computer to Mozilla, and that data will be subject to very strict privacy policies.

If you’re a web developer the beta process will be especially valuable. There are a lot of new features in Firefox 4.0b1 that weren’t in 3.6 – which we’ll go over – but we’ll keep adding and fixing features throughout the beta process and your feedback will be incredibly important. So please take the time to download the beta and try it. Run it all the time, if you can, and watch it change over time.

Performance

Firefox 4 contains a large number of performance improvements over Firefox 3.6. As a web developer you’re likely to notice big improvements in overall performance.

DOM and Style Performance – We’ve made huge improvements in our DOM and style resolution engine, meaning that pages that have complex CSS rules and selector matching will generally work faster and better. (On some tests in the Zimbra performance test suite we’ve seen a solid 2x improvement.)

Reduced IO in the page load path – One big area where we’ve made huge improvements in Firefox 4 vs. 3.6 is the removal of tons of I/O from the main UI thread. This means making sure that when we do history look-ups for coloring links based on browser history, that those look-ups are done off the main thread, to making sure that we’re not synchronously writing data to the HTTP cache on the main thread. This alone has improved the overall feel of the browser more than anything else.

JavaScript – The JavaScript engine is much faster as well, although beta 1 does not include the new JägerMonkey work. That work is well underway and will be landing through the beta process, and is already showing positive results.

Hardware Acceleration via Layers – We’ve also got excellent support in this beta for Hardware Acceleration. If you’re using HTML5 video and you go full screen, we’ll use OpenGL on Macs or Linux and DirectX 9 on Windows to accelerate video rendering. (As we expand our Gecko Layers work we’ll also be extending this acceleration to in-page content where it makes sense.)

Hardware Acceleration via D2D If you’re on Windows 7 or an updated Windows Vista we also have full support for D2D-enabled rendering. This can be a substantial performance improvement for many types of rendering and is also something the IE team is also doing for IE9. It’s not on by default in this beta but you can easily turn it on and try it out. The best demos that we’ve seen for D2D support are actually the IE Flying Images and the IE Flickr Explorer demo. Firefox actually performs wonderfully on these demos, better than the IE9 builds in most cases.

Out of process plugins – even for the Mac – We already delivered out of process plugins to Windows and Linux users using 3.6 a couple of weeks ago, but it’s now available on OSX as well. Moving plugins out of process improves stability, responsiveness and memory consumption. For OSX we have support for running Flash 10.1 out of process on OSX 10.6. (It requires support from 10.6 and changes to the event models for both Firefox and individual plugins.)

HTML5 support

Firefox has had early and excellent support for HTML5 and the beta release continues to build on that history.

HTML5 Forms – We’ve started to land support for many HTML5 forms. We’ll be landing more HTML5 form features during the beta process opportunistically depending on pretty tough shipping criteria.

HTML5 Sections – We now support HTML5 sections like

,

, ,

and

.

WebSockets – This release includes support for WebSockets, based on version -76 of the spec.

HTML5 History – We’ve also got support for the new HTML5 history items: pushState and replaceState. These are very important calls that make it easier to build pages-as-applications and can also be very important for improving privacy as you move from site to site.

HTML5 Parser – We’re also the first browser to fully support the HTML5 parsing algorithm, one of the most important parts of the HTML5 spec. The parser allows us to embed SVG and MathML directly into HTML content, but also promises developers the ability to have the same behaviour in different browsers, even when developers make mistakes in their mark-up. Our hope is that other browsers will follow us on this work since it’s one of the biggest interoperability parts of the HTML5 specification and will really help developers.

And, of course, we have support for HTML5 Canvas (including D2D hardware acceleration), Video and a huge pile of other HTML5 technologies.

HTML5 Video

WebM Support – The biggest change here so far is that we’ve got support for WebM. If you’re part of the Youtube HTML5 beta WebM videos should play pretty well.

Other, upcoming interfaces – Note that through the beta process we’ll also be adding support for a JavaScript-driven full screen API for video, support for the buffered attribute and be renaming the autobuffer attribute to preload.

Storage and File API

IndexedDB – Firefox 4 beta 1 also includes a super-early snapshot of the new IndexedDB standard for storage. Due to the fast pace in changes in the standard, the object is available on the privately-namespaced window.moz_indexedDB object. This is a pretty complex item, and we’ll have more posts on it soon.

URI Support for the File API – We’ve also early support for the URI support inside of the File API. This means that it’s possible to process large amounts of data like images or videos from the File API without having to load the entire file into memory. You should also be able to reference private File API URLs in image and video tags for preview or manipulation.

FormData – We also have support for the FormData method, which makes it much easier to send complex data from the File API and other sources to servers.

Animation and Graphics

SMIL – We’ve added support for SVG Animation (SMIL.) If you’re running a 4.0 beta there are a huge number of beautiful examples on this page by David Dailey worth looking through.

SVG Everywhere – Later in the Firefox beta release cycle we’ll also be adding support for SVG-as-img and SVG-as-CSS-background. Most of that work is done, but it hasn’t landed yet.

CSS Transitions – This beta release contains a nearly complete implementation of CSS Transitions, privately namespaced with a -moz prefix. The only big things left here are the animation of transforms and gradients. (Gradients is still waiting on working group feedback, code for transitions is under review.)

WebGL – This build also has improved support for WebGL, although it is not yet on by default. (You can learn how to turn it on in an older post from Vlad.) The WebGL spec is on its way to a 1.0 release and is being implemented in Chrome, Safari and Firefox. We would like to ship it in Firefox 4, but that decision will be based on spec stability as well as the availability of drivers. If you’re on a Mac WebGL should work very well. On Windows with ATI and NVIDIA drivers, it should also work very well. Windows people with Intel drivers are in less luck due to very poor driver support from Intel. (Including your author!) Linux is more complicated due to wildly varying driver support – people with NVIDIA drivers seem to work well, others less so, but work is underway to help fix many issues on Linux.

CSS

Resizable textarea Elements – Textarea elements are now resizable by default. You can use the -moz-resize property to change the default.

New -moz-any selector – The -moz-any is a powerful selector that lets you replace large and complicated selectors with much smaller ones. Please see the post for more examples.

New CSS3 calc() support – This beta includes support for the new CSS3 calc() value. This lets you specify sizes that include a combination of percentages and absolute values and is hugely popular with developers. Please see the post on CSS3 calc for examples.

Selecting a section of a background image – You can now use the new -moz-image-rect selector to select only a section of a background for display.

Removed support for -moz-background-size – The -moz-background-size property has been renamed to its final background-size name. -moz-background-size is no longer supported.

DOM and Events

CSS Touch Source on Input Events – You can now tell if an input event came from a mouse or touch with event.mozInputSource.

Obtaining boundary rectangles for ranges – The Range object now has getClientRects() and getBoundingClientRect() methods.

Capturing mouse events on arbitrary elements – Support for the Internet Explorer-originated setCapture() and releaseCapture() APIs has been added.

Support for document.onreadystatechange – We now support the document.onreadystatechange.

Security

Content Security Policy – This beta contains support for Content Security Policy. CSP allows you to control what the browser is allowed to do when loading content from your site. CSP is built to mitigate Cross-site Scripting Attacks and Cross Site Request Forgery. It also contains an automated reporting mechanism so that admins can get reports of problems that may affect other browsers.

In Closing

So that’s about it for the start of the Firefox 4 beta. We’ll be adding a few more features during the beta release process and we’ll post about is as they land. And we’ll also have more information coming about some of these features in depth. And, of course, we’ll continue to work on performance through the beta process as well. Please test and post comments if you have them here, or use the Feedback system in Firefox.

Enjoy!

HTML5 adoption stories: box.net and html5 drag and drop

Christopher Blizzard — Wed, 23 Jun 2010 15:46:12 +0000

This is a guest post from Tomas Barreto, a developer who works at box.net. They recently adopted HTML5 drag and drop as a way to share files with other people using new features in Firefox. The included video is a pitch for the feature and service, but shows how easy it is to do simple HTML5-based upload progress even with multiple files. Tomas gives an overview of the relatively simple JavaScript required to do this, and how improvements in Firefox 4 will make things even easier. Also have a quick look at the bottom of the post for links to additional docs and resources.

At Box.net, we’re always exploring new ways to help users get content quickly and securely onto our cloud content management platform. So when asked, “What feature would make you use Box more?” during the Box Hack Olympics in April, my colleague CJ and I decided to tackle the most intuitive way to upload files: simply dragging them from the desktop into Box.

We considered technologies ranging from Gears to Firefox plugins, but only HTML5 had sufficient adoption. By using some of the JavaScript APIs defined in the HTML5 standard, CJ and I could create a seamless drag and drop experience for our users on supporting browsers. Furthermore, using an HTML5-based upload feature would allow us to enable users to select multiple files at once, and also display progress on the client without polling. And with HTML5 adoption across the latest versions of three of the top four browsers, we felt confident about building an upload method based on this new technology without the trade-offs of using a third-party plug-in.

We rolled out the first rev of our drag and drop feature a few weeks ago, and we’re impressed with how quickly it has been adopted. It’s already one of the most popular ways to get files onto Box, and in its first week it surpassed our old AJAX upload method. You can check out our demo video to get a feel for the feature:

To build this feature, we referenced a handful of online examples that explained how to use Firefox 3 FileReader object and the drag and drop file event support. Our first implementation used this object to load the file into memory and then took advantage of the latest XMLHttpRequest events to track progress on the client.

var files = event.originalEvent.dataTransfer.files; // drop event
var reader = new FileReader();
 
reader.onload = function(event) {
  var file_contents = event.target.result;
  var request = new XMLHttpRequest();
 
  ... // attach event listeners to monitor progress and detect errors
 
  var post_body = '';
 
  .. // build post body
 
  post_body += file_contents;
 
  .. // finish post body
 
  var url = 'http://example.com/file_upload';
 
  var request = new XMLHttpRequest();
 
  request.open("POST",  url, true); // open asynchronous post request
  request.setRequestHeader('content-type', 'multipart/form-data; boundary=""'); // make sure to set a boundary
  request.send(post_body);
}
 
reader.readAsBinaryString(files[0]);

This approach worked well because we could use the same server processing code that we previously used for uploads. The main disadvantage here is that the FileReader object reads the entire file into memory, which is not optimal for a general upload use case. Our current HTML5 implementation uses this logic and has forced us to restrict drag and drop uploads to just 25mb. However, thanks to recommendations from the Mozilla team, we’ll be taking an alternative approach for V2 of drag and drop, where the file is read chunks as needed by the request. Here’s how we’re going to do it:

var files = event.originalEvent.dataTransfer.files; // drop event
var url = 'http://example.com/file_upload';
 
var request = new XMLHttpRequest();
request.open("POST",  url, true); // open asynchronous post request
request.send(files[0]);

Since this approach is not formatted as a multipart form-data, it will require some adjustments on our back-end to support receiving file uploads in this way. However, it’s definitely worth the trade-off since we’ll get all the benefits of the previous method and we don’t need special file size restrictions. In the future, we’ll consider using yet another way to efficiently upload files that is supported in Firefox 4 and uses the traditional multi-part form:

var files = event.originalEvent.dataTransfer.files; // drop event
var url = 'http://example.com/file_upload';
 
var request = new XMLHttpRequest();
 
var fd = new FormData;
fd.append("myFile", files[0]);
 
request.open("POST",  url, true); // open asynchronous post request
request.send(fd);

We’re already exploring more ways to enrich the Box experience using HTML5. With HTML5, we can build faster, richer and more interactive features with native browser support, and bridge the traditional gap between desktop software and web applications. Here are just a few cool new upload-related features on our roadmap:

Pause/Resume uploads using the Blob slice API to split files into chunks (this will be a huge robustness boost, especially for large uploads)
Allowing uploads to resume even after the browser closes by caching the file using IndexedDB support (possibly in Firefox 4)

We’d also like to begin a discussion about supporting the reverse drag and drop use case: dragging files from the browser to the desktop. Based on our users’ enthusiasm around the drag and drop upload feature, we think the reverse functionality would well received. If you are interested in contributing to a specification for this feature, please let us know (html5 [-at$] box.net)!

Resources:

upcoming changes to the viewport meta tag for firefox mobile

Christopher Blizzard — Thu, 27 May 2010 16:59:03 +0000

This is a guest post by Matt Brubeck who works on the Firefox Mobile team.

The upcoming release of Mobile Firefox (Fennec) 1.1 features improved
support for the tag. Previous version of Fennec supported the width, height, and initial-scale viewport properties, but had problems with some sites designed for iPhone and Android browsers. We now support the same properties Mobile Safari does, and we also changed Fennec to render mobile sites more consistently on screens of different sizes and resolutions.

touch.facebook.com before:

touch.facebook.com after:

You can see these changes for yourself in the latest Fennec 1.1 and trunk nightly builds for Maemo, Android, Windows, Mac, or Linux.

Background

Mobile browers like Fennec render pages in a virtual “window” (the viewport), usually wider than the screen, so they don’t need to squeeze every page layout into a tiny window (which would break many non-mobile-optimized sites). Users can pan and zoom to see different areas of the page.

Mobile Safari introduced the “viewport meta tag” to let web developers control the viewport’s size and scale. Many other mobile browsers now support this tag, although it is not part of any web standard. Apple’s documentation does a good job explaining how web developers can use this tag, but we had to do some detective work to figure out exactly how to implement it in Fennec. For example, Safari’s documentation says the content is a “comma-delimited list,” but existing browsers and web pages use any mix of commas, semicolons, and spaces as separators.

Viewport basics

A typical mobile-optimized site contains something like the following:

<meta name="viewport"
 content="width=device-width, initial-scale=1, maximum-scale=1"/>

The width property controls the size of the viewport. It can be set to a specific number of pixels like width=600 or to the special value device-width value which is the width of the screen in CSS pixels at a scale of 100%. (There are corresponding height and device-height values, which may be useful for pages with elements that change size or position based on the viewport height.)

The initial-scale property controls the zoom level when the page is first loaded. The maximum-scale, minimum-scale, and user-scalable properties control how users are allowed to zoom the page in or out.

A pixel is not a pixel

The iPhone and many popular Android phones have 3- to 4-inch (7–10 cm) screens with 320×480 pixels (~160 dpi). Firefox for Maemo runs on the Nokia N900, which has the same physical size but 480×800 pixels (~240 dpi). Because of this, the last version of Fennec displayed many pages about one third smaller (in actual, physical size) than iPhone or Android. This caused usability and readability problems on many touch-optimized web sites. Peter-Paul Koch wrote about this problem in A pixel is not a pixel.

Fennec 1.1 for Maemo will use 1.5 hardware pixels for each CSS “pixel”, following the lead of Android’s WebKit-based browser. This means a page with initial-scale=1 will render at close to the same physical size in Fennec for Maemo, Mobile Safari for iPhone, and the Android Browser on both HDPI and MDPI phones. This is consistent with the CSS 2.1 specification, which says:

If the pixel density of the output device is very different from that of a typical computer display, the user agent should rescale pixel values. It is recommended that the pixel unit refer to the whole number of device pixels that best approximates the reference pixel. It is recommended that the reference pixel be the visual angle of one pixel on a device with a pixel density of 96dpi and a distance from the reader of an arm’s length.

For web developers, this means that 320px be full width in portrait mode at scale=1, on all of the above-mentioned handheld devices, and they may size their layouts and images accordingly. But remember that not all mobile devices are the same width; you should also make sure that your pages work well in landscape mode, and on larger devices like the iPad and Android tablets.

On 240-dpi screens, pages with initial-scale=1 will effectively be zoomed to 150% by both Fennec and Android WebKit. Their text will be smooth and crisp, but their bitmap images will probably not take advantage of the full screen resolution. To get sharper images on these screens, web developers may want to design images – or whole layouts – at 150% of their final size (or 200%, to support the rumored 320-dpi iPhone) and then scale them down using CSS or viewport properties.

Right now Fennec uses the same default ratio of 1.5 on all devices. (It’s a hidden preference that can be changed in about:config or by an add-on.) Later we’ll need to change this – as well as many other parts of Fennec’s user interface – to work correctly on screens with different pixel densities. Note that the default ratio of 1.5 is true only when the viewport scale equals 1. Otherwise, the relationship between CSS pixels and device pixels depends on the current zoom level.

Viewport width and screen width

Many sites set their viewport to "width=320, initial-scale=1" to fit precisely onto the iPhone display in portrait mode. As mentioned above, this caused problems when Fennec 1.0 endered these sites, especially in landscape mode. To fix this, Fennec 1.1 will expand the viewport width if necessary to fill the screen at the requested scale. This matches the behavior of Android and Mobile Safari, and is especially useful on large-screen devices like the iPad. (Allen Pike’s Choosing a viewport for iPad sites has a good explanation for web developers.)

For pages that set an initial or maximum scale, this means the width property actually translates into a minimum viewport width. For example, if your layout needs at least 500 pixels of width then you can use the following markup. When the screen is more than 500 pixels wide, the browser will expand the viewport (rather than zoom in) to fit the screen:

<meta name="viewport" content="width=500, initial-scale=1"/>

Fennec 1.1 also adds support for minimum-scale, maximum-scale, and user-scalable, with defaults and limits similar to Safari’s. These properties affect the initial scale and width, as well as limiting changes in zoom level.

Mobile browsers handle orientation changes slightly differently. For example, Mobile Safari often just zooms the page when changing from portrait to landscape, instead of laying out the page as it would if originally loaded in landscape. If web developers want their scale settings to remain consistent when switching orientations on the iPhone, they must add a maximum-scale value to prevent this zooming, which has the sometimes-unwanted side effect of preventing users from zooming in:

 name="viewport" content="initial-scale=1, maximum-scale=1">

This is not necessary in Fennec; when the device changes orientation, Fennec updates the viewport size, the page layout, and JavaScript/CSS properties like device-width, based on its new “window” dimensions.

Standards

There is clearly demand for the viewport meta tag, since it is supported by most popular mobile browsers and used by thousands of web sites. It would be good to have a true standard for web pages to control viewport properties. According to the HTML5 spec, extensions to the meta element should first be registered on the WHATWG wiki and then go through the W3C standards process. If this happens, then we at Mozilla will work to make sure we can implement any changes made during standardization.

Fast JavaScript and Audio: Speech Synthesis in Your Browser

Christopher Blizzard — Wed, 26 May 2010 17:31:27 +0000

If you haven’t been keeping track of David Humphrey’s work to bring audio manipulation to Firefox, you’re missing out. He’s made an update post with a huge number of demos, requiring some of the most recent advances in JavaScript found in Firefox – binary arrays, super-fast tracing-based FFT analysis, etc. This was my favorite bit of his post:

I think that my favourite demo by far this time around is one that I’ve been waiting to see since we first began these experiments. I’ve written in the past that our work could be used to solve many web accessibility problems. A few weeks ago I mentioned on irc that someone should take a shot at building a text to speech engine in JavaScript, now that we have typed arrays. Yury quietly went off and built one based on the flite engine. When you run this, remember that you’re watching a browser speak with no plugins of any kind. This is all done in JavaScript.

Web Audio Data API – Text to Speech Demo from David Humphrey on Vimeo.

Firefox, YouTube and WebM

Christopher Blizzard — Wed, 19 May 2010 16:24:23 +0000

Five important items of note today relating to Mozilla’s support for the VP8 codec:

1. Google will be releasing VP8 under an open source and royalty-free basis. VP8 is a high-quality video codec that Google acquired when they purchased the company On2. The VP8 codec represents a vast improvement in quality-per-bit over Theora and is comparable in quality to H.264.

2. The VP8 codec will be combined with the Vorbis audio codec and a subset of the Matroska container format to build a new standard for Open Video on the web called WebM. You can find out more about the project at its new site: http://www.webmproject.org/.

3. We will include support for WebM in Firefox. You can get super-early WebM builds of Firefox 4 pre-alpha today. WebM will also be included in Google Chrome and Opera.

4. Every video on YouTube will be transcoded into WebM. They have about 1.2 million videos available today and will be working through their back catalog over time. But they have committed to supporting everything.

5. This is something that is supported by many partners, not just Google and others. Content providers like Brightcove have signed up to support WebM as part of a full HTML5 video solution. Hardware companies, encoding providers and other parts of the video stack are all part of the list of companies backing WebM. Even Adobe will be supporting WebM in Flash. Firefox, with its market share and principled leadership and YouTube, with its video reach are the most important partners in this solution, but we are only a small part of the larger ecosystem of video.

We’re extremely excited to see Google joining us to support Open Video. They are making technology available on terms consistent with the Open Web and the W3C Royalty-Free licensing terms. And – most importantly – they are committing to support a full open video stack on the world’s largest video site. This changes the landscape for video and moves the baseline for what other sites have to do to maintain parity and keep up with upcoming advances in video technology, not to mention compatibility with the set of browsers that are growing their userbase and advancing technology on the web.

At Mozilla, we’ve wanted video on the web to move as fast as the rest of the web. That has required a baseline of open technology to build on. Theora was a good start, but VP8 is better. Expect us to start pushing on video innovation with vigor. We’ll innovate like the web has, moving from the edges in, with dozens of small revolutions that add up to something larger than the sum of those parts. VP8 is one of those pieces, HTML5 is another. If you watch this weblog, you can start to see those other pieces starting to emerge as well. The web is creeping into more and more technologies, with Firefox leading the way. We intend to keep leading the web beyond HTML5 to the next place it needs to be.

Today is a day of great change. Tomorrow will be another.

Firefox 4: the HTML5 parser – inline SVG, speed and more

Christopher Blizzard — Tue, 11 May 2010 15:55:26 +0000

This is a guest post from Henri Sivonen, who has been working on Firefox’s new HTML5 parser. The HTML parser is one of the most complicated and sensitive pieces of a browser. It controls how your HTML source is turned into web pages and as such changes to it are rare and need to be well-tested. While most of Gecko has been rebuilt since its initial inception in the late 90s, the parser was one of the stand-outs as being “original.” This replaces that code with a new parser that’s faster, compliant with the new HTML5 standard and enables a lot of new functionality as well.

A project to replace Gecko’s old HTML parser, dating from 1998, has been ongoing for some time now. The parser was just turned on by default on the trunk, so you can now try it out by simply downloading a nightly build without having to flip any configuration switch.

There are four main things that improve with the new HTML5 parser:

You can now use SVG and MathML inline in HTML5 pages, without XML namespaces.
Parsing is now done off Firefox’s main UI thread, improving overall browser responsiveness.
It’s improved the speed of innerHTML calls by about 20%.
With the landing of the new parser we’ve fixed dozens of long-standing parser related bugs.

Try the demo with a Firefox Nightly or another HTML5-ready browser. It should look like this:

What Is It?

The HTML5 parser in Gecko turns a stream of bytes into a DOM tree according to the HTML5 parsing algorithm.

HTML5 is the first specification that tells implementors, in detail, how parse HTML. Before HTML5, HTML specifications didn’t say how to turn a stream of bytes into a DOM tree. In theory, HTML before HTML5 was supposed to be defined in terms of SGML. This implied a certain relationship between the source of valid HTML documents and the DOM. However, parsing wasn’t well-defined for invalid documents (and Web content most often isn’t valid HTML4) and there are SGML constructs that were in theory part of HTML but that in reality popular browsers didn’t implement.

The lack of a proper specification led to browser developers filling in the blanks on their own and reverse engineering the browser with the largest market share (first Mosaic, then Netscape, then IE) when in doubt about how to get compatible behavior. This led to a lot of unwritten common rules but also to different behavior across browsers.

The HTML5 parsing algorithm standardizes well-defined behavior that browsers and other applications that consume HTML can converge on. By design, the HTML5 parsing algorithm is suitable for processing existing HTML content, so applications don’t need to continue maintaining their legacy parsers for legacy content. Concretely, in the trunk nightlies, the HTML5 parser is used for all text/html content.

How Is It Different?

The HTML5 parsing algorithm has two major parts: tokenization and tree building. Tokenization is the process of splitting the source stream into tags, text, comments and attributes inside tags. The tree building phase takes the tags and the interleaving text and comments and builds the DOM tree. The tokenization part of the HTML5 parsing algorithm is closer to what Internet Explorer does than what Gecko used to do. Internet Explorer has had the majority market share for a while, so sites have generally been tested not to break when subjected to IE’s tokenizer. The tree building part is close to what WebKit does already. Of the major browser engines WebKit had the most reasonable tree building solution prior to HTML5.

Furthermore, the new HTML5 parser parses network streams off the main thread. Traditionally, browsers have performed most tasks on the main thread. Radical changes like off-the-main-thread parsing are made possible by the more maintainable code base of the HTML5 parser compared to Gecko’s old HTML parser.

What’s In It for Web Developers?

The changes mentioned above are mainly of interest to browser developers. A key feature of the HTML5 parser is that you don’t notice that anything has changed.

However, there is one big new Web developer-facing feature, too: inline MathML and SVG. HTML5 parsing liberates MathML and SVG from XML and makes them available in the main file format of the Web.

This means that you can include typographically sophisticated math in your HTML document without having to recast the entire document as XHTML or, more importantly, without having to retrofit the software that powers your site to output well-formed XHTML. For example, you can now include the solution for quadratic equations inline in HTML:

>
  >x>
 
  >=>
  >
    >
      >−>
      >b>
      >±>
      >
        >
 
          >b>
          >2>
        >
        >−>
        >4>
        >⁢>
        >a>
 
        >⁢>
        >c>
      >
    >
    >
      >2>
      >⁢>
      >a>
 
    >
  >
>

Likewise, you can include scalable inline art as SVG without having to recast your HTML as XHTML. As screen sized and pixel densities become more varied, making graphics look crisp at all zoom levels becomes more important. Although it has previously been possible to use SVG graphics in HTML documents by reference (using the object element), putting SVG inline is more convenient in some cases. For example, an icon such as a warning sign can now be included inline instead of including it from an external file.

 height=86 width=90 viewBox='5 9 90 86' style='float: right;'>
   stroke=#F53F0C stroke-width=10 fill=#F5C60C stroke-linejoin=round d='M 10,90 L 90,90 L 50,14 Z'/>
   stroke=black stroke-width=10 stroke-linecap=round x1=50 x2=50 y1=45 y2=75 />
>

Make yourself a page that starts with and put these two pieces of code in it and it should work with a new nightly. In general, if you have a piece of MathML or SVG as XML, you can just copy and paste the XML markup inline into HTML (omitting the XML declaration and the doctype if any). There are two caveats: The markup must not use namespace prefixes for elements (i.e. no svg:svg or math:math) and the namespace prefix for the XLink namespace has to be xlink. In the MathML and SVG snippits above you’ll see that the inline MathML and SVG pieces above are more HTML-like and less crufty than merely XML pasted inline. There are no namespace declarations and unnecessary quotes around attribute values have been omitted. The quote omission works, because the tags are tokenized by the HTML5 tokenizer—not by an XML tokenizer. The namespace declaration omission works, because the HTML5 tree builder doesn’t use attributes looking like namespace declarations to assign MathMLness or SVGness to elements. Instead, establishes a scope of elements that get assigned to the SVG namespace in the DOM and establishes a scope of elements that get assigned to the MathML namespace in the DOM. You’ll also notice that the MathML example uses named character references that previously haven’t been supported in HTML. Here’s a quick summary of inline MathML and SVG parsing for Web authors:

… is assigned to the SVG namespace in the DOM.
… is assigned to the MathML namespace in the DOM.
foreignObject and annotation-xml (an various less important elements) establish a nested HTML scope, so you can nest SVG, MathML and HTML as you’d expect to be able to nest them.
The parser case-corrects markup so works in HTML source.
The DOM methods and CSS selectors behave case-sensitively, so you need to write your DOM calls and CSS selectors using the canonical case, which is camelCase for various parts of SVG such as viewBox.
The syntax opens and immediately closes the foo element if it is a MathML or SVG element (i.e. not an HTML element).
Attributes are tokenized the same way they are tokenized in HTML, so you can omit quotes in the same situations where you can omit quotes in HTML (i.e. when the attribute value is not the empty string and does not contain whitespace, ", ‘, `, <, =, or >).
Warning: the two above features do not combine well due to the reuse of legacy-compatible HTML tokenization. If you omit quotes on the last attribute value, you must have a space before the closing slash. is OK but is not.
Attributes starting with xmlns have absolutely no effect on what namespace elements or attributes end up in, so you don’t need to use attributes starting with xmlns.
Attributes in the XLink namespace must use the prefix xlink (e.g. xlink:href).
Element names must not have prefixes or colons in them.
The content of SVG script elements is tokenized like they are tokenized in XML—not like the content of HTML script elements is tokenized.
When an SVG or MathML element is open …]]> sections work the way they do in XML. You can use this to hide text content from older browsers that don’t support SVG or MathML in text/html.
The MathML named characters are available for use in named character references everywhere in the document (also in HTML content).
To deal with legacy pages where authors have pasted partial SVG fragments into HTML (who knows why) or used a tag for non-MathML purposes, attempts to nest various common HTML elements as children of SVG elements (without foreignObject) will immediately break out of SVG or MathML context. This may make some typos have surprising effects.



Beyond HTML5: experiments with interactive audio
Christopher Blizzard — Fri, 30 Apr 2010 18:57:33 +0000
This is a re-post of an important post from David Humphrey who has been doing a lot of experiments on top of Mozilla’s extensible platform and doing experiments with multi-touch, sound, video, WebGL and all sorts of other goodies.  It’s worth going through all of the demos below.  You’ll find some stuff that will amaze and inspire you.
David’s work is important because it’s showing where the web is going, and where Mozilla is helping to take it.  It’s not enough that we’re working on HTML5, which we’re about finished with, but we’re trying to figure out what’s next.  Mozilla’s platform, Gecko, is a huge part of why we’re able to experiment and learn as fast as we can.  And that’s reflected with what’s possible here.  It’s a web you can see, touch and interact with in new ways.
David’s post follows:
I’m working with an ever growing group of web, audio, and Mozilla  developers on a project to expose audio  spectrum data to JavaScript from Firefox’s audio and video elements.  Today we show what we did at www2010.
I’m in Raleigh, North Carolina, with Al MacDonald for the www2010 conference.  We’re here to present our work on exposing audio data in the browser.  Over the past month Corban, Charles, and a bunch of other friends have been working with us to refine the API and get new types of demos ready.  We ended-up with 11 demos, some of which I’ve shown here before.  Here are the others.
The first was done by Jacob Seidelin, and shows many cool 2D visualizations of audio using our API.  You can see the live version on his site, or check out this video:

The second and third demos where done by Charles Cliffe, and show 3D visualizations using WebGL and his CubicVR engine.  These also show off his JavaScript beat detection code.  Is JavaScript fast enough to do real-time analysis of audio and synchronized 3D graphics?  Yes, yes it is.  The live versions are here and here, and here are some videos:


The fourth demo was done by Corban Brook and shows how audio data can be mixed live using script.  Here he mutes the main audio, plays it, passes the data through a low pass filter written in JavaScript, then dumps the modified frames into a second audio element to be played.  It’s a technique we need to apply more widely, as it holds a lot of potential.  Here’s the live version, and here’s a video (check out his updated JavaScript synthesizer, which we also presented):

The fifth and sixth demos were done by Al (with the help of many).  When I was last in Boston, for the Processing.js meetup at Bocoup, we met with Doug Schepers from the W3C.  He loved our stuff, and was talking to us about ideas that would be cool to build.  He pulled out his iPhone and showed us Brian Eno’s Bloom audio app.  “It would be cool to do this in the browser.”  Yeah, it is cool, and here it is, written in a few hundred lines of JavaScript and Processing.js (video 1, video 2):


This demo also showcases the awesome work of Felipe Gomes, who has a patch to add multi-touch DOM events to Firefox.  The method we’ve used here can be taken a lot further.  Imagine being able to connect multiple browsers together for collaborative music creation, layering other audio underneath, mixing fragments vs. just oscillators, etc.  We built this one in a week, and the web is capable of a lot more.
One of the main points of our talk was to emphasize that what we’re talking about here isn’t just a concept, and it isn’t some far away future.  This is real code, running in a real browser, and it’s all being done in HTML5 and JavaScript.  The web is fast enough to do real-time audio processing now, powerful enough and expressive enough to create music.  And the community of digital music and audio hackers, visualizers, etc. are hungry for it.  So hungry that they are seeking us out, downloading our hacked builds and creating gorgeous web audio applications.
We want to keep going, and we need help.  We need help from those within Mozilla, the W3C, and other browsers to get this stuff into shipping browsers.  We need the audio, digital music, accessibility, and web communities to come together in order to help us build js audio libraries and more sample applications.  Yesterday Joe Hewitt was talking on twitter about how web browser vendors need to experiment more with non-standard APIs.  I couldn’t agree more, and here’s a chance for people to put their money where their mouth is.  Let’s make audio a scriptable part of the open web.
I’m currently creating new builds of our updated patch for Firefox, and will post links to them here when I’m done.  You can read more about the technical details of our work here, and get involved in the bug here.  You can talk more with me on irc in the processing.js channel (I’m humph on moznet), or talk to me on twitter (@humphd) or by email.  One way or another, get in touch so you can help us push this forward.



WebSockets in Firefox
Christopher Blizzard — Wed, 28 Apr 2010 17:11:19 +0000
Here’s the pitch for WebSockets: a low-complexity, low-latency, bi-directional communication system that has a pretty simple API for web developers.  Let’s break that down, and then talk about if and when we’re going to include it in Firefox:
Low-complexity
The WebSocket protocol, which is started via an HTTP-like handshake, has a relatively simple model for sending text packets back and forth.  The complexity of the protocol is quite low.  There’s no multiplexing, no support for binary data, and once the data connection is set up, the actual transport is quite cheap.
Note that there are people who feel – possibly correctly – that support for multiplexing and binary data should be added.  That would obviously increase the complexity but in some cases might be worth the cost.  But more on that later.
Bi-directional Communication
One of the key aspects of WebSocket is its support for simple bi-directional communication.  Servers can easily send updates to clients and clients can send updates to servers.  Many of the comet-style applications that people have built will be much simpler and faster with this model because the protocol and API support it directly.
While allowing for bi-directional communication it also is bound by the HTTP same-origin model.  That is, it’s doesn’t give the browser the ability to connect to any site on any port it wants to.
So WebSocket is really TCP with the HTTP security model.
Low-latency
This is actually the primary value in WebSockets.  The key thing is that the cost of sending a small amount of data is also very small.  It’s possible to do bi-directional communication today with comet-style applications, but small amounts of data often require a huge amount of overhead to do so.
A second-hand story to give you a sense of scale: Google Wave, which tries to do real-time communication with keystrokes has a several-kilobyte overhead for just about every keystroke because of the TCP startup, teardown and HTTP message headers involved with what should be only a few bytes sent over the wire.
I haven’t tried, but I’m going to guess that if you built Quake on top of HTTP comet that the interactive experience would be poor.  So this is where WebSockets really shine.
Simple API
The actual API that a developer sees for WebSocket is relatively simple.  You can send messages, you can get messages, you get events when sockets open, close or there’s an error.  Additional complexity, which I’m sure others will develop, will happen in JavaScript and backend libraries.
(While this might seem like punting on the issue of complexity, this is actually the model for success we’ve seen for other browser standards: build something relatively simple that others can experiment with.  When we understand what’s slow or what’s preventing progress, iterate and improve.)
When will it be in Firefox?
We really really want to support WebSockets in the next version of Firefox.  And a lot of other people want us to include support too.
The first set of test patches, written by the wonderful Wellington Fernando de Macedo (one of our most excellent contributors!) was first submitted in April of 2009.  Since then we’ve been iterating both on the patches themselves and following the spec as it’s changed.
Unfortunately, the spec itself is still under revision.  WebSockets did ship in Chrome with version 4 and I’m told by Chrome developers that it’s going to be included in Chrome 5, without changes.  Unfortunately, the version that Google included in Chrome doesn’t reflect the current draft.  The handshake for how to start a WebSocket connection has changed, largely to improve security on servers.  There’s also a lot of ongoing discussion on the role of integrated compression, direct support for binary data (instead of encoding binary data as strings), whether or not the protocol should support multiplexing and a number of other issues.
Since WebSocket isn’t used widely yet, and that Chrome has an uptake rate that’s similar to Firefox, the hope is that once a more recent draft makes it through the process that both Chrome and Firefox can include a more recent version at around the same time.
So in short: we want to ship it because the promise of WebSockets is great, but we’ll have to see if it’s stable and safe enough to do so.  Code isn’t the issue – we’ve had that for a while.  It’s whether or not there’s consensus on if the protocol is “done enough” to ship it to a few hundred million people.



a series of updates on what’s coming in Firefox 4
Christopher Blizzard — Mon, 26 Apr 2010 17:17:06 +0000
Over the next couple of weeks, people like Paul Rouget and I are going to post a series of updates on a bunch of technologies that are part of our next release.  That release, likely called Firefox 4, was underway before the release of Firefox 3.6 and already includes a bunch of new features, bug fixes and performance enhancements.  (As an aside, I personally suspect that in a lot of ways Firefox 4 is likely to be a revolutionary release for both users and web developers, but more on that in later posts.)
Since we’re in the middle of the development cycle it’s important for web developers to know what’s coming and how they can test them.  We’ll talk candidly about not only what’s coming, but why they are important.  Very often in the current race to improve browsers context is lost on why something is or isn’t included, or why something is higher priority than something else.  We’ll try and shine some context on a lot of these things as well as give good technical info about our roadmap to the next Firefox release.
So stay tuned, it’s going to be a fun ride.



Theora on N900
Christopher Blizzard — Mon, 19 Apr 2010 17:00:41 +0000
This is a re-post from Matthew Gregan’s personal weblog on the work that he’s been doing to bring HTML5 open video to mobile devices.  Google recently announced funding for some work to bring Theora to ARM devices via a CPU-driven code path.  Mozilla has been funding similar work over the last year or so to do video decoding on DSPs found in mobile devices, leaving the CPU largely idle.
We realize this post isn’t strictly web developer-facing, but it’s interesting enough for those who want to know how this stuff works under the covers.
Theora on N900: Or, how to play full-screen Theora video on the N900 with 80% idle CPU.
The C64x+ DSP is often found in systems built upon TI’s OMAP3 SoC, such as the Palm Pre, Motorola Droid, and Nokia N900. Last year, Mozilla funded a port, named Leonora, of Xiph’s Theora video codec to the TI C64x+ DSP. David Schleef conducted the port impressively quickly and published his results. The intention of this project was to provide a high quality set of royalty free media codecs for a common mobile computing platform. The initial focus is Firefox Mobile on the N900, so I am working on integrating David’s work into Firefox. To experiment with other facilities Firefox could use to accelerate video playback and test integration, I’ve been hacking on a branch of a stand-alone Ogg Theora and Vorbis player originally written by Chris Double called plogg.
Decoding and playing video can be a CPU intensive process, especially when all of the steps are fighting for time on a single CPU. The expensive parts of the playback process can be broken down into a few coarse pieces, in approximate descending order of cost:

Video frame decode
Video colour-space conversion (Y’CbCr to RGB)
Video frame display
Audio block decode
Audio block playback

David’s DSP work enables item 1 to be off-loaded from the CPU completely, effectively providing “hardware accelerated” video decoding. Most devices have some way to off-load items 2 and 3 to the graphics hardware, but it can be difficult to make use of this while integrating with an existing graphics rendering pipeline.
The N900 has a 800×480 pixel display, so my hope was to play a 800×480 video full-screen at 30 frames per second with low CPU use and good battery life.
The ARM CPU in the N900 is quite fast. Doing a pure video-decode-only test, the original Theora library, which currently does not have ARM specific optimizations, is able to decode a 640×360 video at 76 frames per second, and it can even decode an 800×480 video at 32 frames per second. With the ARM optimized port by Robin Watts, those numbers become 110 FPS and 47 FPS. David’s DSP port produces 78 FPS and 39 FPS, and it leaves the CPU completely idle because the entire decode is off-loaded to the DSP. With these numbers, it’s clear that the N900 is up to the task of playing back video smoothly if we can get the bits on the screen fast enough.
I am using plogg as a basis for experimentation using techniques applicable in the Firefox rendering engine. This requirement immediately excludes some techniques. For example, using hardware Y’CbCr overlays to display the video frames is excluded because it is not possible for Firefox to render arbitrary HTML content over the top of the overlay.
Chris’s original version of plogg used SDL’s Y’CbCr overlay API, which uses a fast direct overlay path on most systems. This provided a baseline for playback performance. Decoding my 800×480 test video with the DSP, it was possible to play back at 33 FPS with around 20% CPU idle. Unlike the decode-only benchmarks mentioned above, the plogg benchmarks are playing both audio and video with correct A/V synchronisation. With 44.1kHz stereo audio, I observed that 10-15% of the device’s CPU is used by PulseAudio. This indicates that audio playback may constitute a significant amount of processor time with some configurations.
Because there was already work underway to provide OpenGL accelerated compositing in Firefox with the newly conceived Layers API, it seemed logical to try using a GLSL fragment shader to off-load colour-space conversion to the GPU. This turned out to be too slow to play back a full-screen video.
Looking at the list of vendor-specific OpenGL extensions available on the N900, I discovered the texture streaming API. This allows a program to directly map texture memory and copy Y’CbCr data into that memory without having to perform an expensive texture upload or colour-space conversion. The colour-space conversion is off-loaded to dedicated graphics hardware inaccessible via the standard OpenGL APIs. Using this and the modified bc-cat kernel module from the gst-bc-cat project, it’s possible to play back at 26 FPS with 81% CPU idle.
One drawback of the current bc-cat kernel driver is that there is a very limited set of texture formats supported (NV12, UYVY, RGB565, and YUYV), and none of them are the same as what Theora produces. To work around this, a format conversion is required to convert planar Y’CbCr to packed 4:2:2 UYVY. Fortunately, this conversion is much simpler than a full colour-space conversion. Timothy Terriberry sent me a couple of patches to off-load this conversion work to the DSP. If it’s possible to extend the bc-cat driver to support texture formats compatible with Theora’s output, performance can be further improved.
The test files used for benchmarking were: Big Buck Bunny (video: 640×360 @ 500 kbps 24 FPS, audio: 64 kbps 48kHz stereo, 9m 56s, 40MB) and the movie trailer for 9 (video: 800×480 @ 2 Mbps 23.98 FPS, audio: 44.1kHz stereo, 2m 30s, 30MB). Benchmarks were run with the CPU frequency fixed at 600MHz.
In summary, it’s possible to play full-screen Ogg Theora videos on the N900 at full frame rates with low CPU use by off-loading video decoding to the DSP and colour-space conversion and painting to the GPU. There are opportunities for optimization left, tuning for battery life needs to be investigated, and the integration into Firefox still needs to be done.
Video decode-only:



Decoder
FPS (800×480)
Idle CPU


libtheora 1.1
32
0.7%


TheorARM 0.04
47
0.4%


leonora (DSP)
39
99.0%


Playback (video decode + paint, audio decode + not played). DSP decoding video:



Method
FPS (800×480)
Idle CPU


SDL/overlay
33
20.0%


OpenGL/bc-cat
26
81.4%





mozilla developer preview 4 ready for testing
Christopher Blizzard — Mon, 12 Apr 2010 18:41:01 +0000
Note: this is a re-post of the entry in the Mozilla Project Development Weblog.  There’s some juicy stuff in here for Web Developers that need testing.  In particular, this is the first build with the CSS history changes.
As part of our ongoing platform development work, we’re happy to announce the fourth pre-release of the Gecko 1.9.3 platform.  Gecko 1.9.3 will form the core of Firefox and other Mozilla project releases.
It’s available for download on Mac, Windows or Linux.
Mozilla expects to release a Developer Preview every 2-3 weeks. If you’ve been running a previous release, you will be automatically updated to the latest version when it is released. 
This preview release contains a lot of interesting stuff that’s worth pointing out, and contains many things that were also in previous releases.  Here are the things of note in this release:
User Interface Changes

Open tabs that match searches in the Awesomebar now show up as “Switch to Tab.”
This is the first preview release to contain resizable text areas by default.

Web Developer Changes

This is the first preview release to contain changes to CSS :visited that prevent a large class of history sniffing attacks.  You can find more information about the details of why this change is important over on the hacks post on the topic and on the Mozilla Security Weblog.  Note that this change is likely to break some web sites and requires early testing – please test if you can.

SVG Attributes which are mapped to CSS properties can now be animated with SMIL.  See the bug or a demo.


Plugins


Out of process plugins support for Windows and Linux continues to improve.  This release contains many bug fixes vs. our previous developer preview releases.  (In fact, it’s good enough that we’ve ported this code back to the 3.6 branch and have pushed that to beta for a later 3.6.x release.)
This is the first release that contains support for out of process plugins for the Mac.  If you are running OSX 10.6 and you’re running the latest Flash beta, Flash should run out of process

Performance

One area where people complained about performance was restart performance when applying an update.  It turns out that a lot of what made that experience poor wasn’t startup time, it was browser shutdown time.  We’ve made a fix since the last preview release that made a whopping 97% improvement in shutdown time.  (That’s not a typo, it’s basically free now.)
Our work to reduce the amount of I/O on the main thread continues unabated.  This preview release will feel much snappier than previous snapshots, and feel much faster than Firefox 3.6.
We continue to add hardware acceleration support.  If you’re on Windows and you’ve got decent OpenGL 2 drivers, open video will use hardware to scale the video when you’re in full screen mode.  For large HD videos this can make a huge difference in the smoothness of the experience and how much power + CPU are used.  We’ll be adding OSX and Linux support at some point in the future as well, but we’re starting with Windows.
We continue to make improvements and bug fixes to our support for Direct2D.  (Not enabled by default.  If you want to turn it on see Bas’ post.)  If you’re running Alpha 4 on Windows Vista or Windows 7, and you’ve turned on D2D, try running this stress test example in Alpha 4 vs. Firefox 3.6.  The difference is pretty amazing.  You can also see what this looks like compared to other browsers in this this video.  (Thanks to Hans Schmucker for the video and demo.)


Platform


JS-ctypes, our new easy-to-use system for extension authors who want to call into native code now has support for complex types: structures, pointers, and arrays.  For more information on this, and how easy it can make calling into native code from JavaScript, see Dan Witte’s post.
Mozilla is now sporting an infallible allocator.  What is this odd-sounding thing, you ask?  It’s basically an allocator that when memory can’t be allocated it aborts instead of returning NULL.  This reduces the surface area for an entire class of security bugs related to checking NULL pointers, and also allows us to vastly simplify a huge amount of Gecko’s source code.





privacy-related changes coming to CSS :visited
Christopher Blizzard — Wed, 31 Mar 2010 15:26:13 +0000
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.



a quick note on JavaScript engine components
Christopher Blizzard — Mon, 08 Mar 2010 21:23:00 +0000
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:

Monitor interpreted JavaScript code during execution looking for code paths that are used more than once.
When we find a piece of code that’s used more than once, optimize that code.
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.



Mozilla developer preview (Gecko 1.9.3a2) now available
Christopher Blizzard — Fri, 05 Mar 2010 20:28:57 +0000
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  and  is now supported.
</li>
<li>Support for SMIL Animation in SVG. Support for animating some SVG attributes is still under development and the <code>animateMotion</code> element isn’t supported yet.
</li>
<li>Support for CSS Transitions. This support is not quite complete: support for animation of transforms and gradients has not yet been implemented.
</li>
<li>Support for WebGL, which is disabled by default but can be enabled by changing a preference. See <a href="http://hacks.mozilla.org/2009/09/webgl-for-firefox/">this blog post</a> and <a href="http://hacks.mozilla.org/2009/12/webgl-draft-released-today/">this blog post</a> for more details.
</li>
<li>Support for the <code>getClientRects</code> and <code>getBoundingClientRect</code> methods on Range  objects. See <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=396392">bug 396392</a> for details.</li>
<li>Support for the <code>setCapture</code> and <code>releaseCapture</code> methods on DOM elements. See <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=503943">bug 503943</a> for details.</li>
<li>Support for the HTML5 <a href="https://developer.mozilla.org/en/DOM/Manipulating_the_browser_history#Adding_and_modifying_history_entries"><code>History.pushState()</code> and <code>History.replaceState()</code> methods and the <code>popstate</code> event</a>. See <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=500328">bug 500328</a> for details.</li>
<li>Support for the <code><a href="https://developer.mozilla.org/en/CSS/background-image">-moz-image-rect()</a></code> value for background-image. See <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=113577">bug 113577</a> for more details.
</li>
</ul>
<p>For the full list of new web developer features please visit our page on <a href="https://developer.mozilla.org/en/Upcoming_Firefox_features_for_developers">Upcoming Features for Web Developers</a>.</p>
<h3>Performance Improvements</h3>
<ul>
<li>We’ve removed link history lookup from the main thread and made it asynchronous.  This results in <a href="https://wiki.mozilla.org/Firefox/Goals/2010Q1/IO_Reduction">less I/O during page loads</a> and improves overall browser responsiveness.</li>
<li>Loading the <a href="http://www.whatwg.org/specs/web-apps/current-work/">HTML5 spec</a> no longer causes very long browser pauses.
</li>
<li>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.</li>
<li>The JavaScript engine has many improvements: String handling is improved, faster closures, some support for recursion in TraceMonkey to name a few.</li>
<li>Improvements to the performance of repainting HTML in <code><foreignObject></code>.
</li>
<li>Strings are not copied between the main DOM code and <a href="https://developer.mozilla.org/En/Using_web_workers">web workers</a>, improving performance for threaded JavaScript which moves large pieces of data between threads.</li>
</ul>

</article>
</main></body></html>

Mozilla Hacks - the Web developer blog » Christopher Blizzard

Introducing Aurora 9

JavaScript Type Inference

JavaScript Interface for Do Not Track

mouseenter and mouseleave events

Camera UI for Mobile

Support for chunked XMLHttpRequest

Other changes

HTML

Graphics

Layout

Video

Network

Tools

What’s new for Web Developers in Firefox 7

Firefox 4 Beta 9 – a huge pile of awesome

Performance

WebGL

JavaScript

Web Console

HTML5

DOM

CSS

Security

That’s a lot of stuff

Fun With Fast JavaScript

Brendan Eich at JSConf 2010 – what’s coming in ECMAScript 5 and more

Firefox 4 – FormData and the new File.url object

Firefox 4 beta 1 is here – what’s in it for web developers?

HTML5 adoption stories: box.net and html5 drag and drop

upcoming changes to the viewport meta tag for firefox mobile

Background

Viewport basics

A pixel is not a pixel

Viewport width and screen width

Standards

Fast JavaScript and Audio: Speech Synthesis in Your Browser

Firefox, YouTube and WebM

Firefox 4: the HTML5 parser – inline SVG, speed and more

Beyond HTML5: experiments with interactive audio

WebSockets in Firefox

a series of updates on what’s coming in Firefox 4

Theora on N900

mozilla developer preview 4 ready for testing

privacy-related changes coming to CSS :visited

a quick note on JavaScript engine components

Mozilla developer preview (Gecko 1.9.3a2) now available

Out of Process Plugins

Web Developer Features