Featured Articles

Just under a month ago I wrote a personal post about my thoughts on Firefox OS and why I think there is something ‘magical’ about what it stands for and the possibilities it brings to the table. This post is a follow-up that aims to cover much of the same ground but with extra detail and more of a technical focus.

What is Firefox OS?

In short, Firefox OS is about taking the technologies behind the Web, like JavaScript, and using them to produce an entire mobile operating system. It’s effectively a mobile OS powered by JavaScript!

This is achieved with a custom version of Gecko, the rendering engine in Firefox, that introduces a variety of new JavaScript APIs needed to create a phone-like experience; things like WebSMS to send text messages, and WebTelephony to make phone calls.

You might be wondering what’s running Gecko, as a phone can’t naturally boot directly into Gecko. To do that, the phone boots into a very lightweight Linux kernel that, in turn, boots the Gecko process. The process is a little more involved than that and much more detail can be found in the B2G Architecture documentation, including how Gecko accesses the radio hardware and other phone-specific functionality.

The Firefox OS project also aims to combine many of the other projects at Mozilla into a single vision, what we refer to as the Web as the platform. These projects include the Open Web Apps initiative and Persona, our solution to identity and logins on the Web (formally known as BrowserID). It’s the combination of these various technologies that completes Firefox OS.

If you want to find out more technical information about the OS then definitely check out the Firefox OS pages on MDN.

Why Firefox OS?

A couple of common questions that come up are, “Why Firefox OS?” and more specifically, “Why build a mobile OS using JavaScript?” These are incredibly important questions so let’s take a moment to delve into them in a little detail.

Why build a mobile OS using JavaScript?

Answering this question can quite simply be boiled down to one sentence; because it’s possible. It’s not the one and only answer but it succinctly handles most of the arguments against JavaScript being used in this way.

A longer answer is that a JavaScript-powered OS unlocks a whole range of possibilities that aren’t normally or easily available to developers and users with existing operating systems.

The most obvious of the possibilities is the ability to build applications using the technologies that we already use to build websites; namely JavaScript, CSS, and HTML. While not a truly unique feature of Firefox OS — projects like PhoneGap have done this for years on ‘native’ platforms — it allows developers everywhere to create mobile applications without having to learn native languages and APIs.

Another draw of JavaScript is that it’s both extremely well documented and free to develop with. Anyone could sit down for a weekend and put together an application without having to pay for a single thing. Obviously that’s not true in the majority of cases, as people tend to buy their own hosting or tooling, but theoretically there is nothing to stop you building with these technologies for free.

What’s arguably most interesting about JavaScript being used in this way is that it inherently enables physical devices to communicate using the same APIs that we already use on websites. In effect, instead of accessing the Web through a mobile browser the entire phone is now capable of accessing and communicating with any Web API. For example, there is nothing to stop you building an application for Firefox OS that uses WebRTC (once added) to create Skype-like P2P video communication between phones, desktop computers, or anything else that supports WebRTC.

This really only scrapes the surface of “Why JavaScript?” but it certainly gives you a feel of how this is both interesting and important, beyond the tired debate of ‘native’ vs. Web. If you’re still not convinced, just think for a moment about how you can now customise an entire mobile OS using nothing by JavaScript. You’d be hard pushed to deny that it’s pretty darn interesting!

OK, but why Firefox OS?

Effectively, Firefox OS has been built to put our money where our mouth is (so to speak) and prove that JavaScript is capable of doing what we say it can do. However, there is much more to the project than just proving the the technology is fast enough.

The first reason ‘Why Firefox OS’ is that the mobile ecosystem is overrun with proprietary platforms, most of which prevent you from easily moving between various platforms. What Firefox OS aims to achieve is a truly ‘open’ platform that doesn’t lock you in and inherently makes it as easy and possible to move between devices as and when you choose.

Mozilla is effectively replicating its success with Firefox, in which it stormed the browser market and showed users that there is an alternative, one that lets them be in control of how they use the Web. In this case, it’s less about browsers and more about mobile platforms and application portability.

Another reason is that Firefox OS is an attempt to push the Web forward into the world of physical devices. One direct benefit of this is the addition of brand new Web standards and APIs that allow for things like hardware access using JavaScript.

Plenty of challenges

It’s fair to say that the Firefox OS journey will contain a number of technical challenges along the way, however that’s part of the fun and the reasons why we’re working on it.

One of those challenges is how to manage an apps ecosystem that is open and distributed. This is something that we are tackling with the Open Web Apps initiative and the Mozilla Marketplace. It’s a challenge that we are dealing with as things progress and as we learn more about how things work best, as is the nature with new ways of thinking.

Another of the challenges is making sure that the phone runs as fast as possible, creating the best experience possible. This also relates to questions raised within the developer community around the performance capabilities of JavaScript, particularly when it is used to do things that are perceived to be complex, or when it is compared against ‘native’ technologies. This is a challenge that we are taking very seriously and one which we feel we can overcome. In fact, it’s a challenge that I believe we have already overcome.

One prime example of how capable JavaScript has become is seeing beautiful JavaScript games running in Firefox OS at near-enough 60 frames per-second, on a low-end, cheap phone.

Beyond the mobile phone

While the phone aspect of Firefox OS is immediately interesting, you should consider the wider implications of a JavaScript OS and what possibilities it unlocks. For example, what other devices could benefit from being powered by JavaScript? And, what would a network of JavaScript-powered devices allow us to do — things like Ubiquitous Computing, perhaps?

These aren’t things that we are exploring directly at Mozilla, but they are things that are now inherently possible as a result of the work that we’re doing. There is nothing to stop you taking the Firefox OS source code from GitHub and porting it to a device that we’ve never even considered.

We’re already starting to see this happen with examples like a Firefox OS port for the Raspberry Pi, as well as another for the Pandaboard.

What about a game console powered by Firefox OS? A TV, or set-top box? What about a fridge? Individually, these are all interesting projects, but together they offer something we don’t really have at the moment, a network of different devices powered by the same, open technologies and able to access and communicate across the Web with the same APIs.

We are a long way away from that kind of world but it is projects like Firefox OS that may pave the way for it to happen. You could even be a part of it!

Getting started with Firefox OS

The hope is that by now you’re sufficiently interested in Firefox OS to begin exploring, experimenting and playing with it. The good news is that there are a whole host of ways that you can do that.

Documentation

One of the first places to start is the MDN documentation surrounding Firefox OS and its related technologies. This is where you’ll find everything you need to know about the developer-facing aspects of the platform.

If you’re more interested with the inner-workings of the platform then you’ll want to cast an eye over the B2G wiki, which outlines much of the internals in plenty of detail.

Source code

If you’re keen to get to grips with the source code of Firefox OS then you’ll want to head over to GitHub and check it out. The two main repositories that you want are ‘b2g’ (the underlying Gecko engine) and ‘gaia’ (everything you can see, the OS).

Getting involved

There are a few ways to get involved with the project. You could check out some of the issues and get involved in fixing them, or perhaps just hang out in the mailing list for B2G, or the one for Gaia, and take part in the discussions there.

If you just want to ask a few immediate questions then try out the #b2g and #gaia rooms on irc.mozilla.org. We’re all pretty friendly!

Development options

If you just want to dig in and make some applications, or perhaps customise the OS, then you’ll need to know about the various development options available to you. They are covered in some detail on MDN but here is a brief overview.

The simplest method to get started is running Gaia (the visual side of Firefox OS) within Firefox Nightly. This doesn’t give you a true representation of a phone environment but it will allow you to install applications and use all of the developer tools within the browser that you’re already used to.

Slightly more involved than Nightly is using the desktop B2G client. This is effectively a chromeless build of Firefox that looks phone-like has some added APIs that aren’t normally available in standard Firefox. This doesn’t replicate phone hardware but it’s the next best thing before starting to develop on an actual device.

Setting up the desktop B2G client isn’t too hard, but it could be made easier. In the meantime, projects like r2d2b2g aim to make the process super simple. Definitely worth checking out.

The last method, and arguably the most important one, is developing on an actual Firefox OS device. This is the only method that will give you a true representation of how your application will perform. It is also the only method that will give you access to the all the new APIs that come with Firefox OS.

Right now, you’ll need to build and install Firefox OS on one of the supported devices. In the future you will be able to skip this step and get access to devices that already run Firefox OS. We don’t have any dates for that just yet.

Go forth and be part of something big

My hope is that by now you should now have enough inspiration and information to go forth and begin building for this new platform, powered by the technologies you already use. We hope you do and we’d love to see what you come up with.

It’s not every day that you get the opportunity to be a part of something that could quite literally change the way we do things.

Developers building apps for Firefox OS should be able to test them without having to deploy them to actual devices. I looked into the state of the art recently and found that the existing desktop test environments, like B2G Desktop, the B2G Emulators, and Firefox’s Responsive Design View, are either difficult to configure or significantly different from Firefox OS on a phone.

Firefox add-ons provide one of the simplest software installation and update experiences. And B2G Desktop is a lot like a phone. So I decided to experiment with distributing B2G Desktop via an add-on. And the result is r2d2b2g, an experimental prototype test environment for Firefox OS.

How It Works

r2d2b2g bundles B2G Desktop with Firefox menu items for accessing that test environment and installing an app into it. With r2d2b2g, starting B2G Desktop is as simple as selecting Tools > B2G Desktop:

To install an app into B2G Desktop, navigate to it in Firefox, then select Tools > Install Page as App:

r2d2b2g will install the app and start B2G Desktop so you can see the app the way it’ll appear to Firefox OS users:

Try It Out!

Note that r2d2b2g is an experiment, not a product! It is neither stable nor complete, and its features may change or be removed over time. Or we might end the project after learning what we can from it. But if you’re the adventurous sort, and you’d like to provide feedback on this investigation into a potential future product direction, then we’d love to hear from you!

Install r2d2b2g via these platform-specific XPIs: Mac, Linux (32-bit), or Windows (caveat: the Windows version of B2G Desktop currently crashes on startup due to bug 794662 795484), or fork it on GitHub, and let us know what you think!

For the past year, we’ve been rapidly improving Mozilla Persona (previously BrowserID). Our goal is simple: we want to eliminate passwords on the Web. Today, after many iterations based on community implementation feedback, Persona enters Beta. This first beta means:

1. we’ve produced and are committing to a much improved API
2. the first-user experience is significantly improved and streamlined: it’s actually hard to get lost
3. critical new features, including support for showing your site’s name and logo, as well as terms of service and privacy policy, are live

Since the beginning, Mozilla Persona was designed to work across browsers. Our commitment to this continues: Persona Beta 1 supports all major mobile, tablet, and desktop browsers. In fact, we’re working to build an extensive library of automated regression tests across all browser platforms to ensure that this support remains rock solid as we continue to add features.

Persona is not just a great product, it’s also designed with the Mozilla Values in mind. When you deploy Persona on your web site (in an afternoon or, sometimes, only 15 minutes), you’re showing respect for your users and their data. You’re only asking for the data needed to log them in, and users know they’re only sharing exactly what’s shown on the screen.

The technology behind Persona is interesting in its own right. We’ve built and scaled Mozilla’s first serious node.js-based service. We’ll be writing a few more posts on the specifics of our technology in the weeks and months to come. In the meantime, check out our source code, and join us on email or irc.

And if you’re building or upgrading a web site, don’t forget to add Persona login support! Our quick setup guide should help you get off the ground in minutes.

In a great victory for open standards, the Internet Engineering Task Force (IETF) has just standardized Opus as RFC 6716.

Opus is the first state of the art, free audio codec to be standardized. We think this will help us achieve wider adoption than prior royalty-free codecs like Speex and Vorbis. This spells the beginning of the end for proprietary formats, and we are now working on doing the same thing for video.

There was both skepticism and outright opposition to this work when it was first proposed in the IETF over 3 years ago. However, the results have shown that we can create a better codec through collaboration, rather than competition between patented technologies. Open standards benefit both open source organizations and proprietary companies, and we have been successful working together to create one. Opus is the result of a collaboration between many organizations, including the IETF, Mozilla, Microsoft (through Skype), Xiph.Org, Octasic, Broadcom, and Google.

A highly flexible codec

Unlike previous audio codecs, which have typically focused on a narrow set of applications (either voice or music, in a narrow range of bitrates, for either real-time or storage applications), Opus is highly flexible. It can adaptively switch among:

• Bitrates from 6 kb/s to 512 kb/s
• Voice and music
• Mono and stereo
• Narrowband (8 kHz) to Fullband (48 kHz)
• Frame sizes from 2.5 ms to 60 ms

Most importantly, it can adapt seamlessly within these operating points. Doing all of this with proprietary codecs would require at least six different codecs. Opus replaces all of them, with better quality.

The specification is available in RFC 6716, which includes the reference implementation. Up-to-date software releases are also available.

Some audio standards define a normative encoder, which cannot be improved after it is standardized. Others allow for flexibility in the encoder, but release an intentionally hobbled reference implementation to force you to license their proprietary encoders. For Opus, we chose to allow flexibility for future encoders, but we also made the best one we knew how and released that as the reference implementation, so everyone could use it. We will continue to improve it, and keep releasing those improvements as open source.

Use cases

Opus is primarily designed for use in interactive applications on the Internet, including voice over IP (VoIP), teleconferencing, in-game chatting, and even live, distributed music performances. The IETF recently decided with “strong consensus” to adopt Opus as a mandatory-to-implement (MTI) codec for WebRTC, an upcoming standard for real-time communication on the web. Despite the focus on low latency, Opus also excels at streaming and storage applications, beating existing high-delay codecs like Vorbis and HE-AAC. It’s great for internet radio, adaptive streaming, game sound effects, and much more.

Although Opus is just out, it is already supported in many applications, such as Firefox, GStreamer, FFMpeg, foobar2000, K-Lite Codec Pack, and lavfilters, with upcoming support in VLC, rockbox and Mumble.

For more information, visit the Opus website.

The web is such an integral part of our lives and how we communicate with each other. That’s why we get so excited when we reach evolutionary peaks that take us leaps and bounds forward in offering a better and open game-changing experience for users and web developers alike! We believe WebRTC to be one of those steps.

What is WebRTC?

The RTC in WebRTC stands for Real-Time Communications, offered directly on the web without any need for plugins or third-party software. The idea is to be able to share and stream video, audio and data in the most powerful fashion, directly in a web browser, offering media rich exchanges.

Representatives from Mozilla, Google, Opera and others have been working on WebRTC over a year, and it is on its way to becoming a W3C recommendation.

The three corner stones in WebRTC are:

MediaStream

Granting web apps/sites access to the camera and microphone on your computer, via the getUserMedia API.

DataChannel

Communicating data peer to peer.

PeerConnection API

Enabling direct peer to peer connections between two web browsers for audio and video.

Code simplicity

If you take a look at our work with WebAPI, you will see examples of a number of simple and intuitive APIs. We believe it’s important for WebRTC to be as easy-to-use by all web developers, not just the rocket scientists among us (nothing wrong with being one, by the way – it’s just that not everyone is. :-))

To enable this, the web browser handles the real-time media and networking for the web developer, so developers can focus on writing apps that include real-time communication as one of the features. We feel the web itself has in part become an incredibly popular tool for so many developers because it makes it easy to create wonderful things to share with the world.

We believe WebRTC will become successful for the same reason.

For example – and you’ve probably already seen this elsewhere – it is very simple to stream the webcam of your computer directly into a web page (with user-granted access, of course):

/*
	NOTE: This is meant to show a simplified version,
	without prefixes and such that are currently used 
	for experimental implementations
*/
 
// Get a reference to an existing video element, set to autoplay
var liveVideo = document.querySelector("#live-video");
 
/*  Request access to the webcam
	Note: in current implementations, this has to 
	be prefixed, and Google Chrome needs a Blob URL 
	for the MediaStream
*/

navigator.getUserMedia(
	{video: true},
	function (stream) {
		liveVideo.src = stream;
	},
	function (error) {
		console.log("An error occurred: " + error);
	}

);

If you want to delve more into the code and APIs right now, then Real-time communication without plugins is a good read.

Coming to a web browser near you!

It is important to note that WebRTC has been planned for a long time, and we are now finally reaching a step where cutting edge web browsers – such as Firefox, Google Chrome and Opera – implement their support and bring WebRTC to the web. With Firefox, our plan is to ship full WebRTC support in Firefox 18, in the beginning of January next year.

Stay tuned, and we’ll keep you up to date on the progress!

What can I say? Wow.

The No JavaScript Challenge was absolutely incredible. It was our most successful Dev Derby yet, and by far. You shared more than seventy amazing demos of what you can do without touching a single line of JavaScript. More than seventy amazing demos of how powerful declarative markup can be. That’s nearly twice the number of demos submitted to our second most popular Derby.

As you can imagine, it is extremely difficult for us to name only a handful of winners. But after looking through the entries, our three new expert judges — David Walsh, Joe Stagner, and (filling in for John Hammink this month) Chris Heilmann — have decided on their top five picks.

Winners

• Honey Pursuit: Yet Another Love Saga by newcomer Vanco Stojkov
• Funny agenda by newcomer Fernando García Gómez
• Pure CSS slides by May winner Ondřej Žára

Runners-up

• Pure CSS3 Homer by newcomer bernarddeluna
• Ship Animation by the very active halls-of-valhalla

Congratulations to these winners and to all of our contributors for making this our most exciting contest yet. All of these people have done a fantastic job pushing declarative markup forward and deserve lots of praise for doing so. We might even see some of them again next month… here’s hoping!

Enjoy the No JavaScript challenge? Remember that we have a new contest every month! We are now accepting entries related to Geolocation (September), CSS Media Queries (October), and the Full Screen API (November). Head over to the Dev Derby to get started.

A new version of Firefox Aurora is released every six weeks. Every release includes important features for web developers like you, such as security improvements and support for new HTML5 and CSS3 features.

Aurora 17 brings significant improvements to standards support:

• The :dir(...) pseudo-class of Selectors Level 4, which allows you to easily style content differently based on text direction. This is more powerful than the attribute selector [dir=...], which only matched the value of the attribute and could not take inheritance or other factors into account. This will make it easier for you to write stylesheets friendly to both left-to-right and right-to-left languages.
• The new @supports pseudo-class, which allows you to test support for specific CSS properties and values. This helps you fall back gracefully when a feature is not supported. The pseudo-class is unprefixed, but is only available behind a preference (layout.css.supports-rule.enable) because the specification is still young. Other vendors are in the procress of implementing this specification as well, so we expect it to move forward quickly towards the CR status. Wide support will greatly ease feature direction in the future.
• The WheelEvent event of DOM Events Level 3. This is an important step towards DOM compatibility, and especially event compatibility. Until now, browsers implemented two non-interoperable wheel events, MouseWheelEvent and MouseScrollEvent. This move toward WheelEvent will lead to better interoperability once all other browsers support it. Support for the associated onwheel attribute has also been implemented.
• CSS Animations are now calculated asynchronously, resulting in significant performance improvements.
• Experimentally, Gecko now supports the inputmode attribute of the HTML <input> element. The supported values different from those defined by the WhatWG, but the draft is still young and discussions are ongoing.
• Two big changes related to SVG: support for the FillPaint attribute and support for the StrokePaint attribute. More importantly, SVG display lists have been implemented.
• JavaScript improvements through continued implementation of Harmony, the experimental EcmaScript 6 draft. Maps and Sets are now iterable, and the new string methods startsWith(), endsWith(), and contains() are now supported.
• Blobs finally support ZIP content.

Aurora 17 also brings two major security-related changes:

• Support for the sandbox attribute of the <iframe> element. This lets you manage the security risk of embedding content in a page. For example, you could grant full privileges to an <iframe> that contains content you control, but fewer rights to an <iframe> that uses content from a third party, like an advertising service.
• New handling of certain dialogs. In particular, prompt, alert, and confirm dialogs can no longer be launched from onunload, onbeforeunload, or onpagehide. Though there are some legitimate uses of this type of behavior, many Web sites were abusing it to prevent users from leaving a page.

On the media side, we continue to improve our implementation of the Opus codec. For example, we now support multiple channels audio. These improvements are especially important due to upcoming real-time communication features.

As with all recent Firefox releases, Aurora includes improvements to our developer tools:

• A new Markup panel in the Page Inspector, allowing you to easily edit the DOM.
• Improvements that make the Web Console, Debugger and Developer Toolbar faster and easier to use.

This is an especially strong release in terms of user interface improvements.

Numerous improvements have been made to Mac OS integration:

• When available, Firefox now uses the Notification Center (in Mac OS Mountain Lion) instead of Growl to send notifications.
• The background color of the tab bar now changes when inactive, just like other native Mac OS applications.
• Light windows now have a new light color, matching the Mac OS theme.

Users will also see improvements when copying images to other programs. Until now, copying from the content area to a program like Photoshop caused transparency information to be lost. This is no longer the case!

Still on the user experience side, the look of location bar results has been greatly improved. Additionally, when fixed content is present in the header, scrolling with Page-DOWN and Page-UP now works correctly, allowing continuous reading and a far better scrolling experience.

Like always, responsiveness and memory management have continued to improve this cycle. Even though no major changes were made, numerous small improvements have been made to make Firefox a little bit snappier as a whole.

Again, this is a very strong Aurora release. As always, the final set of features released with Firefox 17 (scheduled for November 20th, 2012) may change slightly due to testing and user feedback, but nonetheless this is a very strong start.

Firefox 16, now on the Beta channel, has a fantastic feature that was mentioned briefly in the Aurora 16 blog post and first introduced in a separate post by Joe Walker, the feature’s creator. We’ve devoted a sizable portion of the new Developer Toolbar to the “command line”, which you may sometimes see us call GCLI (short for Graphical Command Line Interface). The command line gives you quick keyboard control over your tools and access to features that don’t have any other user interface.

I have made a video version of this blog post so you can see the command line in action:

To get to the Developer Toolbar and the command line, you can use the shift-F2 keyboard shortcut, or select Developer Toolbar from the Web Developer menu. If you want a quicker keyboard shortcut (this is a keyboard-heavy feature, after all!), you can use the Customize Shortcuts add-on to override a shortcut that you don’t use.

This command line is designed to be quick-to-type and discoverable. It will complete commands and parameters for you, to save you typing. There’s also a lot of help built in for the commands and their options. Here’s a look at the list of commands shipped with the initial command line release:

Control Your Tools

Personally, I hate having to reach for my trackpad. Removing my hands from the keyboard just slows me down. The problem is that it’s not easy to remember all of the keyboard shortcuts and traditional keyboard navigation is sometimes not as quick as reaching for the trackpad. Let’s look at how the new command line helps with this.

Let’s say that I forgot the keyboard shortcut for the Web Console. I could reach for my trackpad and hit the Web Console button that is conveniently located on the new Developer Toolbar. Or, I can just remember the keyboard shortcut for the command line and run the command console open. Voila! The console opens. What I actually type to run that command is “con<tab>o<tab><enter>”, which is quick to type indeed.

Want to see what else you can do with the Web Console? Type help console.I’m not even sure if there’s a keyboard shortcut for the Clear button in the Web Console. It’s easier to just run the console clear command than try to remember a seldom used shortcut.

Here are the current commands that control the developer tools:

• console – open, clear and close the Web Console
• dbg and break – many controls for the Debugger and breakpoints
• edit – open the Style Editor on any of the CSS files loaded in the page
• inspect – open the Page Inspector for a part of the page
• resize – control the Responsive Design View
• tilt – control the 3D page view

Let’s look at a more interesting example. The current design of mozilla.org is a responsive design. I want to see how the headings will show up on a smaller screen. If I’ve been working on the page, I would likely know some of the IDs and structure used in the page, so I could enter a command like:

inspect "#home-news h3"

The “inspect” command takes as a parameter a CSS selector that is used to select a node on the page. An easy way to jump into page inspection on any page is to type inspect body, because every page will have only one. After typing inspect "#home-news h3", I’ll see something like this:

In the style panel, I can see that the font size is set to 28px on this heading. How would it look on a phone-sized screen? Many phones report their size as 320×480. Let’s give that a try by typing the following command:

resize to 320 480

That turns on the Responsive Design View and sets the size at the same time. Here’s what the result looks like:

In the Style panel, we can now see that a media query with a max-width has taken effect and the font-size on the heading has dropped to 24px. We can also scroll down and see that the three columns that were side-by-side are now stacked. You could use the resize off command to turn off the Responsive Design View, or you could just hit <esc> a couple of times to get back to normal browsing mode.

Entirely New Developer Features

We’ve also added a handful of commands giving you some new and useful powers. Let’s take a look at a few of them.

Put your hands in the cookie jar

The “cookie” command highlights why this command line is a “graphical” command line and not your old ’70s-style command line. Running cookie list on mozilla.org, I see:

The output shows me all of the cookies that I have right now for this site. If I want to remove that cookie, all I have to do is type cookie remove WT_FPC or, if I think it’s easier, I can click on the “Remove” action listed next to the cookie and that command will be entered on the command line for me. I can also give myself new cookies using the “cookie set” command.

Screenshots for fun and profit

The “screenshot” command is really handy. At mozilla.org, I ran this command:

screenshot heading.png 0 false h1

This said to make a file called “heading.png”, wait 0 seconds before taking the shot, don’t include anything outside the visible browser window and finally grab just the element selected by the “h1″ CSS selector. The result, saved conveniently in my Downloads directory, looks like this:

The command line provides hints inline for each parameter. Pressing F1 gives me even more help about the current parameter.

Stop the blinking!

The “pagemod” command lets you quickly make some bulk changes to the page. If you’re looking at a page and there’s something flashing at you, you can nuke it using the “pagemod remove element” command. See how everything on the page looks without classes by typing:

pagemod remove attribute class *

Or, take a look at how a different headline looks:

pagemod replace "Out of Date News" "The New Hotness"

Here’s a fun one that’s interesting to try out on popular sites:

pagemod remove element iframe

See if you can spot the bits that go away.

More goodies: grab the HTML, reconfigure Firefox

The “export html” command opens a new tab with an HTML snapshot of the current state of the page.

The “addon” command lets you quickly enable and disable addons. This is useful for isolating an add-on that might be causing you trouble, or for keeping some add-ons that you don’t use often turned off.

The “pref” command lets you easily change one of the many configuration options that Firefox has. For example, if you’d like to do some Firefox add-on development, you may find this command handy:

pref set devtools.chrome.enabled true

After that, use the “restart” command to restart the browser, and you’ll find that tools like Scratchpad have gained some extra powers for hacking on your browser. While many add-ons these days are restartless, you’ll find that there are still some popular ones that require a restart when enabling or disabling them, and the restart command is handy for that as well.

Add Your Own

One of the best features of command lines in general is that they are a very scalable form of user interface. Adding more commands does not add visual clutter in the UI you look at all day. Expect to see more commands in future Firefox releases, plus new commands that appear in add-ons.

In a future command line article, we’ll show you how to create your own commands. It’s easier than you might expect!

At Mozilla, we believe in the power and potential of the Web and want to see it thrive for everyone, everywhere.

What We’ve Done

We’re committed to building the infrastructure needed to keep the Web the most robust platform on the planet. Although its roots have been around for some time, Mozilla’s focus on games is a relatively new initative. We are focused on making Firefox the best game development platform possible.

Check out BananaBread.

The latest Firefox release includes all of the JavaScript and WebGL updates needed to produce this demo.

BananaBread was developed by Mozilla to show our progress in action. We ported a complete C++ game engine to JavaScript using Emscripten. The original opensource engine is called Cube 2. It was designed to support first person shooters. Few believed porting a full, highly responsive game to JavaScript was an achievable goal. (We had our own doubts.) To our amazement, we found that we were able to build a demo that surpassed our highest expectations.

The project required very few code modifications to the original game, which demonstrates that porting games to the Web does not have to be difficult.

Learn more about Emscripten.

New technologies for HTML5 games

Here are a few technologies that have landed this year to advance our support for HTML5 games:

• Game focused performance improvements to JavaScript, many inspired by games and demos that we saw on the Web or that developers sent to us for testing
• Wide range of WebGL performance improvements
• High precision timing
• Compressed texture support on desktop
• Smoother JavaScript execution on large code bases
• Hardware acceleration of 2D canvas on desktop
• FullScreen API
• PointerLock API (special thanks to David Humphrey and students at Seneca College)
• OrientationLock

Firefox for desktops has come a long way in a short time. But there is still more to come. We are working on features that will improve performance and make development easier. We are also investigating options for porting to JavaScript from languages such as C# and Java.

What’s Next

Our focus for the first half of 2012 was Firefox for Windows, Mac and Linux, and while we continue to make improvements there, our focus for the second half of the year will include Firefox for Android and Firefox OS. There are hard challenges ahead but we are excited to deliver the maximum potential HTML5 has to offer, both in features and performance.

One of the main goals of the Mozilla Community working on games is to not only drive game development on Firefox but across all browsers. Any browser that has implemented the necessary modern Web standards used by the BananaBread demo can run it. These efforts help us stay in touch with how HTML5 is coming together and see opportunities where we can make developers’ lives easier. Hearing directly from the HTML5 game developer community is a key part of how we learn what needs to be done.

I hope you’ll come and join us in raising the bar on what’s possible!

You can join the conversation on our IRC server at irc.mozilla.org, channel #games.

Or sign up for the mailing list at https://lists.mozilla.org/listinfo/community-games

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.