Articles by Christopher Blizzard

Sort by:


  1. What’s new for Web Developers in Firefox 7

    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:


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


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


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

    WebSockets: Updated protocol and available on mobile

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

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

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

    An even faster Canvas element

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

    Web sites can no longer resize your main browser window

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

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

    Support for the new Navigation Web Timing Spec

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

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

  2. Firefox 4 Beta 9 – a huge pile of awesome

    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.


    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, 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.


    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.


    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.)


    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.


    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.


    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.


    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.


    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.


    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 <img> 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.


    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.


    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!)


    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.


    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.


    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.


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


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


    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.


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


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


    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.


    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.


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


    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.


    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.

  3. Fun With Fast JavaScript

    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!

  4. Firefox 4 – FormData and the new File.url object

    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;

    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();"POST", "file_handler.php");

    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">

    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();"POST", "file_handler.php");

    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();"POST", "file_handler.php");

    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 to give us feedback, or use the feedback button in the upper right corner (see below screenshot).

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

    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.


    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.


    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.


    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.


  6. HTML5 adoption stories: and html5 drag and drop

    This is a guest post from Tomas Barreto, a developer who works at 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, 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 =;
      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 = '';
      var request = new XMLHttpRequest();
  "POST",  url, true); // open asynchronous post request
      request.setRequestHeader('content-type', 'multipart/form-data; boundary=""'); // make sure to set a boundary

    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 = '';
    var request = new XMLHttpRequest();"POST",  url, true); // open asynchronous post request

    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 = '';
    var request = new XMLHttpRequest();
    var fd = new FormData;
    fd.append("myFile", files[0]);
"POST",  url, true); // open asynchronous post request

    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$]!


  7. upcoming changes to the viewport meta tag for firefox mobile

    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 <meta name="viewport"> 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. before: 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.


    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:

    <meta 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.


    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.

  8. Fast JavaScript and Audio: Speech Synthesis in Your Browser

    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.