Featured Articles

At Mozilla, we are dedicated to keep the web open and independent of a single company or technology. This means that users should have a choice of browsers and technology to use to go online and should not be blocked out because they can’t afford a certain device or are forbidden to change their browser.

In the world of mobile web development there is currently a massive debate going on about the need for support of various browsers seeing that the most successful phone systems both use the same browser engine. This is good, and we need this debate. It is not good though when developers block out users because they concentrate on targetting a browser. Sometimes this is not by choice of the developer – they are simply using tools that do that blocking for them and the usefulness of the tool outweighs the qualms developers have about that.

We are currently talking to library and tool developers and help them support more than one browser engine to prevent this. As a start of that process we wanted to get a glimpse of what people are using right now so we make sure we have the most impact when we help. This is why we conducted an online survey asking developers about their tools for mobile development.

590 developers took the survey and we are thankful for them spending their time giving us a lot to ponder and think about.

We are very aware that this is *not* a scientifically clean research and should be taken with a grain of salt (we haven’t asked how many times people used the tools or how much of their work is building mobile apps) but it gives us a good idea of what is going on.

So without further ado, here are the numbers as charts with a quick commentary:

Platforms

A lot of developers showed their love for the web in this survey, but then again it was a survey initiated by Mozilla. Most likely an Apple-lead survey would have different results. iOS and Android are the follow-up and Windows Phone and Blackberry are less of a concern for the developers who filled the survey. This, of course, could differ greatly were we do to this survey targetted to different markets. Interesting that in the case of Android the amount of “must have” is higher than “focus” – the only platform showing this.

You can compare the results dynamically here.

What platforms are you targeting with your apps – Web
	focus 370 63% must have 153 26% supported 33 6% sometimes 23 4% not at all 11 2%

What platforms are you targeting with your apps – iOS
	focus 261 44% must have 207 35% supported 53 9% sometimes 28 5% not at all 41 7%

What platforms are you targeting with your apps – Android
	focus 182 31% must have 221 37% supported 102 17% sometimes 47 8% not at all 38 6%

What platforms are you targeting with your apps – Windows phone
	focus 10 2% must have 46 8% supported 131 22% sometimes 173 29% not at all 230 39%

What platforms are you targeting with your apps – Blackberry
	focus 8 1% must have 15 3% supported 100 17% sometimes 164 28% not at all 303 51%

People may select more than one checkbox, so percentages may add up to more than 100%.

Libraries

In the world of libraries jQuery and jQuery mobile very much took the lead with more than 200 more uses than the next follower Zepto.js. A lot of feedback was that developers don’t like libraries and use their own hand-rolled solutions on mobile instead. While it is good to see that libraries that work cross-browser are the most used ones (jQuery just announced that they happily support Firefox mobile), the high number of Sencha users is worrying and we’ll see how we can help make their cross-browser support better. Sencha was also mentioned a lot in the “why webkit only” question which shows that it is an important tool for developers.

What libraries do you use to build mobile web apps/sites?
	jQuery 437 74% jQuery mobile 301 51% Zepto.js 116 20% JO 5 1% XUI.js 23 4% Sproutcore 9 2% Sencha touch 88 15% JQTouch 61 10% Mootools mobile 16 3% M project 1 0% Nimblekit 2 0% Lime.js 10 2% Wink 2 0% Uxebu Bikeshed 1 0% Other 152 26%

People may select more than one checkbox, so percentages may add up to more than 100%.

All in all we collected 66 libraries (in order of popularity): jQuery, jQuery mobile, Zepto.js, Sencha Touch, JQTouch, XUI.js, Backbone, Mootools mobile, Lime.js, Sproutcore, Angular JS, Underscore, Bootstrap , Enyo, Modernizr, Dojo, handlebars, JO, Closure, Dojo Toolkit, GWT, Hammer.js, iScroll, require.js, YUI, Chibi, Ember.js, Kendo, Kinetic, Lungo.js, Nimblekit, Prototype, Wink, Adobe Air, Atto, Box2D, ChesterGL, Cobra, Crafty, Cujo, d3.js, Dart , Dojo Mobile, Dojo Mini, enhance.js, Eyebrow.js, fitml, gl-matrix, H5BP, JQMobi, Javelin, Jukebox, Knockout, MProject, Mootools, Openlayers, Path , Playcanvas, pointer.js, Raphael, Sugar.js, TerrificJS, Thorax, Titanium Mobile, Uxebu bikeshed, Wakanda

Conversion frameworks

There is no doubt that Phonegap / Cordova rules this segment of the market followed by Appcelerator. Quite a lot of feedback was also people claiming that native apps should be coded natively. Being a web evangelist, I disagree as you can not convert from native to web but the other way around, but it is interesting to see that developers felt the need to have their say here.

Which frameworks do you use to convert apps to native apps?
	PhoneGap 325 90% Appcellerator 50 14% MoSync 2 1% Other 38 10%

People may select more than one checkbox, so percentages may add up to more than 100%.

All in all we collected 13 conversion tools (in order of popularity): Phonegap, Adobe Air, Apache Cordova, Cocoon.js, Brightcove App Cloud, Mosync, Sencha Native SDK, appMobi, Flex Mobile, Mobileweb, Monotouch and backbone.

Visual editors

Not many developers seem to use visual editors, which is probably because most of them are still in a “beta” or “alpha” stage. It would be interesting to do the same survey with Flash developers who are moving towards HTML5 and see if the numbers are higher. As it stands, Adobe Edge and Sencha Animator are the clear winners, and some of the entries were interesting including one “you got to be kidding me” :).

Do you use any visual tools/converters to build apps? If so, which?
	Adobe Edge 19 36% Sencha Animator 10 19% Other 25 47%

People may select more than one checkbox, so percentages may add up to more than 100%.

All in all we collected 17 editors (in order of popularity): Adobe Edge, Sencha Animator, Adobe Dreamweaver, Adobe Flash, Adobe Photoshop, Codiqua, Construct 2, Hype, Playcanvas , Radi, Rhodes, Telrik, Tiggzi, Tiler, Wakanda, Web Developer Add-on, WebMatrix

Webkit only?

71% of developers filling out the survey said they test for more than Webkit browsers and in the general feedback section of the survey we had a lot of information as to how people are testing and what would make things much easier for them. This makes us happy of course.

Do you test on non-Webkit browsers?
	Yes 421 71% No 169 29%

Reasons to test for webkit only

The main reason here is a lack of time to test on other platforms which is understandable – we can assume that a lot of projects from a planning perspective have 99% iOS/Android written all over them. The “lack of incentive” number is high, too, which is understandable – if you can’t show the numbers, you don’t get the time to support. The high number of “not supported on hardware” is of course another very understandable reason and we wished there would be a way to change this.

Fixed environment defined by client needs		46	24%
Lack of time to support more browser platforms		103	55%
Lack of incentive – I don’t know what the benefit of supporting more is		79	42%
Lack of documentation how to install and debug on non-webkit browsers		43	23%
Bugginess of other browsers on test platforms		31	16%
Lack of support for other browsers on target hardware		68	36%
Other		20	11%

People may select more than one checkbox, so percentages may add up to more than 100%.

Webkit only technology

The question “What technologies/features do you use on Webkit browsers that are crucial for you and not available on others?” was answered by 135 developers and only partly answered what we needed to know. A lot of it wasn’t features of Webkit but general speed and availability reasons that are reliant on the operating system and the hardware. A lot of the answers also simply stated that these browsers come with the hardware which means end users have them and developers don’t have an overhead of installing other browsers or tools. However, quite a few developers praised the predictability of a “one browser platform web” and not having to worry about vendor prefixes and differences in html5 support.

What can mobile Firefox do better?

The question “If yes, what could Firefox mobile provide to make your life easier?” got around 230 answers and is a great resource for us to improve the browser. The message that came across loud and clear was the need for remote debugging for Firefox Android which was just announced here on the hacks blog. It is obvious that developers do not want to have a long gap between writing code and seeing the results on their phones – very understandable indeed. Quite in demand was also a native simulator for the Desktop to avoid the need of having a phone at all. Another thing that stood out was support for older and more hardware.

Anything else?

The “Anything else you want to get heard?” question got 73 answers with a lot of great feedback, especially praise for what is happening right now in the world of Mozilla and some very detailed concerns of developers. We now have a great time going through these answers and will see how we can accelerate a few of the demands in our next browser builds.

Check the results

We’ve uploaded the anonymised answers as a spreadsheet to Google Docs, so feel free to read and dig at your own leisure: Mozilla libraries survey.

A huge Thank You

Last but not least, we want to say Thank you! to everyone who participated. We now have a lot of insightful information and can focus our outreach to frameworks, tools and libraries that will have the most impact when it comes to supporting a cross-browser web. We were also very positively surprised that the trolling and fanboi-ing was kept to a bare minimum – this showed us that the topic really is important for all developers out there.

Back in May, I was lucky to go to Moscow, Russia, to speak at the .toster conference about JavaScript APIs and the web as a platform. Now I have the video together with the slides to share from that presentation.

I cover a lot of various JavaScript APIs, possibilities on the web and also new WebAPIs!

The video for JavaScript APIs – The Web is the Platform is available on YouTube. It is also embedded below:

(If you’ve opted in to HTML5 video on YouTube you will get that, otherwise it will fallback to Flash)

The slides that I use in the presentation are available on SlideShare, and also embedded here:

Last month, creative web developers from around the world showed us what they could do with WebGL in the June Dev Derby competition. After looking through the entries, our three expert judges—Guillermo Rauch, Peter Lubbers, and Rob Hawkes—have decided on three winners and two runners-up.

Not a contestant? There are other reasons to be excited. Most importantly, all of the entries are completely open-source, making them wonderful lessons in all of the exciting things you can do with WebGL today.

Winners

• SnappyTree by newcomer Paul Brunt
• Slice:Drop by newcomer Daniel Haehn
• Kai ‘Opua by newcomer Collin Hover

Runners-up

• 3d Grapher by sophomore guska076
• FLUID by veteran Emeric “boblemarin” Florence

Relatively few demos were submitted this time around, but the quality of the entries was outstanding. Each and every finalist has created something truly amazing, something that pushes WebGL forward in an inspiring way. And let’s not forget about the other jaw-dropping entries. Games, planets, maps, mirrors, and more — every entry is extremely impressive. Congratulations to all of our contestants!

Want to get a head start on an upcoming Derby? We are now accepting demos for the No JavaScript Challenge (July) and demos related to the Camera API (August). Get started today!

Further Reading

• Getting started with WebGL
• More MDN documentation on WebGL
• Learning WebGL tutorials

Web developers, it is time to celebrate! In the upcoming Firefox 16, which reached the Aurora status today, a major enhancement is the unprefixing of several stable CSS features. Other notable features of interest to Web developers include several more HTML5-related APIs, better accessibility on Mac OS, and improvements to Firefox Developer Tools.

So which CSS features are unprefixed?

Pay attention to the gradient syntax

While the syntax of CSS animations, transitions and transforms has not changed lately, that is not the case of the CSS gradients syntax, which is significantly different than in most prefixed implementations.

The definitive syntax for linear gradients is :

<linear-gradient> = linear-gradient([ [ <angle> | to <side-or-corner> ] ,]? <color-stop>[, <color-stop>]+ )
<side-or-corner> = [left | right] || [top | bottom]

If we break it down, its structure is :

linear-gradient( direction , color-stop )

As the color-stop syntax hasn’t evolved lately, the direction parameter is where most of the latest changes happened.

The direction parameter can be defined either using a CSS <angle>, or using the to keyword followed by one or two keywords describing the side or the corner.

That’s the major change! This to keyword wasn’t there before and it reverses the direction that was use previously: -prefix-linear-gradient( top left ) becomes linear-gradient( to bottom right ).

Also the <angle> changed: before, 0deg pointed to the right; now it points, consistently with other angles in the CSS spec, to the top. Like this:

So here again, you need to change -prefix-linear-gradient(0deg) to linear-gradient(90deg). Failure to adapt the angle will lead to the gradient to be oriented differently, like this:

→

Similar changes have been made to the radial gradient syntax, with a newly introduced at keyword.

More HTML5 & friends goodies

Unprefixing mature CSS features is not the only improvement in the area of supporting standards:

• IndexedDB has reached Candidate Recommendation status and has been unprefixed too. This is amazing.
• Support for the HTML5 Microdata API landed.
• Support for the HTML5 <meter> element landed.
• We unprefixed the Battery API.
• We unprefixed the Vibration API.
• We improved our media queries support by adding support for the dppx unit.
• The CSS properties height and width are now animatable.
• The CSS animations can be “reversed“:  the reverse and alternate-reverse keywords have been added.
• Our implementation of JavaScript improved with several new features in Harmony (the maybe future EcmaScript 6):
  • Support for direct proxies
  • Support for the Array‘s spread operator
  • Improvement of Number, supporting now toInteger(), isInteger() and isFinite()
• Improvement of Keyboard (still prefixed as mozKeyboard), now supporting setSelectedOption(), setValue() and onfocuschange().

Accessiblity

A giant step has been done in making Firefox more accessible. Support for VoiceOver on Mac OS has landed. It was the last platform where our accessibility features where severely behind. This is very exciting for all people needing such features on the Mac. More information.

Developers Tools

Last but not least, we continued to improved our developer tools!

Now you can toggle a developer toolbar: go to Tools > Web Developer > Developer Toolbar, or press Shift-F2. The toolbar itself looks like this:

The toolbar has a command line interface and also nice buttons to the right to quickly reach useful tools. The command line interface is easy to expand and more commands are expected in the future. Typing help in it displays the supported commands.

The Web Console also has been improved and displays now a nifty error count.

Finally our Scratchpad gained a list of recently opened files. Always convenient.

Other notable changes

• We slightly changed our UA string not to display the 3rd digit of our versioning system.
• Incremental GC, a major part in our effort to revamp our Garbage Collector, is now enabled by default.
• Opus, a low-latency codec aimed at real-time communication, is enabled by default.
• By default, we do not accept anymore MD5 hashes in X.509 certificates.
• about:memory is now displaying memory usage ‘per tab’.
• We tweaked the context menu, removing the ‘Send link…’ item and combining the ‘Stop’ and ‘Reload’ ones.

See more details in the release notes and in Firefox 16 for developers.

Conclusion

Firefox 16 is on the way to being a very strong release for Web developers, both on the support of standards, and with the nice improvements in our tools, maturing quickly. In the future, Web sites will be easier to do and more powerful!

Firebug 1.10 has been released and so, let’s see what new features are introduced in this version.

First of all, check out the compatibility table:

• Firefox 5.0 – 13.0 with Firebug 1.9
• Firefox 13.0 – 16.0 with Firebug 1.10

Firebug 1.10 is true community achievement and so, let me also introduce all developers who contributed to Firebug 1.10

New Features

Bootstrapped Installation

Firebug installation doesn’t require browser restart. Install, press F12 and Firebug is immediately ready at your fingertips.

If you are updating the previous 1.9 version that require restart you need to restart the browser.

Delayed Load

Firebug doesn’t slow down Firefox start-up time anymore! It’s loaded as soon as the user actually needs it for the first time. Only the Firebug start-button and menu is loaded at the start up time.

Cookie Management

Firebug allows to view and manage cookies in your browser. You can deny cookies for specific sites, filter cookies, create new and delete existing cookies. You can also break into the debugger when specific cookie changes its value and see the line of script that caused the change. And much more! Check out full list of cookie related features.

Command Editor Syntax Highlighting

Command editor (aka multiline command line) supports syntax highlighting.

Autocompletion

Autocompletion in Firebug has never been better. This feature helps you when editing CSS properties, variables in the Watch panel, break-point conditions, any numbers, colors, font-families, etc. Just try to edit your page through Firebug UI and you’ll see for yourself.

Check out the screenshot. When typing into the Watch panel, the autocompletion offers variables in the current scope.

Trace Styles

This feature allows tracing all places which affected specific CSS property. The feature is part of the Computed side panel where every CSS property is expandable. The Computed side panel also supports tooltips for colors, images and fonts.

See, there are three places trying to set the font-size of the selected element (the one in black succeeded). Of course, the blue text/location on the right is click-able and navigates the user the right place. See also detailed explanation.

New Command: help

If you are interested what built-in commands are actually available in the Command Line (within the Console panel) just type: help. You’ll see a list of commands with a description.

The green command name is a link navigating the user to Firebug wiki with more info (and how-to-examples) about clicked command.

Link to Web-font Declaration

This feature allows to quickly inspect custom font-family declarations. All you need to do is to right-click on your font-family value, pick Inspect Declaration and you’ll be automatically navigated to the CSS panel that shows the place where the font-family is declared. Check out the screenshot below.

Support For Media Queries

Media queries of @import CSS rules are displayed inside the CSS panel and it’s possible to edit them. Of course, auto-completion works in this case too (e.g. when I did the screenshot, I clicked on 400px value and pressed up-arrow, that’s why there is 401px).

Displayed Entities Format

There are new options in the HTML panel that allow changing displayed format of HTML entities.

And by the way, MathML entities are also supported.

Displayed Color Format

There are also new options allowing to change displayed format of CSS colors. Firebug offers three options: Hex, RGB and HSL. These options are available in CSS, Style and Computed panels.

Tooltips for Menu Items

This is one of many little and neat improvements. Every menu item has also a tooltip that explains the associated action. It’s especially useful for options.

Support for “focus” CSS pseudo class

Apart from hover and active CSS pseudo classes, Firebug is also supporting: focus.

This feature helps in situations where you want to inspect CSS rules that applies only if the inspected element has focus. Here is what you need to do.

1. Use Firebug Inspector to select your element
2. Open the option menu for the Style side panel (click the black triangle next to the panel label)
3. Check :focus option
4. Now Firebug simulates the focus state and so, every CSS rule using :focus pseudo class in the selector will be displayed

HTTP Requests From BFCache

Firebug Net panel is able to display also HTTP requests coming from so called BFCache (Back-Forward Cache). This cache makes backward and forward navigation between visited pages very fast. Note that this has nothing to do with the browser cache.

Check out the screenshot, we changed the background for requests coming from the BFCache and so they can be easily differentiated from other requests. Only the last request on the screenshot is coming from the server.

In order to see those requests you need to check Show BFCache Responses option.

Delete CSS Rule

Another neat feature that allows to delete whole CSS rule together with all its properties. Just right click a CSS rule…

Check out our issue tracker for all 79 enhancements in Firebug 1.10.

Also, follow us on Twitter to be updated about upcoming Firebug news!

Jan ‘Honza’ Odvarko

Update 2012-07-06: The date when content editing switches to the new platform has been postponed to July 9th. There have been some stability and data center issues that slowed us down, as well as a few big bugs that have been resolved but still need to be tested.

Hopefully by now you’re aware we’re switching to a brand new, Mozilla-built wiki platform for the Mozilla Developer Network. The new site will launch in mid-July, and we’re incredibly excited about it!

As part of the launch process, we’re going to begin directing all editing of content to the new wiki starting on July 5th. That means any time someone tries to edit a page, they will actually go to the new site and edit that instead. No editing of the current, MindTouch powered site will be possible from that time on.

The current site will remain in place for the time being, and viewers will see that rather than the updated content. However, each page will include a banner explaining the situation and offering a link to the equivalent page on the new wiki, for people that want to view the very latest content.

On the weekend of July 7-8, we plan to have a very structured test program, led by Mozilla’s brilliant QA team. We will be inviting community members to participate actively, to help ensure that the new site is ready for action.

We continue to expect to launch the new site on or around July 15th, directing all traffic there.

Watch this space for further announcements. We’re getting close now, and we’ll need your help to get there!

Last month, ten excellent WebSocket demos were shared in the May Dev Derby competition. After looking through the entries, our three expert judges—Guillermo Rauch, Peter Lubbers, and Rob Hawkes—have decided on three winners and three runners-up.

You don’t have to be a contestant to get excited. Because these demos are completely open-source, they provide wonderful lessons in all of the exciting things you can do with the WebSocket API today.

Winners

• Just Spaceships! by April finalist Ondřej Žára
• Achtung, die Kurve! by newcomer rdragon
• Atoms, also by Ondřej Žára

Runners-up

• Collaborative Draw, also by Ondřej Žára
• Sync HTML5 audio by sophomore JoanC
• open whiteboard by long time contributor Cory Gackenheimer

Many congratulations to Ondřej for his astounding and record-setting three placements this month. Thankfully, this won’t be the last we see of him. Based on his early entry to the July Derby, it’s clear that Ondřej has much more to share. Congratulations also to rdragon, JoanC, and Cory Gackenheimer, who have shown us that newcomers and veterans alike are equally capable of impressing in this contest.

And let’s not forget about all of our other great contributors. The Websocket API is very important for the future of the web, and these contributors deserve a great deal of praise for pushing it forward.

Want to get a head start on a future Derby? We are also accepting demos that highlight the all that can be done today without JavaScript (July Derby) and demos related to the Camera API (August Derby).

Further Reading

• MDN articles on WebSockets
• BrowserQuest – a massively multiplayer HTML5 (WebSocket + Canvas) game experiment
• Adding real-time multiplayer game-play with WebSockets

For people building web sites, Responsive Web Design has become a natural approach to making sure the content is available for as many users as possible. This is usually attended to via CSS media queries. However, there is a JavaScript alternative as well.

Introducing window.matchMedia

The way to approach media queries in JavaScript is through window.matchMedia. Basically, you just use the same approach as with CSS, but with a JavaScript call:

var widthQuery = window.matchMedia("(min-width: 600px)");

This query returns a MediaQueryList object, on which you can do a few things:

matches

Boolean whether the query matched or not.

media

Serialized media query list.

addListener

Adding event listener to a media query. Much preferred over polling values or similar.

removeListener

Removing event listener from a media query.

Therefore, the easy way to determine if a media query matched is using the matches property:

var widthMatch = window.matchMedia("(min-height: 500px)").matches;

Adding listeners is very easy:

function getOrientationValue (mediaQueryList) {
    console.log(mediaQueryList.matches);
}
 
portraitOrientationCheck = window.matchMedia("(orientation: portrait)");
portraitOrientationCheck.addListener(getOrientationValue);

Demo and code

I’ve put together a window.matchMedia demo where you can see some queries in action. Try resizing the window and see the values change.

The complete JavaScript code for that demo, which is of course available on GitHub, is as follows:

Web browser support

At this time, window.matchMedia has been implemented in:

• Firefox 6+
• Google Chrome 9+
• Safari 5.1+. Note: doesn’t support addListener.
• Firefox mobile
• Google Chrome beta on Android. Note: doesn’t support addListener.
• Safari 5 on iOS. Note: doesn’t support addListener.
• Android stock browser. Note: doesn’t support addListener.

It is also planned to be in Internet Explorer 10.

For older/unsupported web browsers, you can try the matchMedia() polyfill, although it doesn’t support addListener.

Releasing an app is much more than just coding it. You are providing a service to people and they trust you with their data. With the amount of reports of apps “calling home” and storing and sending your data to third parties without your consent rising it is important to make it plain and obvious what you do. An easy to understand and plain Privacy Policy is not only a good service but it can make it easier for investors and users to choose your product over another.

Ramping up developers to submit and publish their apps to the Mozilla Marketplace we just released a few simple to understand Privacy policy guidelines complete with an HTML/CSS/RSS Privacy Policy Template on GitHub.

Whilst the guidelines are not a substitute for a real lawyer and don’t provide legal advice they have some very simple and powerful tips to get you going:

• Design your app or add-on so that what you actually do with user data is what users think you are doing with it.
• Try to give the user as much control over their data as you can, such as giving them the choice to opt-in to or opt-out of data collection whenever possible.
• Try to limit your data collection and use to only the data that you need.
• Design your app and service to protect the security of your user’s data in its collection, storage, and use.
• Respond to user questions and concerns about your privacy practices.
• Avoid ‘secret’ updates.
• Make your use of social features transparent, so that users are aware of when they’re sharing data socially.
• Give people a way to turn off automatic sharing or make more granular choices about sharing data.
• Obtain consent from users when necessary, especially for location and other sensitive information.
• Put a link to your privacy policy and, if you have them, your “terms of use” somewhere in your app.

Avoid confusion and problems in the future by getting the basics right – and that very much includes privacy concerns in your app.

We have just released Firefox Aurora 14, which includes a number of improvements. If all goes well, these features should be released in 12 weeks as part of Firefox 14.

Highlights

There are a few of things we’d like to shine some extra light on here:

• Native Fullscreen Support in Mac OS X 10.7 “Lion”: Firefox can now use the native full-screen mode and button. It animates and behaves properly in that mode, like any other well-integrated application.
• Great news for gamers! The Pointer Lock API, sometimes called the Mouse Lock API, lets games better control the mouse, by removing the pointer and letting the application capture and handle the mouse move coordinates directly.
• The four default ways to search — using the search bar, the address bar, the contextual menu, or the home page, now all use the Google https search service in Aurora. This increase the security of your searches.
• The dev tools now allow easily inspecting pseudo-classes states: when hovering over an element with the dev tools activated, the contextual menu now lists the different states of the element, like :hover, :active, and :focus. When selecting one of these items, the element is locked in the associated state and can be inspected. That feature was already there in Aurora 13, but the interface to access it is now very convenient!
  
  

List of improvements

Here is a (more or less) complete list of the improvements.

DevTools

• New keyboard shortcuts have been added to the Source Editor JS module (used by the Scratchpad or the Style Editor) to quickly jump to the code block start and end.
• Still in the Source Editor module, it is now possible to add or remove a comment on a line or the current selection with one keystroke.
• Beside the new pseudo-class inspector, several improvements have been made to the infobar which has now an inspect button to the left and a node menu to the right (for example, it may be used to set the pseudo-class state on the node!)

DOM

• The Pointer Lock API has been implemented.
• A proposal for the replacement of MutationEvents, introduced in DOM Level 2 but deprecated in DOM Events Level 3, has landed, prefixed: instead of events, an API allowing callbacks to be registered has been crafted.
• New, with added performance, DOM bindings for non-list objects have landed. Currently XMLHttpRequest is the only non-list object using them. These bindings are often called the “Paris DOM bindings” as they were designed in that city.
• The SVGSVGElement has been fixed to be a DOM Element.
• HTMLProgressElement, the DOM object associated with the <progress> HTML element, was a HTMLFormElement. This was incorrect and has been fixed. It is a simple HTMLElement now.

Plugins

• Optionally, if the plugins.click_to_play preference is enabled in about:config, plugins will require an extra click to activate and start “playing” content. This mode improves the security of the browser and may be extended in the future to be activated by default in some cases. When on, site-specific permissions can be set.

Layout

• CSS text-transform and font-variant properties have been updated to match the spec and now handle the Dutch IJ digraph, the Turkic dotless and dotted i, and the Greek sigma lowercase characters correctly. This is big improvement for writing on the Web in these languages!
• Related to CSS transforms, the skew() function has been removed from the spec, so support has been removed from Firefox as well. It wasn’t a real skew function which designs the linear shear mapping transform and its effect is still achievable using the matrix() function.
• Directly viewed images now have a textured background.
• The character maps (cmap) have been optimized. Fonts with identical character coverage now share them. This lets Firefox use less memory, about 0.5 MB on a desktop system with few fonts, and up to 1.8MB or more on systems with a lot of fonts. The more fonts that are installed, the greater the savings. This was done as a part of the MemShrink project.
• SVG performance has been significantly improved.

User Interface

• The popup bubble containing a link URL that appears on the bottom of the page when hovering over a link is now longer when the URL doesn’t fit in it.
• As part of the Australis theme evolution project, the navigation bar buttons have been modified (on Windows only).
• The identity block has been redesigned. The favicon has been changed to show an icon describing the connection used:
• The page is served unencrypted (http).
  
• The page is served encrypted (via https) but some of its content comes from unencrypted servers.
  
• The page and its content is served encrypted (and the server uses a CV certificate).
  
• The page and its content is served encrypted (and the server uses an EV certificate).
  

Network

• At launch, tabs are no longer loaded in the background. Instead, they are now loaded when first selected, which improves response during the start-up of Firefox. This has been done as a part of the Snappy project.

Others

• Both the Internet Explorer and Safari migrators have been rewritten in JavaScript. Using asynchronous I/O, they don’t block the browser when they run and it improves their maintainability. This has been done as part of the Snappy project.
• On Linux, the $LANG system variable is now used when not able to locate a given dictionary in another way. Useful for system-wide installed dictionaries.
• For add-ons writers, the js-ctypes library has been extended. Variadic ctypes functions — that is, support for functions with a variable number of arguments — have been added.
• Several bugs in our WebGL implementation have been fixed (and workarounds for some common driver bugs added). We are close to WebGL 1.0.1 conformance, but your help is still needed.
• Extra flexibility has been added to the Garbage Collector (GC): it could previously be applied on a single compartment or on all compartments. Now it can also be applied on a set of compartments. This will let it be launched in more cases in the future, leading to a finer control of memory and of GC pauses.

Note: pdf.js and the new panel-based Download Manager, though they landed on Nightly, have not been lifted to Aurora 14 as they need further polishing. Similarly, support of GStreamer for videos, though it landed last week, has not been activated yet.