In additional to the normal improvements that you’ve come to expect like performance, security and bug fixes, Aurora 10 focuses in HTML5 enhancements.

New additions

• HTML5 Visibility API
• createProcessingInstruction
• WebGL antialiasing
• 3D Transforms
• Visibility API
• Document.mozFullScreenEnabled\

Developer Tools

• Code Editor
• CSS Rules View
• Page Inspector/Highlighter
• Console Object Completion
• Style Inspector

Aurora 10 also implements incremental enhancements like IndexedDB setVersion API changes. Ongoing detailed attention to evolving specifications help to keep Firefox at the front of the Web revolution. (Read more about IndexedDB on MDN.)

DOM

• We now fire a “load” event on stylesheet linking when the sheet load finishes or “error” if the load fails.
• We turn the POSTDATA prompt into an information page (when navigating in session history).
• We only forward event attributes on body/frameset to the window if we also forward the corresponding on* property.
• We no longer allow more than one call to window.open() when we allow popups.
• We fixed a bug where a success callback never fired when a position update is triggered after getCurrentPosition().
• We removed replaceWholeText().
• We fixed an error with createPattern(zero-size canvas).
• We now handle putImageData(nonfinite) correctly.
• We now throw INVALID_STATE_ERR when dispatching uninitialized events.
• We’ve made Document.documentURI readonly.
• We fixed document.importNode to comply with optional argument omitted.

Web workers

• We now allow data URLs.
• We implemented event.stopImmediatePropagation in workers.
• We made XHR2 response/responseType work in Web Workers.

Graphics

• We implement the WebGL OES_standard_derivatives extension.
• We implement minimal-capabilities WebGL mode.

JavaScript

• The function caller property no longer skips over eval frames.
• We fixed E4X syntax so that it is not accepted in ES5 strict mode.
• weakmap.set no longer returns itself instead of undefined.
• We implemented the battery API.

Offline: IndexedDB enhancements

• IndexedDB setVersion API changes
• Added support for IDBObjectStore/IDBIndex.count
• Various methods accept both keys and KeyRanges.
• Added support for IDBCursor.advance.
• Implemented deleteDatabase.
• objectStoreNames are no longer updated on closed databases when another connection adds or removes object stores
• IDBObjectStore.delete and IDBCursor.delete now return undefined.
• No longer throws an error if there are unknown properties in the options objects to createObjectStore/createIndex.
• We now the errorCode to “ABORT_ERR” for all pending requests when IDBTransaction.abort() is called.
• Fixed the sort order for indexes.

Layout

• We have updated the current rule for handling malformed media queries.
• We now support the HTML5 <bdi> element and CSS property unicode-bidi: isolate.
• The CSS3 implementation now supports unicode-bidi: plaintext.

Media

• Implemented Document.mozFullScreenEnabled.
• Enabled the DOM full-screen API on desktop Firefox by default.

You can see them in action in this demo of a rotating HTML5 logo and the screencast below:

This means now that we need your support in trying out CSS 3D examples in Firefox and add other extensions than -webkit- to your CSS 3D products and demos. To show that this is possible, we took the well-known webkit-only “poster circle” demo and made it work with Firefox nightly by adding the -moz- (and of course the other prefixes and one set of instructions without browser prefixes). Here is a slight excerpt:

-webkit-transform-style: preserve-3d;
-moz-transform-style: preserve-3d;
-o-transform-style: preserve-3d;
-ms-transform-style: preserve-3d;
transform-style: preserve-3d;

You can see this in action in the screencast below alongside Chrome and you try the demo out yourself. The slight jerkiness is actually my MacBook Air impersonating a starting jet every time I use ScreenFlow and not the browser.

To celebrate the release and to show how CSS 3D can be applied as subtle effect, have a game of pairs using your favourite browsers (and a cat) :

Oleg Romashin also spent some time to convert a few CSS 3D demos to work with Mozilla and you can check the 3D city for more “wow”.

If you are new to CSS 3D transformations here’s a good beginner course and a tool to create them.

The rotating HTML5 logo demo also shows how you can check if the currently used browser supports 3D transforms. Instead of repeating the animation frames for all the prefixes we test in JavaScript and create the CSS on the fly:

function checksupport() {
  var props = ['perspectiveProperty', 'WebkitPerspective',
               'MozPerspective', 'OPerspective', 'msPerspective'],
      i = 0,
      support = false;
  while (props[i]) {
    if (props[i] in form.style) {
      support = true;
      pfx = props[i].replace('Perspective','');
      pfx = pfx.toLowerCase();
      break;
    }
    i++;
  } 
  return support;
}
if (checksupport()) {
  var s = '';
  styles = document.createElement('style');
  s += '#stage{-'+ pfx +'-perspective: 300px;}'+
       '#logo{-'+ pfx +'-transform-style: preserve-3d;position:relative;}'+  
       '#logo.spin{-'+ pfx +'-animation: spin 3s infinite linear;}'+
       '@-'+ pfx +'-keyframes spin {'+  
       '0% {'+ 
       '-'+ pfx +'-transform: rotateX(0deg) rotateY(0deg) rotateZ(0deg);'+   
       '}'+
       '100% {'+   
       '-'+ pfx +'-transform: rotateX(0deg) rotateY(360deg)'+
       ' rotateZ(360deg);'+ 
       '}}';
  styles.innerHTML = s;
  document.querySelector('head').appendChild(styles);
}

For more information on creating your own pages that use 3D transformations, take a look at the draft specification

As always, If you find any bugs, please report them at bugzilla.mozilla.org!

So please reward our hard work bringing the third dimension to Firefox’s CSS engine by supporting and testing. Cheers!

Tristan Nitot – Hi Ben, can you briefly introduce yourself?

Ben Adida – I’ve been hacking since high school and, since college, I’ve been fascinated with cryptography, security, and controlling my data. I built my first DB-backed web site before cookies. I ran my own IMAP mail server starting in 1997 because no one else was doing it the way I wanted it. I started an open-source web dev shop in 2000, went back to grad school in 2003 to work on secure voting, explored security and privacy of health data at Harvard Med for a few years, and joined Mozilla in March 2011. I’m now Tech Lead on Identity and User Data, and I’m having a blast.

TN – Oh my… running your own IMAP server in 1997? That’s the kind of thing that gives instant nerd credibility ;-)

BA – Oh yes, big nerd and proud of it!

TN – So you’re now with Mozilla, focusing on Identity and User data. Can you update us on what’s Mozilla is doing on these fronts?

BA – Everyone I talk to within Mozilla realizes that the Open Web depends on more than just the Firefox web browser. People are storing massive quantities of their personal data online, using dozens of services, and an open browser is not enough to ensure that they have true choice, true control, that they can shape the Web to their liking. So we need to be working towards providing user choice in web-based services, too. The first piece of the puzzle is a usable, federated, and distributed identity system. That’s what we’re doing with BrowserID.

TN – “federated, distributed”, with users having control… Sounds like the original pillars of the Web, right? I mean, as opposed to what we tend to see these days, with identity being concentrated into the hands of very large commercial organizations… How do you plan to achieve this?

BA – That’s right, distributed/federated *is* the way of the Web, but when you look at today’s identity solutions, most are incredibly centralized, and those that are more distributed in terms of protocol tend to become centralized in implementation because of the so-called NASCAR problem: you get to log in with Google or Yahoo, and if you’re *really* knowledgeable then maybe you can log in with your own Identity Provider. We think we can do better for users and developers in terms of ease of use and adoption.

TN – And what about privacy?

BA – We’ve specifically designed BrowserID to reduce the amount of private data that changes hands to the bare minimum required for authentication. For example, in every other web-based identity system today, the site you log into phones home to your identity provider. In the real world, the equivalent is: you check into a hotel, present your ID to confirm your name, and the receptionist calls the issuing government agency and says “Hi, this is the Hyatt San Francisco, Tristan is checking in just now, is that okay?” Why does the government agency or, in the case of a privately issued identifier, the commercial entity, need to know where and when you’re checking in? In the real world, the receptionist just checks the seal on the ID without phoning anyone. BrowserID recreates this more restrained, more privacy-protecting data flow for web logins.

TN – So how do you manage to get the best of both worlds: user experience and user control?

BA – First we’re making the browser an important part of the protocol. After all, the browser is the User’s Agent. Isn’t it a little bit silly on today’s Web that you typically have a tab open to your gmail, and then another site asks you to log in with Google or Yahoo? Why can’t the browser help coordinate those two tabs? You’re logged into gmail, of course you have a gmail email address you can use to authenticate! And in the enterprise setting, you’re logged into your company webmail, of course you can authenticate using that enterprise identity! The browser can help reduce user complexity significantly.

TN – But I could want to use another email address, than the one I use for my Webmail…

BA – Right, so we’re always going to give users a choice. Users can choose exactly which persona they want to present. And one major BrowserID design point is simply that users understand email addresses as personas. They typically have home and work email addresses, and they don’t use them the same way. If they have a moonlighting job, they often have a separate email address for that. So BrowserID is based on this concept users already understand: logging in is simply delivering an email address to a web site in a way that the web site can easily verify.

TN – Cool. Say I’m a Web developer that wants to use BrowserID on my site. How hard is that? How much do I have to relinquish control of my users to Mozilla?

BA – It takes about 5 lines of JavaScript and 10 lines of backend code to integrate BrowserID, and it works today. It’s by far the easiest of the available identity solutions. In the short term, it means you’re relying on Mozilla servers to provide the BrowserID interface and verify users’ email addresses. That said, this is only temporary scaffolding for our distributed system.

TN – But as BrowserID becomes native in browsers and identity providers appear, this will change?

BA – We’ve taken great care to design the system so that, as browsers begin to support the BrowserID APIs natively, we can remove our scaffolding and leave standing a truly distributed protocol. Best of all, web sites don’t have to change a line of code for that to happen: as the identity providers and browsers start supporting BrowserID, our scaffolding automatically fades away. And let’s say you’re a web developer and you want to stop using BrowserID for whatever reason: just send your users an email with their new password, and you’re done. No other identity system minimizes lock-in this much, for both users and web developers.

TN – So minimizing lock-in is part of the BrowserID design goals?

BA – Absolutely! This is part of our mission and manifesto. We don’t want to own users, we want to empower them. Mozilla is in a unique position to build this kind of identity system because, as we all like to say, Mozilla answers only to users, and we can leverage Firefox to deploy these pro-user designs.

TN – Fantastic! What would you recommend to Websites who want to do a test-run on their site? And for users who want to experience BrowserID right away?

BA – Web developers can check out our documentation. Users can check out http://current.openphoto.me, a very promising distributed photo storage system shepherded by WebFWD that chose BrowserID. Just click the distinctive BrowserID login button to get a taste of the user experience.

TN – I’m sure our readers will try it right away! Thanks a lot Ben for your time. Long live BrowserID!

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.

Moving pictures have always fascinated people. From the first zoetropes to the multi million dollar blockbusters of today – seeing things move grabs our attention as humans much better than any clever copy or imagery could. Video was alien to the web for a long time. Well, not alien, but we needed plugins to make them play. With newer browsers and HTML5, we now have the <video> element to natively embed video in a web page. This allows us to, amongst other things:

• Style video elements with CSS and SVG
• Make the video interact with other elements of the document and vice versa
• Use Canvas to grab frames from videos and manipulate them
• Create accessible video as the controls can be used with a keyboard without us having to write that functionality

Using this arsenal, you can do pretty cool things. You can:

• write a player that rotates and zooms video (source on GitHub)
• Build your own Indiana Jones style maps (GitHub)
• Put your colleagues in a washing machine
• Simulate a green screen
• Apply CSS3 and SVG filters and transitions to video
• Inject other content into videos
• Stretch a video over the whole screen
• Use video in a 3D environment
• Allow users to take screengrabs of videos (source on GitHub)

..and many more things.

Now it is your turn to show us what you can do with HTML5 video! We don’t expect you to build another Wilderness Downtown or 3 Dreams of Black, but we are very excited to offer you the chance to shine in July’s Mozilla Dev Derby.

Why not use CSS3 and Canvas to redesign the Outer Limits intro? Why not make the video do the things Diana Ross talks about in Upside down? Why not build a video cropping tool in Canvas? How about you have a crack at making closed captioning and subtitling work with HTML5 video? There are many ideas floating about – it just needs a bit of drive and a text editor to go for it. So, show us what you can do!

There are a lot of tools out there to make your life easier with HTML5 video. Vid.ly makes it easy to convert videos, Popcorn.js is a library to sync page content and video and there are many tutorials on video available.

To get you into the mood and see some examples in action, we are running an HTML5 video webinar on the 14th of July and you can ask some questions you have upfront using Google Moderator.

Bring the web screen alive, I dare you! I am off to watch Cinema Paradiso again.

Screencast:

Youtube link.

Gorgeous Animations

The principal feature show-cased in this demo is CSS3 Transitions. The animation between the welcome-screen and the planet-screen, and the animation between the different planets are powered by transitions. But there are many little effects in this demo. Take a look at the Twitter button, the ruler, the credit page or the back button. These effects are CSS3 Transitions too.

Another interesting detail. Next to the planet, you have some different animations. The way the animations is played depends on if you’re coming from the left, the right or from the home screen.

Try it yourself: Click on the planet Earth, from the home screen. See the text “falling” from the top? Now, go to Mars, and come back to Earth. Now the text is “flying” from the right. Designers will love that :)

Beautiful fonts

@font-face allows you to use your own font for creative design. Combined with text-shadow and font-feature-settings, you can accurately forge and style your typographic content.

Your turn!

These are features you can use today.
This demo works perfectly in Firefox 4, Safari and Chrome. Also, Transitions and font-face are easily degradable. Go. Check out the source code, read the documention, and if you’re proud of your code, feel free to submit a demo!

Firefox 4 Beta 1 already brought a large amount of new features (see the Beta 1 feature list). So what’s new for web developers in this beta?

Performance & CSS3 Transitions

The two major features for web developers with this release are Performance improvements and CSS3 Transitions on CSS3 Transforms.

This video is hosted by Youtube and uses the HTML5 video tag if you have enabled it (see here). Youtube video here.

Performance: In this new Beta, Firefox comes with a new page building mechanism: Retained Layers. This mechanism provides noticeable faster speed for web pages with dynamic content, and scrolling is much smoother. Also, we’re still experimenting with hardware acceleration: using the GPU to render and build some parts of the web page.

CSS3 Transitions on transforms: The major change for web developers is probably CSS3 Transitions on CSS3 Transformations.

CSS3 Transitions provide a way to animate changes to CSS properties, instead of having the changes take effect instantly. See the documentation for details.

This feature was available in Firefox 4 Beta 1, but in this new Beta, you can use Transitions on Transformation.

A CSS3 Transformation allows you to define a Transformation (scale, translate, skew) on any HTML element. And you can animate this transformation with the transitions.

#victim {
  background-color: yellow;
  color: black;
 
  transition-duration: 1s;
  transform: rotate(10deg);
 
  /* Prefixes */
 
  -moz-transition-duration: 1s;
  -moz-transform: rotate(5deg);
 
  -webkit-transition-duration: 1s;
  -webkit-transform: rotate(10deg);
 
  -o-transition-duration: 1s;
  -o-transform: rotate(10deg);
}
#victim:hover {
  background-color: red;
  color: white;
 
  transform:  rotate(350deg) scale(1.4) rotate(-30deg);
 
  /* Prefixes */
 
  -moz-transform:  rotate(350deg) scale(1.4) rotate(-30deg);
  -webkit-transform:  rotate(350deg) scale(1.4) rotate(-30deg);
  -o-transform:  rotate(350deg) scale(1.4) rotate(-30deg);
}

CSS 3 Transitions are supported by Webkit-based browsers (Safari and Chrome), Opera and now Firefox as well. Degradation (if not supported) is graceful (no animation, but the style is still applied). Therefore, you can start using it right away.

Demos

I’ve written a couple of demos to show both CSS3 Transitions on Transforms and hardware acceleration (See the video above for screencasts).

This demo shows 5 videos. The videos are Black&White in the thumbnails (using a SVG Filter) and colorful when real size (click on them). The “whirly” effect is done with CSS Transitions. Move you mouse over the video, you’ll see a question mark (?) button. Click on it to have the details about the video and to see another SVG Filter applied (feGaussianBlur).

This page shows 2 videos. The top left video is a round video (thanks to SVG clip-path) with SVG controls. The main video is clickable (magnifies the video). The text on top of the video is clickable as well, to send it to the background using CSS Transitions.

This page is a simple list of images, video and canvas elements. Clicking on an element will apply a CSS Transform to the page itself with a transition. White elements are clickable (play video or bring a WebGL object). I encourage you to use a hardware accelerated and a WebGL capable browser. For Firefox on Windows, you should enable Direct2D.

Credits

Creative Commons videos:

• Ian Broyles
• Spoony Mushroom
• Mark Sebastian: [1] [2]
• Swanky
• Spiral Production

The multicolor cloud effect (MIT License)

• Professor Cloud

Last night I landed support for :-moz-any() selector grouping. This allows providing alternatives between combinators, rather than having to repeat the entire selector for once piece that’s different. For example, it allowed replacing this rule in our user-agent style sheet:

/* 3 deep (or more) unordered lists use a square */
ol ol ul,     ol ul ul,     ol menu ul,     ol dir ul,
ol ol menu,   ol ul menu,   ol menu menu,   ol dir menu,
ol ol dir,    ol ul dir,    ol menu dir,    ol dir dir,
ul ol ul,     ul ul ul,     ul menu ul,     ul dir ul,
ul ol menu,   ul ul menu,   ul menu menu,   ul dir menu,
ul ol dir,    ul ul dir,    ul menu dir,    ul dir dir,
menu ol ul,   menu ul ul,   menu menu ul,   menu dir ul,
menu ol menu, menu ul menu, menu menu menu, menu dir menu,
menu ol dir,  menu ul dir,  menu menu dir,  menu dir dir,
dir ol ul,    dir ul ul,    dir menu ul,    dir dir ul,
dir ol menu,  dir ul menu,  dir menu menu,  dir dir menu,
dir ol dir,   dir ul dir,   dir menu dir,   dir dir dir {
  list-style-type: square;
}

with this one:

/* 3 deep (or more) unordered lists use a square */
:-moz-any(ol, ul, menu, dir) :-moz-any(ol, ul, menu, dir) ul,
:-moz-any(ol, ul, menu, dir) :-moz-any(ol, ul, menu, dir) menu,
:-moz-any(ol, ul, menu, dir) :-moz-any(ol, ul, menu, dir) dir {
  list-style-type: square;
}

In theory, I could even have used:

/* 3 deep (or more) unordered lists use a square */
:-moz-any(ol, ul, menu, dir) :-moz-any(ol, ul, menu, dir) :-moz-any(ul, menu, dir) {
  list-style-type: square;
}

but this would have been slower since it no longer falls into the tag bucket. (If :-moz-any() turns out to be popular, we could add extra code so it’s just as fast, but I haven’t done so yet.)

:-moz-any() is allowed to contain selectors with multiple simple selectors (using the css3-selectors definition of simple selectors, not the CSS 2.1 definition), but it is not allowed to contain combinators or pseudo-elements. So you can write :-moz-any(p.warning.new, p.error, div#topnotice) or :-moz-any(:link, :visited).external:-moz-any(:active, :focus), but you can’t put “div p” or “div > p or “:first-letter” inside :-moz-any().

This has a -moz- prefix for two reasons. First, it’s just a proposal, and hasn’t made its way into any specification. And second, it isn’t quite ready for prime-time, though, since it doesn’t yet handle specificity correctly.

Note: This will be extremely valuable in an HTML5 context when it comes to sections and headings. Since section, article, aside, and nav can be nested, doing something like styling all h1 elements at different depths could be extremely complex.

/* Level 0 */
h1 {
  font-size: 30px;
}
/* Level 1 */
section h1, article h1, aside h1, nav h1 {
  font-size: 25px;
}
/* Level 2 */
section section h1, section article h1, section aside h1, section nav h1,
article section h1, article article h1, article aside h1, article nav h1,
aside section h1, aside article h1, aside aside h1, aside nav h1,
nav section h1, nav article h1, nav aside h1, nav nav h1, {
  font-size: 20px;
}
/* Level 3 */
/* ... don't even think about it*/

With -moz-any():

/* Level 0 */
h1 {
  font-size: 30px;
}
/* Level 1 */
-moz-any(section, article, aside, nav) h1 {
  font-size: 25px;
}
/* Level 2 */
-moz-any(section, article, aside, nav)
-moz-any(section, article, aside, nav) h1 {
  font-size: 20px;
}
/* Level 3 */
-moz-any(section, article, aside, nav)
-moz-any(section, article, aside, nav)
-moz-any(section, article, aside, nav) h1 {
  font-size: 15px;
}

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.

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

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

This is what we do to trace:

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

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

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

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

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

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

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

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

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

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

Out of Process Plugins

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

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

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

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

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

Web Developer Features

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

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

Performance Improvements

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

The input tag

To let your user select a local file, use the input tag on your Web page. This will show the file picker to the user:

<input type="file"/>

In Firefox 3.6, the input tag has been expanded to support multiple files:

<input type="file" multiple=""/>

The user will still see the same file picker, but will be able to select more than one file.

The form tag

You can still use the classic form mechanism:

<form method="post" action="upload.php" enctype="multipart/form-data">
  <input name='uploads[]' type="file" multiple=""/>
  <input type="submit" value="Send">
</form>

If the server side code is in PHP, don’t forget to make sure that the value of the name attribute has brackets. The brackets are not from the HTML specification, but are required to manipulate the result of the request as an array (see PHP documentation).

Here’s an example, which goes through the file list and prints each file name:

foreach ($_FILES['uploads']['name'] as $filename) {
    echo '<li>' . $filename . '</li>';
}

Using File API

Firefox 3.6 also supports FileAPI. This allows you to do extra processing on the client slide before sending the files to the server. You can access the selected files with the files property of the input DOM element and then manipulate the files using the FileAPI.

For example, here’s how to get the name of each file selected by the user. This is done on the client side, unlike the previous PHP example.

  var input = document.querySelector("input[type='file']");
  // You've selected input.files.length files
  for (var i = 0; i < input.files.length; i++) {
    // input.files[i] is a file object
    var li = document.createElement("li");
    li.innerHTML = input.files[i].name;
    ul.appendChild(li);
  }

Demo

See this mechanism in action in our multiple file input demo. You’ll need Firefox 3.6 (beta).

Documentation

To learn more about multiple file input, check out the documentation on MDC.

It is important to note that even before the advent of the W3C File API draft (which only became a Working Draft in November 2009), Firefox 3 and later provide the ability to read files into memory synchronously but that capability should be considered deprecated in favor of the new implementation in Firefox 3.6 of the asynchronous File API. The deprecated API allowed you synchronously access a file:

// After obtaining a handle to a file
// access the file data
var dataURL = file.getAsDataURL();
img.src = dataURL;

While Firefox 3.6 will continue to support code usage of the sort above, it should be considered deprecated since it reads files synchronously on the main thread. For large files, this could result in blocking on the result of the read, which isn’t desirable. Moreover, the file object itself provides a method to read from it, rather than having a separate reader object. These considerations informed the technical direction of the new File API in Firefox 3.6 (and the direction of the specification). The rest of this article is about the newly introduced File API.

Accessing file selections

Firefox 3.6 supports multiple file selections on an input element, and returns all the files selected using the FileList interface. Previous versions of Firefox only supported one selection of a file using the input element. Additionally, the FileList interface is also exposed to the HTML5 Drag and Drop API as a property of the DataTransfer interface. Users can drag and drop multiple files to a drop target within a web page as well.

The following HTML spawns the standard file picker, with which you can select multiple files:

<input id="inputFiles" type="file" multiple="" />

Note that if you don’t use the multiple attribute, you only enable single file selection.

You can work with all the selected files obtained either through the file picker (using the input element) or through the DataTransfer object by iterating through the FileList:

var files = document.getElementById("inputFiles").files;
 
// or, for a drag event e:
// var dt = e.dataTransfer; var files = dt.files
 
for (var i = 0; i < files.length; i++) {
  var file = files[i];
  handleFile(file);
 
}

Properties of files

Once you obtain a reference to an individually selected file from a FileList, you get a File object, which has name, type, and size properties. Continuing with the code snippet above:

function handleFile(file) {
    // RegExp for JPEG mime type
    var imageType = /image\/jpeg/;
 
    // Check if match
    if (!file.type.match(imageType)) {
        return false;
    }
   // Check if the picture exceeds set limit
   if(file.size > maxSize) {
      alert("Choose a smaller photo!");
      return false;
   }
  // Add file name to page
  var picData = document.createTextNode(file.name);
  dataGrid.appendChild(picData);
  return true;
}

The size attribute is the file’s size, in bytes. The name attribute is the file’s name, without path information. The type attribute is an ASCII-encoded string in lower case representing the media type of the file, expressed as an RFC2046 MIME type. The type attribute in particular is useful in sniffing file type, as in the example above, where the script determines if the file in question is a JPEG file. If Firefox 3.6 cannot determine the file’s type, it will return the empty string.

Reading Files

Firefox 3.6 and beyond support the FileReader object to read file data asynchronously into memory, using event callbacks to mark progress. The object is instantiated in the standard way:

var binaryReader = new FileReader();

Event handler attributes are used to work with the result of the file read operation. For very large files, it is possible to watch for progress events as the file is being read into memory (using the onprogress event handler attribute to set the event handler function). This is useful in scenarios where the drives in question may not be local to the hardware, or if the file in question is particularly big.

The FileReader object supports three methods to read files into memory. Each allows programmatic access to the files data in a different format, though in practice only one read method should be called on a given FileReader object:

• filereader.readAsBinaryString(file); will asynchronously return a binary string with each byte represented by an integer in the range [0..255]. This is useful for binary manipulations of a file’s data, for example to look for ID3 tags in an MP3 file, or to look for EXIF data in a JPEG image.
• filereader.readAsText(file, encoding); will asynchronously return a string in the format solicited by the encoding parameter (for example encoding = "UTF-8"). This is useful for working with a text file, for example to parse an XML file.
• filereader.readAsDataURL(file); will asynchronously return a Data URL. Firefox 3.6 allows large URLs, and so this feature is particularly useful when a URL could help display media content in a web page, for example for image data, video data, or audio data.

An example helps tie this all together:

if (files.length > 0) {
    if (!handleFile(files[0])) {
        invalid.style.visibility="visible";
        invalid.msg = "Select a JPEG Image";
     }
}
 
var binaryReader = new FileReader();
binaryReader.onload = function(){
   var exif = findEXIFInJPG(binaryReader.result);
   if (!exif) {
      // ...set up conditions for lack of data
   }
   else {
    // ...write out exif data
   }
 
binaryReader.onprogress = updateProgress;
binaryReader.onerror = errorHandler;
 
binaryReader.readAsBinaryString(file);
 
function updateProgress(evt){
   // use lengthComputable, loaded, and total on ProgressEvent
   if (evt.lengthComputable) {
          var loaded = (evt.loaded / evt.total);
          if (loaded < 1) {
            // update progress meter
            progMeter.style.width = (loaded * 200) + "px";
          }
   }
}
 
function errorHandler(evt) {
  if(evt.target.error.code == evt.target.error.NOT_FOUND_ERR) {
   alert("File Not Found!");
  }
}

In order to work with binary data, the use of the charCodeAt function exposed on strings will be particularly useful. For instance, an utility of the sort:

function getByteAt(file, idx) {
    return file.charCodeAt(idx);
}

allows extraction of the Unicode value of the character at the given index.

An example of similar code in action in Firefox 3.6, including use of the readAsDataURL method to render an image, as well as binary analysis of a JPEG for EXIF detection (using the readAsBinaryString method), can be found in Paul Rouget’s great demo of the File API..

A word on the specification

The existence of a W3C public working draft of the File API holds the promise of other browsers implementing it shortly. Firefox 3.6′s implementation is fairly complete, but is missing some of the technology mentioned in the specification. Notably, the urn feature on the File object isn’t yet implemented, and neither is the ability to extract byte-ranges of files using the slice method. A synchronous way to read files isn’t yet implemented as part of Worker Threads. These features will come in future versions of Firefox.

References

• The W3C File API Specification
• MDC: Using files within web applications
• MDC: FileList
• MDC: File
• MDC: FileReader
• MDC: Drag and Drop

For SVG you can set the pointer-events property to one of several values, but for HTML you can only set it to one of two values: auto or none.

.foo {
  pointer-events: none;
}

When pointer-events is set to none, pointer events are passed through the target element and are instead sent to the element that is underneath it.

.foo {
  pointer-events: auto;
}

When pointer-events is set to auto, pointer events are handled normally. That is, the element blocks the events from being passed down to a lower element.

Here’s a real world example from Paul Rouget. You will need a Firefox 3.6 beta to see it in action.

Click the pointer-events: none checkbox under the image to see it change.

He’s replicated the tag list that’s on the front page of twitter.com. (Note: you have to not be logged in to see the tag list.) If you go and look at it on twitter you’ll notice that it fades off on the right hand side. This is done with a transparent, faded image that sits on top of the underlying box. The tags underneath are clickable links but the image blocks events from being sent to the ones underneath the fade.

What Paul has done is show how you can use the pointer-events property to allow you to click on the underlying links even with a fade on top of it.

If you are running the latest beta of Firefox 3.6, you should check out our interactive demo and take a look at the corresponding code. Use the radio buttons to switch different style options on or off.

Backgrounds with CSS Gradients

Using CSS gradients in a background allows you to display smooth transitions between two or more specified colors without having to use images. This in turn reduces download time and bandwidth use, looks better while zooming, and lets you create a more flexible layout.

Firefox 3.6 supports two kinds of CSS gradients: linear (-moz-linear-gradient) and radial (-moz-radial-gradient).

Linear Gradients

To create a linear gradient, you’ll need to set a starting point and a direction (or angle) for the gradient and to define the color stops.

 -moz-linear-gradient( [<point> || <angle>,]? <stop>, <stop> [, <stop>]* )

Starting Point. The starting point works just like background position. You can set the horizontal and the vertical positions as a percentage, in pixels, or using left/center/right for horizontal, and top/center/bottom for vertical. Positions start from the top left corner. If you don’t specify the horizontal or the vertical position, it will default to center.

For example, here’s a linear gradient that starts at the center (horizontal) and top (vertical), and goes from blue to white:

  .linear_gradient_square {
    width: 100px;
    height: 100px;
    border: 1px solid #333;
    background: -moz-linear-gradient(top, blue, white);
  }

One that starts left (horizontal) and center (vertical):

    background: -moz-linear-gradient(left, blue, white);

And a gradient starting left (horizontal) and top (vertical):

    background: -moz-linear-gradient(left top, blue, white);

Angle. As you can see above, if you don’t specify an angle, it is defined automatically based on the start position. If you would like more control over the direction of the gradient, you can set the angle as well.

For example, the following gradients have the same starting point of left center, but the one on the right hand-side also has an angle of 20 degrees.

    background: -moz-linear-gradient(left 20deg, black, white);

When specifying the angle, remember that is it the angle between a horizontal line and the gradient line, going counter-clockwise. So using 0deg will generate a left to right horizontal gradient, while 90deg will create a vertical gradient from the bottom to the top.

    background: -moz-linear-gradient(<angle>, red, white);

Color Stops. In addition to start position and angle, you should specify color stops. Color stops are points along the gradient line that will have the specified color at the specified location (set as a percentage or length). The number of color stops is unlimited. If you use a percentage for the location, 0% represents the starting point, and 100% is the ending point, but values above and below those can be used to achieve the desired effect.

Here’s a simple example with three color stops. Because no point is specified for the first and last colors, they will default to 0% and 100%.

    background: -moz-linear-gradient(top, blue, white 80%, orange);

Colors will be evenly spaced if no position is specified.

    background: -moz-linear-gradient(left, red, orange, yellow, green, blue);

Transparency. Gradients also support transparency. This can be useful, for example, when stacking multiple backgrounds. Here’s a combination of two backgrounds: one image and one linear gradient from white to transparent white.

.multibackground_transparent {
    background: -moz-linear-gradient(right, rgba(255,255,255,0), rgba(255,255,255,1)), url(http://demos.hacks.mozilla.org/openweb/resources/images/patterns/flowers-pattern.jpg);
}

Radial Gradients

The syntax for radial gradients is very similar to that of linear gradients:

 -moz-radial-gradient([<bg-position> || <angle>,]? [<shape> || <size>,]? <color-stop>, <color-stop>[, <color-stop>]*);

In addition to the start position, the direction, and the colors, which you have already seen in linear gradients, radial gradients allow you to specify the gradient’s shape (circle or ellipse) and size (closest-side, closest-corner, farthest-side, farthest-corner, contain or cover).

Color stops. Just like with linear gradients, you should define color stops along the gradient line. The following circles have the same color stops, but the gradient on the left defaults to evenly spaced colors, while the one on the right has a specific position for each color.

 background: -moz-radial-gradient(red, yellow, #1E90FF);
 background: -moz-radial-gradient(red 5%, yellow 25%, #1E90FF 50%);

Shape. Here you can see the difference between the two possible shapes, a circle (on the left) and an ellipse (on the right), both with a bottom left starting point:

 .radial_gradient_circle {
    background: -moz-radial-gradient(bottom left, circle, red, yellow, #1E90FF);
}
 .radial_gradient_ellipse {
    background: -moz-radial-gradient(bottom left, ellipse, red, yellow, #1E90FF);
}

Size. The different options for size (closest-side, closest-corner, farthest-side, farthest-corner, contain or cover) refer to the point used to define the size of the circle or ellipse.

Example: closest-side vs. farthest corner for an ellipse.
The following two ellipses have different sizes. The one on the left is set by the distance from the start point (center) to the closest-side, while the one on the right is determined by the distance from the start point to the farthest corner.

  background: -moz-radial-gradient(ellipse closest-side, red, yellow 10%, #1E90FF 50%, white);
  background: -moz-radial-gradient(ellipse farthest-corner, red, yellow 10%, #1E90FF 50%, white);

Example: closest-side vs. farthest-side for a circle.
The size of the circle on the left is determined by the distance between the start point (the center) and the closest side, while the one on the right is the distance between the start point and the farthest side.

 background: -moz-radial-gradient(circle closest-side, red, yellow 10%, #1E90FF 50%, white);
 background: -moz-radial-gradient(circle farthest-side, red, yellow 10%, #1E90FF 50%, white);

Example: contained circle.
Here you can see the default circle on the left, and the version of the same gradient but contained on the right.

 background: -moz-radial-gradient(red, yellow, #1E90FF);
 background: -moz-radial-gradient(contain, red, yellow, #1E90FF);

Repeating Gradients

If you would like to repeat a gradient, you should use -moz-repeating-linear-gradient and -moz-repeating-radial-gradient.

In the examples below, four color stops are specified in each case, and are repeated indefinitely.

 .repeating_radial_gradient_example {
    background: -moz-repeating-radial-gradient(black, black 5px, white 5px, white 10px);
}
 .repeating_linear_gradient_example {
     background: -moz-repeating-linear-gradient(top left -45deg, red, red 5px, white 5px, white 10px);
}

Demo

Check out our interactive demo of linear and radial gradients for more examples.

Note that the gradient syntax has changed between Firefox 3.6 beta 1 and beta 2, so if you used gradients with beta 1, you may need to update your code.

If you’ve ever been editing a page and wanted to know what a particular font looked like without having to upload files to a web server and update CSS (so tedious, that!) then this demo is for you.

He’s come up with a demo that shows what’s possible when you’ve got downloadable fonts, drag and drop and editable content. (If you want to know more about drag and drop we suggest you read his excellent overview of using drag and drop to do file uploading.)

From Ryan’s description:

Font dragr is an experimental web app that uses HTML5 & CSS3 to create a useful standalone web based application for testing custom fonts, once you visit it for the first time you don’t need to be online to use it after the initial visit. It allows you, in Firefox 3.6+, to drag and drop font files from your file system into the drop area. The browser will then create a data URL encoded copy to use in the page and render the content in the dropped font.

You can either read the full description, which contains a lot of useful technical information about how the demo works, or you can view the demo below. Either way, it’s nice to see the excellent HTML5 support in Firefox 3.6 coming together with everything else we’ve added to bring a lot of new capabilities to web developers and users.

Thanks, Ryan!

One new feature that we’re including as part of Firefox 3.6 is support for web pages to access machine orientation information if it’s available. As you can see from the demo above you can use it to figure out if the machine is moving and what direction it’s facing.

Using the API is very simple. All you have to do is add a simple event listener:

window.addEventListener("MozOrientation", function(e) {
                        /* 3 values: e.x, e.y, e.z */
                        }, true);

Originally built as something that we would include for our upcoming mobile browser release, we’ve made it available on desktop systems as well. Many modern Macbooks and Thinkpads contain devices and drivers that expose this information. We’ve added support for Linux, Macs and some Thinkpads where drivers and devices are available. (Note, on some Macbooks detect the orientation information backwards – we’re working on that.)

You can find more information on two posts by Doug Turner and an update on documentation for orientation from Eric Shepherd.

Paul Rouget has this and some other demos up in one of his posts.

This post is targeted at web developers and gives a quick overview of the three kinds of attacks that CSP helps to mitigate and also gives some quick examples so developers can get a sense of how it will work for them.

In case you don’t know what our Content Security Policy code is – and based on anecdotal evidence a lot of people don’t – it’s a set of easy to use tools that allow a web site owner to tell the browser where it should or should not load resources from. In particular it aims to prevent three different classes of common attacks we see on the web today: cross-site scripting, clickjacking and packet sniffing attacks.

Cross-site scripting attacks are largely the result of a mistake made on backend web servers where someone fails to escape data that’s submitted by users. When that happens it’s possible to inject a tag to load JavaScript code from another web site. That code could be harmless but it could also contain something dangerous, like malware. What CSP does is make it possible for a web site author, via HTTP headers, to specify what types of scripts can be loaded and from where. For developers who are setting a policy, it adds a layer of protection where even if they make a mistake it is likely to be mitigated by this additional layer of policy.

Clickjacking attacks are where someone embeds a page into a transparent iframe and “steals” user clicks to activate something dangerous. One particular attack allows a browser to be turned into a remote surveillance device. CSP includes the ability for a page to tell the browser that it never wants to be ever included in an iframe.

And last is the ability for a web site to tell the browser that it never wants resources from that page to be loaded over unencrypted HTTP. Banking and other commerce sites will find this particularly useful.

CSP is very powerful and flexible, allowing you to specify whether or not you want to load different kinds of media, different kinds of script methods, css, can be used to set up loading only from specific other hosts and a large number of other things. It’s meant to be very easy to set up for simple cases but will scale up to pretty complex infrastructure where different resources might be spread out over a large number of machines.

Here are four examples that show common use cases. Each of these examples is a header that’s delivered as a header over HTTP and it affects how the page is rendered.

A site wants all of its content to come from its own domain:

X-Content-Security-Policy: allow 'self'

Example 2: An auction site wants to be able to load images from anywhere, plugin content from a list of trusted media providers and a CDN network and scripts only from its server hosting sanitized JavaScript:

X-Content-Security-Policy: allow 'self'; img-src *; \
                           object-src media1.com media2.com *.cdn.com; \
                           script-src trustedscripts.example.com

Example 3: Server administrators want to deny all third-party scripts for the site, and a given project group also wants to disallow media from other sites (header provided by sysadmins and header provided by project group are both present):

X-Content-Security-Policy: allow *; script-src 'self'
X-Content-Security-Policy: allow *; script-src 'self'; media-src 'self';

Example 4: An online payments site wants to ensure that all of the content in its page is loaded over SSL to prevent attackers from eavesdropping on requests for insecure content:

X-Content-Security-Policy: allow https://*:443

The implementation isn’t quite complete yet, but it’s pretty close. There’s more information on the demo page for CSP, read the overview or read the spec itself.

Web developers will be interested in a number of features that are new in Firefox 3.6 Alpha 1:

• The TraceMonkey JavaScript engine has continued to get faster.
• We’ve made a huge number of improvements to overall DOM and element layout performance. In some cases we’re much, much faster. We’ll cover details on those in a later post.
• The compositor landing has made it possible to fix a large number of interactions between web content, CSS and plugins. We’ll be talking about this in a later post as well.
• We now support the -moz-background-size CSS property which lets you set the size of background images.
• We now support CSS Gradients.
• We now support multiple background images.
• We now support the rem unit as a CSS unit.
• image-rendering is supported for images, background images, videos and canvases.
• We now send a reorder event to embedded frames and iframes when their document is loaded.
• We’ve removed the getBoxObjectFor() method. It was non-standard and exposed all kinds of non-standard stuff to the web.
• We now send a hashchange event to a page whenever the URI part after the # changes.
• We now have Geolocation address support for user-readable position information.
• We now support the complete attribute on document.readystate.

You can keep track of this list and other features for XUL and add-ons developers on the Firefox 3.6 for developers page on developer.mozilla.org

Unlike the year that passed between Firefox 3 and Firefox 3.5, we expect that this 3.6 release will be released in a small number of months. Our main focus for the 3.6 release will be end-user perceived performance, TraceMonkey and DOM performance and new web developer features.

Enjoy and test away!