Are you a developer who’s passionate about Mozilla’s mission on the open Web? We need your help: We’re looking for someone to build a game to help keep the Web open as it goes mobile. There’s a Firefox mobile website testing app which we think would make a nice little HTML5 game — with scoring, achievement, levels, leaderboards — and we think you have the chops to make it fun. We’ve had some success making a game of the activity within our team, but we think you could do it better.

Here’s some context. We need lots of people looking at lots of frequently visited websites to see if they look good and work well on mobile. And if they don’t, we need to figure out how to make them better: by finding the bugs and fixing our browser or by working with the developer who built the site to make it work on the open Web. Testing Fennec matters for the future of the open Web:

Fennec, Mozilla’s mobile browser, just landed in Google Play (you may remember it as the Android Marketplace). Firefox Beta for Android is better than ever! You can download it now, use it on your Android phone or tablet and share your feedback. If you get hooked on testing, you’ll want to create a bugzilla account (if you don’t have one) and start filing bugs. By

If you’d like to do a little more directed testing, check out Aaron Train’s most excellent testing app, which sends you to some of the world’s leading websites to share your feedback. This is the app we’d like to gamify, to motivate more people in the Mozilla community to help us keep improving the Firefox mobile web experience for everyone.

What matters is mobile

It’s an interesting exercise to start viewing and interacting with the world’s most frequently used websites in a mobile browser. Any mobile browser. You realize the mobile Web has a ways to go. But there’s more to it than that. David Slater, who leads Product Marketing at Mozilla put it so well that I’m just going to share a note that he sent out internally earlier this week:

The mobile Web is under threat. For 8 years Mozilla has fought to make the Web open on desktop – and won. On mobile, it’s different – the battle is underway. In order to win, we will have to make the Web on mobile devices as compelling for developers and users as native mobile apps are today. Marketplace is about doing that. Boot-to-Gecko, ultimately, is about doing that. But first, we have to break open the mobile web and expose the issues.

Today, Apple and Google – and therefore browsers based on Webkit – are dominating the mobile Web, and as a result developers are coding for a single rendering engine. Like we did with desktop, we have to ensure developers have access to truly open standards. And that means that we need to do whatever it takes to establish Gecko‘s presence on mobile – and specifically, on the Android platform which is widely forecast to grow more than any other in the next 5 years.

There are many ways you can join us in this battle, but if you’ve been wanting to test your skills by building a Web game, there’s never been a better time to try, and never for a better cause. And if you need a little help, there are many places you can ask, like our IRC channel, #devrel, the engagement-developers mailing list, or simply @mozhacks on Twitter. And, of course, if you do, we’ll make you MDN-famous, and treat you like a hero. Thank you.

The Liberated Pixel Cup is the brainchild of OpenGameArt, a long-standing community of artists that provide graphics and sound effects for others to use in their games. Joining us in supporting the competition are the Creative Commons, Free Software Foundation, as well as the hundreds of everyday supporters who donated to the prize fund.

Getting involved with the Liberated Pixel Cup was an obvious choice for us. Over the past year we’ve vastly improved our performance for games in Firefox, we’ve added new features for games, we’ve hosted a work week to discuss the future of games, we’ve attended and represented the open Web at important game-related events like GDC, as well as much, much more. To put it simply, we think games are pretty darn important to the future of the Web!

As part of our involvement, we’ll be:

• Supporting the HTML5 category of the competition
• Using our various spaces around the world to host Liberated Pixel Cup events
• Donating funds to support the running of the competition

The art side of the competition starts in June, with the code side starting in July; so mark those dates in your diary and get ready to create some game-related goodness!

Check out the Liberated Pixel Cup website for more information.

At the end of this blog post, you also have all the Developer Engagement team members and what they work on. If you are interested in discussing more, contributing or taking part of our work, don’t hesitate to contact us or follow us on Twitter!

Weekly links

If there is anything you think we should read or know about, don’t hesitate to post a comment, contact us on Twitter or through any other means.
The picks this week are:

• A separate mobile website: no forking way – by veteran interaction designer and content strategist Karen McGrane.
• Why Publishers Don’t Like Apps
• HTML9 Responsive Boilerstrap JS: Funny ha ha, and potentially NSFW.
• Did you ever need some knob controls in your tron-like layout? Here you go!
• Cross-Browser Debugging CSS
• LAB! – CSS 3D Earth
• iOS app success is a “lottery”: 60% (or more) of developers don’t break even
• Agile Design – Tapworthy Mobile Design
• mroth/lolcommits: Seeing is believing.

The Developer Engagement team

Mozilla’s Developer Engagement team work with writing articles, documentation – such as MDN (Mozilla Developer Network) – public speaking and generally helping and informing about open technologies and Mozilla products. If you are interested in following our work, here are the team members:

Introduction

Raphaël is a library originally written by Dmitry Baranovskiy and is now part of Sencha Labs.

The goal of this library is to simplify work with vector graphics on the Web. Raphaël relies on the SVG W3C Recommendation (which is well supported in all modern browsers) and falls back to the Micrsoft VML language in order to address legacy versions of Internet Explorer. It also tries to harmonize some working issues across SVG implementations such as the SVG Animations. As a consequence, Raphaël is a very nice wrapper to produce consistent kick-ass graphics all over the Web.

Basic usage

The library has very good documentation with many examples. Do not hesitate to use it extensively.

The following example will draw a simple red circle inside an HTML element with the id “myPaper”.

// the following example creates a drawing zone
// that is 100px wide by 100px high.
// This drawing zone is created at the top left corner
// of the #myPaper element (or its top right corner in
// dir="rtl" elements)
var paper = Raphael("myPaper", 100, 100); 
 
// The circle will have a radius of 40
// and its center will be at coordinate 50,50
var c = paper.circle(50, 50, 40); 
 
// The circle will be filled with red
// Note that the name of each element property
// follow the SVG recommendation
c.attr({
    fill: "#900"
});

Advanced usage

Despite the fact that Raphaël reduces the possibilities offered by SVG (mainly because of the VML fallback) it allows one to perform very advanced stuff:

• Advance Matrix transformation
• Advance event handler
• Cross browser animations
• Easy drag system
• Path intersection detection

Raphaël is also extensible through an extension system that allows you to build custom functions.

For example, here’s an extension to draw pie charts:

/**
 * Pie method
 *
 * cx: x position of the rotating center of the pie
 * cy: y position of the rotating center of the pie
 * r : radius of the pie 
 * a1: angle expressed in degrees where the pie start
 * a2: angle expressed in degrees where the pie end
 */
Raphael.fn.pie = function (cx, cy, r, a1, a2) {
    var d,
        flag = (a2 - a1) > 180; 
 
    a1 = (a1 % 360) * Math.PI / 180;
    a2 = (a2 % 360) * Math.PI / 180; 
 
    d = [
        // Setting the rotating axe of the pie
        "M", cx, cy,
 
        // Go to the start of the curve
        "l", r * Math.cos(a1), r * Math.sin(a1),
 
        // Drawing the curve to its end
        "A", r, r, "0", +flag, "1",
        cx + r * Math.cos(a2), cy + r * Math.sin(a2),
 
        // Closing the path
        "z"
    ]; 
 
    return this.path(d.join(' '));
};

Note: In the example above, you have to be familiar with the SVG path syntax (Raphaël will convert it to the VML syntax under the hood), but once it’s done you can reuse it as any other Raphaël primitive. Look at this extension working to draw a color wheel on jsFiddle.

Limits and precaution

If you are not familiar with SVG and/or want to support legacy MS Internet Explorer browsers, this tool is made for you. However, it’s a JavaScript library, which means that you have to know JavaScript to use it. You cannot use SVG and ask Raphaël to parse it and interpret it (to do that, it exists other libraries).

In terms of browser support, Raphaël gives you a large base. Raphaël currently supports Firefox 3.0+, Safari 3.0+, Chrome 5.0+, Opera 9.5+ and Internet Explorer 6.0+.

In fact, the only browser that can not take advantage of Raphaël is the native browser for Android 1.x and 2.x (and obviously many feature phone browsers). This is due to the fact that those browsers do not support any vector language. Android starts (partially) supporting SVG with Android 3.0 so take care if you want to work with all mobile devices.

Conclusion

Raphaël was the first library to allow web designers and web developers to use SVG in the wild. If you want to write some nice applications without the need of the full SVG DOM API or if you have to support legacy browsers, this library will give you some power.

In conclusion, here are some cool usages of Raphaël:

• http://vlog.it/
• http://type.method.ac/
• http://shape.method.ac/
• http://www.nissanusa.com/leaf-electric-car/index
• http://ilovedemocracy.arte.tv/fr/

One of the best things about HTML is that it’s never “done”.  HTML has been with us longer than most of the development technologies that we consider commonplace. (.NET, ASP, Java, PHP, etc.)

The latest incarnation of HTML, HTML5 has been the source of a great deal of buzz in the software and information industries. When we say “HTML5″, we’re implicitly referring to the “stack” of  HTML/CSS/JavaScript.

At Mozilla we often refer to this collectively as the “Web Run-Time” or WebRT for short. Mozilla’s apps initiative, including the Web Runtime is documented here.

Skeptics like to say “HTML5 is not ready”. This week I saw an article declaring HTML5 won’t be “ready” for another 10 years. To which I ask “ready for what?” Of course there are many APIs that are still under development, but for many scenarios HTML5 is ready now. For many other scenarios its ready for development now and will be ready for general public use in the near future.

Recently the Mozilla Apps Native Install Experience was introduced to the Firefox Nightly Channel. (Read here for more information about the Firefox release channels.)

This functionality lets us install an HTML5 application with a native launching experience on Windows or Mac (Linux and Android coming).

One great way to do this is to simply list your app in the Mozilla Marketplace. The Marketplace will be open to the general public soon and developers can submit their app now at the Marketplace Ecosystem Portal. All you need besides an app to submit is a set of BrowserID credentials.

An HTML5 App that targets the Mozilla Web Runtime includes a manifest file.

The manifest is simply a JSON file that declares certain data about the application.

Here is the manifest file from a sample app. You can read more about the Mozilla App Manifest here.

    {  
      "version": "1.0",  
      "name": "KO Round Timer",  
      "description": "A Workout Timer for Fighting Athletes!",  
      "icons": {   
        "128": "/images/icon-128.png"  
      },    
      "developer": {  
        "name": "Joe Stagner",  
        "url": "http://koscience.com"  
      },  
      "installs_allowed_from": [  
        "http://timer.koscience.com", 
	"https://marketplace.mozilla.org"   
      ],    
      "default_locale": "en"  
    }

JSON does not need to be formatted with CRLFs. The above JSON is only formatted to simplify display.

Note line #12 above which specifies where the app can be installed from.

The Mozilla Web Runtime includes an apps object (winbow.navigator.mozApps) The mozApps object (currently implemented in Firefox Nightly on Windows and Mac) has a method to install an application. We’ll look at code that uses that API in a minute.

If you want your app to install from the Mozilla Marketplace you don’t need to write any install code. When you list your app in the marketplace, the marketplace creates a listing page for your app and that page includes an install button.

The generated code that is invoked when the Install button is clicked tells the Runtime to install the app. The Runtime then fetches the manifest for the app and, among other things, checks to see it the app allows installation from whatever domain is requesting the install.

As you can see in the manifest listing above, line 14 specifies that the app may be installed from “https://marketplace.mozilla.org”.

But you might want to let users install your application from other domains, for example your own web site.

You can see line 13 in our sample manifest, listed above, that “http://timer.koscience.com” is also specified as a valid “install from” location. I can specify as many domains as I like to be authorized to install the application from and wildcards are supported.

If we want to install the app from our own web site however, we need to implement the install logic ourselves.

We could create a page similar to the app listing page on the Mozilla Marketplace, or could make the app “self installing” meaning that we could implement installation logic in the app itself.

Take, for example, the Workout Timer app shown below.

Notice the row of navigation buttons at the bottom of the timer.

The last one to the right says “Install Me”.

The install button should only appear if the app is running in an environment that supports the mozApps runtime. Since this app (K.O. Timer) is an HTML5 app it can run in any HTML5 compliant browser but will only be “installable” if it is running in a browser / runtime with mozApps support.

We also don’t want the install button to appear if the app is already installed.

Here is a JavaScript method to test both runtime support and install state.

If runtime support is present and the app is not install then an install button is displayed.

In some scenarios you might choose to forgo the display of an optional install button and simply start the installer when the app is not already installed.

(This code is using jQuery)

function TestAppInstalled() {
    if ((!navigator.mozApps) || (!navigator.mozApps.getSelf)) {
        /*-----------------------------------------------------------+
        || Test to see if the Mozilla Apps Web Runtime is supported
        || HACK: Testing for either mozApps OR mozApps.getSelf is a 
        || hack. 
        || This is needed because some pre-beta versions of Firefox 
        || have the object present but nit fully implemented.
        || TODO: Update when Firefox Desktop & Mobile are complete.
        ------------------------------------------------------------*/
        return;
    }
 
    var MyAppSelf = navigator.mozApps.getSelf();
    MyAppSelf.onsuccess = function() {
        if (! this.result) {
            // Application is not "installed"
            $('#InstallButton').show();
        }
        else {
             // This "MozApp" is already installed.
        }
        return;
    }
    MyAppSelf.onerror = function() {
        alert('Error checking installation status: ' + 
               this.error.message);
        return;
    }
}

When the user clicks on the install button the following code is called.

$('#InstallButton').click(function() {
    var installation = navigator.mozApps.install(
                "http://timer.koscience.com/kotimer.webapp");
    installation.onsuccess = function() {
        $('#InstallButton').hide();
        alert("K.O. Timer has been successfully installed.....");
    }
    installation.onerror = function() {
        alert("APP: The installation FAILED : " + this.error.name);
    }
});

So when the user navigates to the K.O. Timer app (timer.koscience.com) in a browser that supports mozApps (currently Firefox Nightly) and the user clicks on the “Install Me” button the mozApps runtime starts the installer.

After the user clicks “install” button in the dialog pictured above, the installer is called and, when completed, the user has a native launching experience.

On Windows you get a desktop shortcut.

As well as a Start Menu item.

And, of course the app is now in the user’s Mozilla MyApps collection.

It’s important to remember that, while these launchers have been created on the user’s system the application itself still exists in the cloud. A developer can choose to add “off line” functionality to their application by other HTML5 features like AppCache, LocalStorage or IndexedDB.

The ability to provide native launchers for HTML5 apps, coupled with the huge HTML5 apps distribution mechanism that will be available when the Mozilla Marketplace become available to the general public (in the near future), creates great opportunity for developers building standards based apps.

If you have no idea what hack day in MDN means, check out Tristan Nitot’s introductory post.

There are still tickets available, so go to http://mdn-hackday-london.eventbrite.com/ and sign up if you haven’t yet.

There’ll be food (well, Pizza, we thought Fondue would be too much of a mess) and drink (the non-fermented and fermented kind, we don’t discriminate), lots of experts from Mozilla to pester about your wishes for our products and to learn all about what we are doing in London, a few Boot to Gecko phones to play with and quite a few talks to give you inspiration to hack:

Schedule (subject to change slightly but you get the idea of who is speaking):

8:30 Registration & Light Breakfast
9:00 Welcome Remarks Christian Heilmann
9:15 Christian Heilmann – The New Web Challenge
9:45 Rob Hawkes – B2G
10:15 Chloe Varelidi – Catch Them Young – Meet the Web Arcade
10:45 Brad Lassey – Fennec Goes Native
11:15 Break
11:30 Heather Arthur – Firefox DevTools
12:00 Jean Yves Perrier – BrowserID
12:30 Rob Hawkes – Games
1:00 Paul Lewis – WebGL Live Demos
1:30 Lunch (Lightening Talk/Discussion Group Sign Up)
2:30 Hacking
5:15 Presentations and Lightning Talks
5:30 Refreshments

The hashtag to use is #mdnhackday, the wireless is open, the Fox is out there, let’s do this!

Although Snappy first contributed fixes to Firefox 11, Snappy’s most noticeable contributions to date are landing with Firefox 13. Currently in beta, this release includes a number of responsiveness related fixes, most notably tabs-on-demand, cycle collector improvements, and start-up optimization.

Tabs -on-Demand

Tabs-on-demand is a feature that reduces start-up time for Firefox windows with many tabs. In Firefox 12, all tabs are loaded on start-up. For windows with many tabs this may cause a delay before you can interact with Firefox as each tab must load its content. In Firefox 13, only the active tab will load. Loading of background tabs is deferred until a tab is selected. This results in Firefox starting faster as tabs-on-demand reduces processing requirements, network usage, and memory consumption.

Cycle Collector

As you interact with the browser and Web content, memory is allocated as needed. The Firefox cycle collector works to automatically free some of this memory when it is no longer needed. This action reduces Firefox’s memory usage. In Firefox 13, the cycle collector is more efficient, spending less time examining memory that is still in use, which results in less pauses as you use Firefox.

Start-up

Firefox start-up time is visible to all users. Our investigation into start-up has identified a number of unoptimized routines in the code that executes before what we call “first paint”. “First paint” signifies when the Firefox user interface is first visible on your screen. In Firefox 13 we have optimized file calls, audio sessions, drag and drop, and overall IO, just to name a few. We are continuing to profile the Firefox start-up sequence to identify further optimizations that can be made in future releases.

There are numerous other Snappy fixes in Firefox 13 including significant improvements to IO contention, font enumeration, and livemark overhead. All of these fixes contribute to a more responsive experience. We are already working on further responsiveness fixes for future Firefox releases. You can expect to see Snappy improvements in upcoming releases in areas such as memory usage, shutdown time, network cache and connections, menus, and graphics.

The original idea behind DOM Mutation Events is still appealing, however, and so in September 2011 a group of Google and Mozilla engineers announced a new proposal that would offer similar functionality with improved performance: DOM MutationObserver. This new DOM Api is available in Firefox and Webkit nightly builds, as well as Chrome 18.

At it’s simplest, a MutationObserver implementation looks like this:

// select the target node
var target = document.querySelector('#some-id');
 
// create an observer instance
var observer = new MutationObserver(function(mutations) {
    mutations.forEach(function(mutation) {
        console.log(mutation.type);
    });    
});
 
// configuration of the observer:
var config = { attributes: true, childList: true, characterData: 	true }
 
// pass in the target node, as well as the observer options
observer.observe(target, config);
 
// later, you can stop observing
observer.disconnect();

The key advantage to this new specification over the deprecated DOM Mutation Events spec is one of efficiency. If you are observing a node for changes, your callback will not be fired until the DOM has finished changing. When the callback is triggered, it is supplied a list of the changes to the DOM, which you can then loop through and choose to react to.

This also means that any code you write will need to process the observer results in order to react to the changes you are looking for. Here is a compact example of an observer that listens for changes in an editable ordered list:

<!DOCTYPE html>
<ol contenteditable oninput="">
  <li>Press enter</li>
</ol>
<script>
  var MutationObserver = window.MutationObserver || window.WebKitMutationObserver || window.MozMutationObserver;
  var list = document.querySelector('ol');
 
  var observer = new MutationObserver(function(mutations) {  
    mutations.forEach(function(mutation) {
      if (mutation.type === 'childList') {
        var list_values = [].slice.call(list.children)
            .map( function(node) { return node.innerHTML; })
            .filter( function(s) {
              if (s === '<br>') {
                return false;
              }
              else {
                return true;
              }
        });
        console.log(list_values);
      }
    });
  });
 
  observer.observe(list, {
  	attributes: true, 
  	childList: true, 
  	characterData: true
  });
</script>

If you want to see this code running, I’ve put it up on jsbin here:

http://jsbin.com/ivamoh/53/edit

If you play with the live example, you’ll notice some quirks in behaviour, in particular that the callback is triggered when you press enter in each li, in particular when the user action results in a node being added or removed from the DOM. This is an important distinction to be made from other techniques such as binding events to key presses or more common events like ‘click’. MutationObservers work differently from these techniques because they are triggered by changes in the DOM itself, not by events generated either via JS or user interaction.

So what are these good for?

I don’t expect most JS hackers are going to run out right now and start adding mutation observers to their code. Probably the biggest audience for this new api are the people that write JS frameworks, mainly to solve problems and create interactions they could not have done previously, or at least not with reasonable performance. Another use case would be situations where you are using frameworks that manipulate the DOM and need to react to these modifications efficiently ( and without setTimeout hacks! ).

Another common use of the Dom Mutation Events api is in browser extensions, and in the next week or so I’m going to publish a follow-up post on how MutationObservers are particularly useful when interacting with web content in a Firefox Add-on.

Resources

• Original Proposal
• W3C Spec
• Screencast by Rafael Weinstein
• Mutation Summary, a JS library that simplifies MutationObserver usage.

At the end of this blog post, you also have all the Developer Engagement team members and what they work on. If you are interested in discussing more, contributing or taking part of our work, don’t hesitate to contact us or follow us on Twitter!

Weekly links

If there is anything you think we should read or know about, don’t hesitate to post a comment, contact us on Twitter or through any other means.
The picks this week are:

• WebGL Transforms
• Processing XHR2 file uploads in PHP
• Promises and timing in JS: “Write logic, not mechanics”
• How Gliffy is managing the risk of rewriting their product in HTML5
• CamanJS – Image Manipulation in Javascript
• Hiding content untangled: Hiding vs. moving out of the visible viewport. (We don’t always do this right on Mozilla sites, but we’re working on making them better.)
• Great video that shows how to get started with Canvas really quickly: CreativeJS for non-coders on Vimeo
• ChromaPad
• How to revive the Web: 10 Hypotheses (PDF)

The Developer Engagement team

Mozilla’s Developer Engagement team work with writing articles, documentation – such as MDN (Mozilla Developer Network) – public speaking and generally helping and informing about open technologies and Mozilla products. If you are interested in following our work, here are the team members:

Outside the usual categories of docs, Tom Lowenthal created a page of privacy policy guidelines, with help from Jishnu Menon, along with a privacy policy template that you can fork on Github. If you missed the earlier Hacks post about privacy guidelines, check it out.

Help needed

Fbender added a note to the Talk page for JavaScript Functions and function scope that “conditionally defining a function throws an error in at least ES5 strict, possibly non-strict (at least soon), too, see Bug 609832 and Bug 585536. The section Conditionally defining a function should be updated to reflect those changes.” Want to make that change? Go for it!

Web standards docs

• Airportyh added compatibility info to event.defaultPrevented.
• Will Bamberg updated Browser detection using the user agent.
• Ethertank created or updated translations on a bunch of Japanese pages.
• Fusionchess continued to be prolific:
  • Added an example of using a Blob object to Using XMLHttpRequest.
  • Added an example of the constructor to Blob.
  • Updated and expanded Object defineProperty.
  • Modified the example for using ‘apply’ to chain constructors in Function apply.
  • Created a page for JXON.
  • Made JSON consistent with other technology landing pages.
  • Added a code example and cross-references to How to create a DOM tree.
• Fusionchess and Hitautodestruct both expanded the information on ternary evaluation Conditional operator.
• Bertrand Malet added code examples to element.onmouseout and element.onmouseover.
• Masayuki updated KeyboardEvent and added ‘getModifierState’ to MouseEvent.
• Timoté Neullas translated Adding 2D content to a WebGL context into French.
• OoOoOoOo created border-image-slice.
• Jeremie Patonnier created pages for the SVG attributes color and color-profile.
• Thierry Régagnon added browser compatibility info to transition-duration and translated several other pages into French.
• Eric Shepherd added a list of status codes to the WebSockets CloseEvent reference page.
• Masataka Yakura updated compatibility and added external references to console.dir, console.log, console.error, console.info, console.warn, Blob and BlobBuilder.
• Ziyunfei translated or updated translations on a bunch of Chinese pages. Really, really a lot of Chinese pages.

Mozilla technology docs

• Malina Das created a page on Emulator integrated tests for Marionette and updated Marionette Python tests.
• Greg Koberger added info on serving manifests from Apache to Apps Manifest
• Nickolay Ponomarev added a section on instructions supported in bootstrapped extensions to Chrome registration, updated and corrected Bootstrapped extensions, and updated nsIComponentManager.
• Eric Shepherd created a page to document Using the source editor in Firefox developer tools.
• Till Schneidereit created Setting up CDT to work on SpiderMonkey.

Two weeks ago, the Firefox team got together for a work week in Toronto. It was amazing. Walking through a room with that many excellent people doing excellent things was inspiringhumblingunbelievable and the hits kept on rolling.

The combined mobile and graphics teams cut the beta blocker list for Fennec Native in half. The desktop team banged together a working prototype of sign in to the browser. The firefox tech leads worked with product and project management to nail down the kilimanjaro bug list for desktop. Madhava gave a great talk about the future of Firefox UX. I would have scored it as a strong success based on those outcomes alone.

And then this happened:

Hacking

• Scratchpad backending to github gists
• Jetpacks in scratchpad
• Task-specific icons in Windows 7 jumplists
• Finalized interactions and designs for the new downloads manager
• Sync meet-up and discussion to evaluate how to move forward with a smaller core, by moving data handling to components and allowing the Sync team to concentrate on the real Sync functionality
• Session Store meet-up and discussion on how to move forward with “Speedy Session Restore” as well as SS2 (rewriting SS).
• Initial explorations of a Fennec reading mode (post-1.0)
• Implemented Windows 8 appbar
• Roll your own one-off, bespoke debuggers in the scratchpad.
• Responsive Design tool for web developers

Lightning Talks

• Honza made Firebug’s HTTP Monitor a standalone component, and it can now remote-monitor fennec, too
• Gavin gave a great talk about code review
• Tim Abraldes demoed the Web App runtime
• Margaret walked us through Hacking Fennec
• Brian Bondy updated the status of our Windows 8 work
• Felipe found and fixed memory leaks with about:cc
• Dietrich walked through the state of the browser components team
• David Dahl went meta, and talked about giving Firefox talks in our community

I know I’ve missed things. I know some of it is still being written up. In fact, I’m not even the first to write a round up post. Here’s Finkle doing the same, and dcamp, and cwiiis.

FX-Team is big enough these days that it’s quite an undertaking to get us all together in one place. But man, it’s phenomenal when we do.

Articles

• Financial Times passes 2m users for its HTML5 web app
• Coding the future: HTML5 takes the internet by storm
• Utilize JavaScript messaging with postal.js
• Open Source Metro style theme for jQuery Mobile
• JavaScript Style Guides And Beautifiers
• Spine.js vs Backbone.js
• HTML5 – You’ll never believe how LinkedIn built its new iPad app

Resources

• 10 useful libraries for JavaScript developers
• HTML5.org – The Web platform: Browser technologies index
• The Jasmine Unit testing framework for JavaScript applications
• Screenful.js – Simple wrapper for cross-browser usage of the JavaScript Fullscreen API
• Fixie.js – JavaScript tool to automatically add filler content to HTML documents
• skrollr – A JavaScript library to animate any CSS property of any element based on the horizontal scrollbar position
• Cookies – Client-Side Cookie Manipulation API
• JSCheck – a testing tool for JavaScript

Bonus Link

• DevCon5 Video Presentation – Node.js in Context with Jason Hoffman of Joyent

If you find a link that you think should be included, please feel free to forward it to JStagner at Mozilla.com

This month, we are excited to see what you can do with Websockets. Websockets allow you to send messages to a server and receive event-driven responses in real time, without server polling. But this is about more than just sending messages. Websockets have been used in BrowserQuest, Rawkets, and many other highly interactive applications.

Setting up a Websockets demo is more involved than setting up a static demo, but we know you can do it. As long as you keep these three simple rules in mind, everything should work flawlessly.

1. To use Websockets, you need a server to communicate with. Thankfully, free services like Heroku and Nodejitsu provide just that.
2. You do not need to use Heroku or Nodejitsu. If you use a different server, however, you must ensure that it has a signed SSL certificate.
3. When building your demo, be sure to use the wss:// prefix (not the ws:// prefix) to specify the address of your server.

If you have any questions about setup, please let us know in the comments. We will work with you to resolve any issues you encounter. Otherwise, good luck and have fun!

Want to get a head start on a future Derby? We are also accepting entries related to the WebGL (June Derby) and demos that push the limits of the web without using JavaScript (July Derby).

Firefox release channels

Basically, we have four different Firefox release channels:

Firefox Release

The official release of Firefox.

Firefox Beta

Testing the next version of Firefox befire it becomes the official release.

Firefox Aurora

For web/platform developers and early adopters.

Firefox Nightly

Nightly releases that contains experimental features. (covered regularly on Twitter from @firefoxnightly)

Firefox release timeline

Firefox is released on a six week schedule, meaning that every sixth week there will be new versions of Firefox Release, Firefox Beta and Firefox Aurora. Nightly is, naturally, released every night.

Running multiple versions of Firefox at the same time

There are many different ways of running multiple versions of Firefox at the same time. What it all comes down to is setting up different profiles that you have per each web browser instance. The easiest way is most likely to use the Profile Manager, as described on MDN.

If you are on Mac OS X, it’s easy to use the automated version of setting up multiple profiles of Firefox.

Another option, in plain code and as outlined in Multiple Firefox Instances, is to just launch the Profile manager directly:

# On Windows click Start > Run then:
"C:\Program Files\Mozilla Firefox\firefox.exe" -no-remote -ProfileManager
 
# Mac OS X and Linux, in Terminal
firefox -ProfileManager
 
# Depending on system/setup, you might need to do this from the directory
./firefox -ProfileManager

Testing Firefox Aurora

The version of Firefox that is the best version to test for web developers is Firefox Aurora. It is in a stable enough condition to use, but also has features at their latest stage before they become approved. Therefore, your chance to affect implementations, find bugs, improve features is when it has become Firefox Aurora – likewise, it gives us a better chance to ensure that when Firefox is officially released, all the things are in place in the best possible manner.

Therefore, please take the time to test out Firefox Aurora and new features, so we can together help Firefox and the web better!

Many Thanks Yous, One Mozilla

It was a whirlwind week and a half for the crew of the Mozilla MDN Hack Day Tour in Latin America. Over the course of 10 days we visited four cities in four countries in the Conosur, the southern part of South America. We met hundreds of developers in Buenos Aires, Argentina; Montevideo, Uruguay; Sao Paulo, Brazil; and Santiago, Chile. Thanks to everyone who took the time to listen, to talk with us, and make us feel welcome.

Our message was well-received: The Web is the platform and it’s built from open technologies. On this trip, we were eager to introduce some of the new projects Mozilla is working on now to keep the Web open as more of the world goes mobile. As a non-profit committed to promoting openness, innovation and opportunity on the Web, Mozilla works best with inputs and participation from communities everywhere.

In South America, we were a small team, carrying passports from Argentina, Canada, Sweden, Venezuela and the U.S. We spoke in a mix of Spanish and English. Personally I wish more of us had spoken Spanish, but because of my own language limitations, I was extra happy to listen to Spanish-speaking presenters at each of our events.

We talked about HTML5 & friends and new Javascript APIs. We introduced exciting new Mozilla open source projects like Boot-to-Gecko (B2G), our open web phone project that’s just getting started; the soon-to-be-launched Mozilla Marketplace for HTML 5 apps (presented by Mozilla Labs’ Shane Caraveo), and Mozilla Persona, a new identity system for the Web (presented in Spanish by Dan Mills).

In Argentina and Uruguay, Telefonica’s Andres Leonardo Martinez Ortiz introduced BlueVia, the developer program and platform from Telefonica, Mozilla partner and MDN Hack Day sponsor. In Buenos Aires, Kevin Dangoor spoke about the developer tools Mozilla is building and Buenos Aires-based add-ons developer and evangelist Hernan Colmeiro spoke about the beauty of add-ons. In Santiago, Chile, Hernan wowed developers with a Boot-to-Gecko demo.

There were dozens and dozens of individuals who helped make our tour a success, including Mozillians I work with every day and people I’d never met till we arrived in their country. The big risk in writing long thank-yous is that I will unintentionally to forget to mention someone essential, so please accept my apology in advance and don’t hesitate to use the comments.

Buenos Aires

We came to Buenos Aires for MozCamp LATAM, Mozilla’s first community gathering held in Latin America, co-hosted by the amazing, multi-national Mozilla Hispano community and their Portuguese-speaking neighbors from Mozilla Brazil.

On the Friday before MozCamp we organized a day-long Hack Day for developers from Buenos Aires. Over 150 developers attended a morning of talks and demos, followed by an afternoon of project hacking. After lunch, a lively group gathered around Add-ons developer Jorge Villalobos, while other attendees were riveted by Philikon’s demo of the Boot-2-Gecko phone.

MDN Hack Day would not have succeeded without the outreach, organizational support and hospitality of Felipe Lerena, Guillermo Movia, and Santiago Hollman of the Moz Hispano community. And I’ll add a special shout-out to the Mozcamp LATAM planning committee: Mary Colvig, Chris Hofmann, Santiago Hollmann, Gloria Meneses, Ruben Martin, Reuben Morais, Guillermo Movia, and the unflappable Katherine Naszradi. This couldn’t have happened without your support!

Montevideo

The crew left Buenos Aires on a sunny Monday afternoon, and crossed the Rio de la Plata by Buquebus ferry, arriving in Montevideo at nightfall, after a choppy 3-hour crossing.

The next morning I met up with old friend and colleague Evan Henshaw Plath, and new friends Diego Algorta, Elena Vilar and the Cubox Labs team who’d been helping us organize, promote and host MDN Hack Day in Montevideo. They work together in a classic 1920s home converted to a co-working space in a leafy residential neighborhood. I met our evening’s speakers, along with Frenchman Jean-Paul Massonnier, an awesome designer, who’d created a poster that was pure Mozilla. I drank delicious coffee and chatted with developers in the kitchen overlooking a garden where coders kicked a football around in the sunshine.

We headed over to Cafe La Diaria. La Diaria is a subscription-based independent newspaper that is now the 2nd most widely read paper in Uruguay. It is run cooperatively and distributed by employees, with a commitment to the highest journalistic standards. Cafe La Diaria is a venue and community space in the old downtown of the city. Here we met our hosts Damian and Antonieta, who cooked up delicious pizza at the break. Cubox’s Nicolas Barrera gave an entertaining and enlightening talk about responsive design, and Fernando Briano, Cuboxer and noted tech blogger served up a presentation on the web as a tool for Social Change.

In addition, there were two lightning talks: On his last night in Montevideo before moving to Berlin, MDN demo contributor and Developer Derby winner Alvaro Mourino (aka Tuxie) stopped by to talk about our Dev Derby and encourage people to participate. Dario Clavijo, a tech blogger and IT professional in Montevideo, spoke passionately about the importance of free and open software. It was his first ever lightning talk and we were honored to hear from him!

Sao Paulo

Robert Nyman, El Sueco, made the trip to Brazil by himself, since the rest of us yanquis were lacking visas. Here’s his report:

“The next leg of the tour, helpfully organized by local company Caelum, [was] a Mozilla one-man show from me giving two talks in Sao Paulo:

• HTML5, the Open Web and what it means to you
• JavaScript APIs – The web is the platform

In addition to that, local developer Gabriel Oliveira spoke about CSS3, and from what I could understand, he showed some really interesting things!

There were about 40+ attendees this very rainy night in Sao Paulo, and while there weren’t many people, I was really happy to see the nods of approval in the audience during my talk, when I expressed Mozilla’s values and approach to the web and moving forward. After my presentations, we stood around for a long time discussing the web, -webkit prefixes, H.264 support and more. People seemed to be understanding and pragmatic, and I believe there were some really talented people there.

Additionally, I got to spend some time being guided around by local community members Fábio Magnoni and Clauber Stipkovic, who I got to know in person at MozCamp in Buenos Aires, and had interesting discussions!”

Santiago, Chile

Our final Hack Day of the LATAM tour took place in Santiago, Chile on an overcast Saturday evening. We met in a comfortable classroom at the University of Chile’s Escuela de Economía y Negocios. Jano Gonzalez, a Ruby blogger and all around nice guy made the arrangements. His friends Paulina and Rodrigo took some of the team on a tour of the city.

More than 50 attendees came out to hear from us. Pizza Hut (!) delivered pizza during the break. Hernan Colmeiro came out from Buenos Aires to introduce Add-ons and to demo Boot-to-Gecko. And Jonathan Gonzalez, no relation to Jano, introduced the Monkey Project, a fast and scalable web server for Linux.

We had a strong showing of lightning talks: including presentations delivered in English, with slides in Spanish; presentations in Spanish, with slides in English; a compelling pitch by Ricardo about why you should overcome your shyness and get up at events to give talks about the stuff you know; a hilarious parody of a framework that was probably NSFW, but I didn’t understand enough of the Chilean slang so I can’t be sure; and an introduction to Poderopedia, a database that aims to map the relationships between political and financial power in Chile. We also met some entrepreneurs from the Startup Chile accelerator, and on Monday a couple of us had a chance to visit their lively space.

In conclusion

Huge thanks to the rest of the team – everyone was upbeat, professional, collaborative, and more fun than a barrel of monkeys: Shane Caraveo, Hernan Colmeiro, Dan Mills, Robert Nyman, and a special shout-out to Shezmeen Prasad, event organizer extraordinaire, who invited me along. Props also to Jeff Griffiths, who put it all together behind the scenes, from somewhere in Canuckistan. Gracias!

Photo credits: Prima Limon, thunder, and freshelectrons.

Update 2012-05-08: Thanks to last-minute magic by Mozilla IT, MDN won’t be completely unavailable after all. However, it will be running on a single virtual machine rather than three physical servers, so expect worse than usual performance during the time frame described below.

Mozilla Developer Network will be down for maintenance and completely unavailable for approximate eight hours on Tuesday, May 8th, 2012, starting at 15:00 UTC (Tue 17:00 CET, Tue 11:00 US-EDT, Tue 8:00 US-PDT). It should be back online by 00:00 UTC on Wednesday May 9th (Wed 02:00 CET, Tue 20:00 US-EDT, Tue 17:00 US-PDT).

During this time, the site will not be available for viewing or editing, so please make sure to save all your edits and be prepared in advance — maybe go outside and get some fresh air — MDN will be back before you know it.

Meanwhile, here are some alternative resources:

Open Web standards:

• DocHub mirrors content from MDN and other sources
• Dev.Opera has lots of Web technology articles
• W3C Web Design and Applications is a landing page for Web standards
• Safari Developer Library has many articles on Web development

Mozilla stuff:

• Mozilla wiki has all kinds of information related to the Mozilla project

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.

At the end of this blog post, you also have all the Developer Engagement team members and what they work on. If you are interested in discussing more, contributing or taking part of our work, don’t hesitate to contact us or follow us on Twitter!

Weekly links

If there is anything you think we should read or know about, don’t hesitate to post a comment, contact us on Twitter or through any other means.
The picks this week are:

• lake.js – Takes an img element and inserts a canvas element displaying the image and its flipped reflection directly after the img element
• Great rant on when to take your legacy code out back with a shotgun
• WebSockets: A Guide – Build New Games
• The Instagram Architecture Facebook Bought for a Cool Billion Dollars
• Don’t docwrite scripts
• Multiple Firefox Instances
• The three “bad” parts in JS aren’t so bad, just mind-bending and worth reviewing occasionally
• Augmented Paper
• Light Table – a new IDE concept

The Developer Engagement team

Mozilla’s Developer Engagement team work with writing articles, documentation – such as MDN (Mozilla Developer Network) – public speaking and generally helping and informing about open technologies and Mozilla products. If you are interested in following our work, here are the team members:

What is MDN?

Please, don’t laugh, you have no idea how many times I have heard this.

To get straight to the point, MDN is the Mozilla Developer Network. It’s a web site centralizing almost all the documentation about Mozilla products. Basically this site hosts three kind of resources:

• Articles and links to external resources to learn how to use web technologies
• Demos of cutting edge Web technologies available in modern Web browsers (Those demos come from the monthly Dev Derby contest organized by John Karahalis)
• Reference documentation (API, elements, attributes, properties) for Mozilla technologies and more important, reference documentation for all open Web technologies (HTML, CSS, JavaScript, SVG, WebGL, etc.)

The last part, the open Web documentation, is the most important (in terms of volume as well as quality) and the one where Mozilla currently puts its biggest effort. One thing to mention is the fact that this documentation is browser agnostic, with compatibility tables and implementation notes for all browsers, not just Firefox.

Even if this documentation can be considered as one of the best currently available on the Web, it’s far from complete, and you are more than welcome to help with filling the gaps ;)

Is it difficult to contribute?

Not at all, on the contrary, it’s amazingly simple. I even think it is the easiest way to contribute to Mozilla (there is no need to deal with Bugzilla :-P)

Actually, to contribute to MDN, you need two things:

• The will to contribute
• A user account on MDN

And that’s all.

The hardest things to do is to find the “Sign in” button in the upper right corner of the site, stuck between the search field and the ugly white Mozilla tab‚ — yeah, yeah, yeah not really the best place. Once you click it, you are prompted for an e-mail address and a password (MDN uses Mozilla Persona/BrowserID). After that, on the next page, you just have to provide a “user name” to identify your contributions on MDN and voilà, you are ready to contribute.

For its part, contributing is also really simple. Basically, MDN is 80% a wiki. So, on each page of the wiki, you’ll find an “Edit” button (in the upper right corner). Click it to load the page content into a WYSIWYG editor (don’t worry, if you want to be hardcore, you can switch to raw HTML editing). Make all the changes you want and save them (by clicking on the “Save” button on the upper left corner). Congratulations, you’ve made your first contribution to MDN and Mozilla: no stupid publication process, no delay, no review (of course, you can ask for it, but it’s not required) — too easy :)

What can I do, where do I start?

The short answer is “whatever and wherever you want”. Unfortunately, experience has shown me that it’s not the answer expected by newcomers.

Basically, you can do two things on MDN:

• Submit demos to the Dev Derby demos monthly contest, which is pretty cool if you are a developer.
• Contribute to the documentation if you feel you have the heart of a writer.

Contributing to the documentation can be done in several ways, depending on the time and the will you have to get involved:

• Writing new articles
  It’s the most time consuming contribution. However, it’s also the most useful to the most people.
• Localizing content
  If you are familiar with a language other than English it is a good idea to translate existing material into that language. Not everybody uses English all around the world and it’s important to make the Web accessible to anyone.
• Writing code samples
  Explanations are good, but examples are better. Many times, a good example can make things much more understandable than five paragraphs of rubbish text. So writing code samples is one of the most useful contributions and MDN really needs more.
• Reviewing content
  As I said before, the review process on MDN is really limited but contributors can explicitly ask for review (through a tagging system). These can be editorial reviews as well as technical reviews. (Look for NeedsTechnicalReview or NeedsEditorialReview tags on pages; remove the tag if the page is OK.) If you have a small amount of time, it’s the perfect contribution that will help a lot of people.
• Updating compatibility tables
  MDN’s open Web documentation is becoming more browser agnostic. To achieve that goal, there are many pages on MDN with browser compatibility tables. They allow users to know which API, element, attribute, or property is available for each browser. This is amazingly useful and it only take five minutes to add some compatibility data. Without a doubt, it is the easiest and fastest way to contribute to MDN.

One last tip. Documenting the open Web is a huge task that no one can perform alone. As a consequence, it’s a good idea to focus yourself on the topics you are interested in personally. If you want to work on a specific subject, know that MDN has “Topic Drivers” that can help you; feel free to contact them. They will be more than happy to assist you.

To complete this, there two introductory pages on MDN that can be quite helpful:

• Getting started
• To-do list

Conclusion

As you can see, contributing to MDN is quite simple. If you want to know more feel free to ask your question on IRC at irc.mozilla.org on the #devmo channel or through our mailing list/Google group dev-mdc. If you want to speak to someone, the best entry points are Eric Shepherd (aka Sheppy), Janet Swisher and Jean-Yves Perrier (Teoli). Those three people are Mozilla employes dedicated to MDN so don’t worry about contacting them; they signed up for it :-P

Long live the documentation :)

My involvement was to talk about the state of HTML5 when seen from a native market’s perspective, show some cool new technologies that need our input and take part in the browser panel to discuss current issues. Here are the talks and screencasts. Videos recorded by the organisers should follow soon.

Talk “Broken HTML5 promises – are we ‘appy?”

The main Mozilla presentation was about feedback on HTML5 we got at Mobile World Congress from mobile developers, how we as an HTML5 community fail to answer their questions and get tangled up in petty bickering over details instead and what Mozilla does to make HTML5 work across the board.

The slides with notes are available here and the screencast (with bad audio, sorry) is on vid.ly.

Breakout session: “The bleeding edge of HTML needs blood donors”

The breakout session (which was repeated twice) was much less of a “talk” but more of a show and tell in a smaller room. Therefore the screencast is a bit more raw but shows what you can do right now.

The slides with notes are available here and the screencast is on vid.ly.

The conference

All in all the conference was great value for money. All the speakers had great information to give and there was no “marketing talk” promising things that don’t work outside lab environments.

• Michael Mahemoff did a great job introducing the day with a “native vs. web knockout” talk.
• Paul Kinlan showed what is coming in Chrome and how Web Intents can change the way we solve app communication over the web
• Martin Beeby gave a glimpse of how the web can merge with newer devices and UX needs of users

Seb Lee-Delisle took all the browsers to the performance test to end all performance tests by animating millions of 3D particles and seeing which browser would be the one that can show the most without slowing down. In the end Firefox was the winner with 3695244 particles at 10FPS. Of course this is not a real measure (especially seeing IE10 was run in a VM) but it is always fun to see Seb code live.

I guess my favourite piece about the conference was that the browser panel was very much about answering people’s questions instead of trying to beat each other in being the browser that people should use. British understatement at its best.