Articles for July 2010

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

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 <iframe> 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 <form>. (However note that the syntax for this is likely to change before final release)

var fd = myFormElement.getFormData();
var xhr = new XMLHttpRequest();
xhr.open("POST", "file_handler.php");
xhr.send(fd);

Here fd will contain data from all the form fields, from radio buttons to file fields, that are contained in the form.

As always, we’re all ears for feedback about these features. Please let us know what you think, and especially if you have tested them out and they do not appear to do what you expect them to. You can use http://www.mozilla.com/en-US/firefox/beta/feedback/ to give us feedback, or use the feedback button in the upper right corner (see below screenshot).

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 <article>, <section>, <nav>, <aside>, <hgroup>, <header> and <footer>.

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!

We’d like to get your input on where to focus documentation efforts on MDN. There are all kinds of topics that need to be written, updated, or improved — so where should we start? What do you need most?

Give your input via the MDN Dev Doc Priorities forum. You can vote on and comment on proposed topics, or add your own suggestions. I’ve seeded the forum with topics ideas drawn from Bugzilla and from the Documentation Wishlist page on MDN, but no doubt you have other ideas.

If you’re interested in writing on a particular topic, please say so in a comment. Of course, in that case, you don’t need to wait for votes — just dig in.

We’re planning on holding a series of doc sprints (think “hack fest for docs”) starting later this year. Input that you give on documentation needs will help us pick a focus for each of the doc sprints.

Thanks!

(BTW, I’m Janet Swisher, and I started working for Mozilla in June, teaming with Sheppy to improve and expand Mozilla’s assistance for developers of all stripes. I’m having a blast so far, and looking forward to getting to know the community!)