Articles by Joe Stagner

Sort by:


  1. Desktop Apps with HTML5 and the Mozilla Web Runtime

    Desktop Apps with HTML5

    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": ""
          "installs_allowed_from": [
          "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.

    Mozilla Marketplace App Listing Page

    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 “”.

    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 “” 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.

    K.O. Timer Screen Shot

    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.
        var MyAppSelf = navigator.mozApps.getSelf();
        MyAppSelf.onsuccess = function() {
            if (! this.result) {
                // Application is not "installed"
            else {
                 // This "MozApp" is already installed.
        MyAppSelf.onerror = function() {
            alert('Error checking installation status: ' +

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

    $('#InstallButton').click(function() {
        var installation = navigator.mozApps.install(
        installation.onsuccess = function() {
            alert("K.O. Timer has been successfully installed.....");
        installation.onerror = function() {
            alert("APP: The installation FAILED : " +;

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

    KOTimer at Install Click

    KOTimer at Install Click Closeup

    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.

    Native Shortcut for HTML5 App

    As well as a Start Menu item.

    HTML5 app in the Windows Start Menu

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

    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.

  2. Announcing Firefox Aurora 10

    We’re happy to announce the availability of Aurora 10.
    (Download and Test Aurora 10)

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

    New additions

    Developer Tools

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


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

    Web workers

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


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


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

    Offline: IndexedDB enhancements

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


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


    • Implemented Document.mozFullScreenEnabled.
    • Enabled the DOM full-screen API on desktop Firefox by default.
  3. The Mozilla Marketplace is now open for app submissions

    The Web IS the Platform!

    Using HTML, CSS and JavaScript, a developer can build an app using responsive design, and that app can offer the same look and feel as a device-native app, without having to rewrite for every desired target platform. One code base – all popular devices!

    Now, developers can build apps and submit them to the Mozilla Marketplace, so that when the consumer side of the marketplace launches later this year, your apps will be listed and consumers will be able to begin installing and using your apps from the first day of business.

    Why use standards-based Web Development for apps?

    Developers and organizations large and small have expressed interested in building apps for the Mozilla Marketplace. These apps are built using HTML5 for app structure; CSS3 for layout, visual aesthetics, and visual behaviors; and JavaScript for logical implementation.

    This combination of the latest standards-based Web development technologies is enjoying unprecedented popularity and is changing the way we build both websites and apps.

    As always, Mozilla is actively participating in the open Web standards processes and leading the community to define the necessary extensions to existing technology that will permit developers to build apps without technical impedance. For more detail, read Brendan Eich’s recent post on Mobile Web API Evolution.

    On the platform side we’re not only working on the standard “Web technology stack,” but also on all of the device APIs that will ultimately make the platform “rock.”

    For right now, we are focused on supporting mobile apps that will run across all modern, HTML5 capable Web browsers.

    The Mozilla Web Apps platform will feature:

    • The Mozilla Marketplace, the first operating system- and device-independent market for apps based on open Web technologies like HTML5, JavaScript and CSS.
    • New Mozilla-proposed APIs that advance the Web as a platform and will be submitted to the W3C for standardization.
    • A new identity system for the Web that puts users in control of their content, tying apps to the user and not the device or platform.

    Why build apps for the Mozilla Marketplace?

    The Web is the world’s largest single marketplace. By exposing apps through Mozilla’s existing communities, an app can launch to a marketplace of nearly half a billion prospective customers. Developers can also offer their apps via their own sites.

    On the Marketplace side, we’ve been working on identity integration with Persona (BrowserID). We’re also developing payments, app sync, backup and recovery, as well as an outstanding online app discovery and acquisition experience, so that both consumers and developers can easily get what they want from the Marketplace experience, on the front side or on the back end.

    What’s in this release?

    The Mozilla Marketplace is now open for developer app submissions. That means you can secure your app’s name and place in the Marketplace in preparation for the consumer launch later this year and familiarize yourself with the developer side of the Marketplace process.

    So, follow these links below to get started building your apps and then submit them to the Mozilla Marketplace!

    Apps on MDN –
    Mozilla Apps Wiki –
    HTML5 Docs –
    Mozilla Persona –

    And, join the discussions: for marketplace specific questions. for general apps questions.

  4. HTML5: The difference between an App and a Page.

    HTML5 is only one part of the”Stack”

    HTML5 is really more than one thing. In the strictest sense, HTML5 is fifth major revision of the W3C specification of the markup language that is used to create web pages.

    But in a practical sense, HTML5 is far more than that. For developers, HTML is a wave of technologies that are evolving and gaining browser implementations along roughly the same time-line as the markup language itself. Many of the related technologies are being spearheaded by the Web Hypertext Application Technology Working Group (, but still other technologies in this genre are driven from elsewhere. For example WebGL, the 3D rendering engine for Web Apps, is driven at Khronos, and Mozilla’s WebAPI team is leading a collection of relevant API work including a comprehensive array of device-specific APIs. And the W3C was a Device APIs Working Group

    Mozilla is also investing heavily in an initiative to facilitate the use of standards-based Web technologies to build applications that can be installed and used in the same way a “native” applications would be.

    There are many reasons that doing so might be desirable, not the least of which is the ability to build much or all of your application for use on many different devices and platforms using a single set of development technologies.

    Developers can already build HTML Applications (with help from the HTML5 Apps documentation ) and submit their applications to the Mozilla Marketplace.

    App versus Page ?

    When people start talking about building apps with HTML5, one of the early questions that comes to the conversation is “What’s the difference between an app and a page?”

    This is bit of a difficult question to answer because of the very wide range of answers which can all be true, but which may be completely different.

    While your HTML5 app should be more than a simple HTML5 page, technically speaking it doesn’t have to be. Using the steps outlined in the guide “Getting Started with making (HTML5) apps”, you could simply create an apps manifest file and submit your HTML page as an app.

    When an Open Web app runs, the Mozilla Web Runtime installs local copies of the HTML5 markup and all of the other web assets that are specified using an HTML5 Cache Manifest ( read here ).

    If a Web page is dynamically generated, as in an ASP.NET, PHP, etc., application, any cached version represents a snapshot of a single point in time. When submitted as an app, the page actually “becomes” an app, getting a launcher item similar to native apps on whatever the host operating system is. When the app is launched, the local assets are used if there is no Internet connection or if the caching mechanism determines that the assets have not changed since they were last downloaded.

    By doing the above we have not added any additional functionality to our application. All we have done by declaring our page to be an app is to get the run-time to copy the bits locally and to run those local bits if the device is off line or if the bits haven’t changed.

    Does this get us anything ?

    Is there value in just this simple step ?

    Yes, it gets us three valuable improvements:

    • Users can see our page even if they are not connected because the run-time renders the cached version if there is no Internet connection.
    • Processor cycles and bandwidth consumption from our infrastructure or hosting are greatly reduced because new bits are only fetched when they are needed.
    • Performance improves because resources are loaded locally by default.

    Many organizations are starting with this approach because very little technical effort is necessary and it can be done very quickly. In most cases all you need to do is to create an app manifest file ( more info here ) and to submit  the app to the marketplace. Developers can submit apps now at the Mozilla marketplace Developer Submission site so that they will be available to consumers when the “buy side” of the marketplace opens later this year.)

    But if that’s all you do with your app, you are missing the opportunity.

    Take a look at for a snapshot view of technologies that are available to developers using the modern web runtime.

    Whether we are building a real Open Web App from scratch or we are converting an HTML page to an app and then adding modern features, HTML5 era technologies let us really start to developer client / server applications that utilize the browser and its host resources, thereby reducing our server requirements while improving the end user’s experience.

    Developers can do things like :

    • Read and write data locally and sync with a server when appropriate.
    • Run multiple threads of execution at the same time.
    • Exchange content with other applications, or share logic with them.
    • Interact with the device on which their app is running.
      • Touch user interface
      • GPS
      • Camera
      • Richly integrate multimedia.
      • And much more…..

    Since apps’ source code is deployed to a single URL and is updated on the device on which the app runs only when updates are necessary, versioning is low cost and friction free. This makes it easy to start by making a page and then iteratively adding features one after another.

    Lets do it !

    Since this model makes it so easy to get started, why not give at a try?

    Follow the guidance here :

    And submit your app here :

  5. Weekly HTML5 Apps Developer Resources, October 24th 2012

    Weekly Resources for HTML5 Apps Developers



    Bonus Link

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

  6. Enhance your HTML5 app with audio.

    When we think of sound in an HTML application we might think of two things: We remember all those sites that started playing loud obnoxious background music when the page loads and then we think about music playing apps.

    Sound can however be much more: when building immersive app experiences it can be a crucial attribute. It can enhance tactile feedback or communicate activity or changes in state to the user. A ping sound when a new email arrives or a dismissive sound when there was an error can make things much more obvious for the end user.

    Prior to HTML5 most developers had to resort to plug-in technologies like Flash, Quicktime, Real player or Windows Media Player to play audio. These, of course, required that these technologies were installed on the users’ machines and the plugins being active.

    With HTML5, we have an audio element that natively supports sound playback. As with any HTML element, you can even play nice with older technologies by providing fallback content. For example by simply linking to the audio file:

    <audio controls src="intro.mp3">
      <a href="intro.mp3">Introduction to HTML5 (10:12) - MP3 - 3.2MB</a>

    As not all browsers support the same audio formats (MP3 not being a free format makes it impossible to decode it in an open source browser) you can provide the same audio in different formats:


    <audio controls>
      <source src="MySound.ogg" type="audio/ogg">
      <source src="MySound.mp3" type="audio/mp3">
      <a href="MySound.mp3">The recording - MP3 - 2.3MB</a>

    If you really need to provide a player for all browsers – including the ones that don’t understand HTML5 – I collected some information in this blog post.

    When your application checked that HTML5, Canvas and all the other things needed for your functionality is supported then backward compatibility is less of a concern, however you may still have cross-browser compatibility concerns since browser vendors are not fully converged on common feature implementation. That said, basic support for audio is available across all major browsers.

    You don’t need to have an audio element in your HTML, you can also create them on the fly in your JavaScript:

    var aSound = document.createElement('audio');
    aSound.setAttribute('src', 'PlayMe.ogg');

    However, there may be advantages to using the tag in your HTML.

    • Using the tag adds to the semantic integrity of your markup.
    • It makes your code easier to read and understand.
    • The tag can display controls so the user can play the audio and seek in it with native controls that are also keyboard accessible
    • The tag has an optional preload attribute that tells to the browser to load the audio before users start playing it.
    • Browsers have a distinct loading sequence of referenced assets. By leveraging that sequence, it iss possible for you to help improve the performance of your app.

    Here are some examples for using the tag in HTML5.

    <audio id="MySound" src="MySound.ogg" preload="auto"></audio>

    In this instance the audio element is not visible and MySound.ogg will only be played by calling the play method on the element instance.


    By adding a controls attribute you can display the player controls so that the user can play the audio file by interacting with them.

    <audio id="MySound" src="MySound.ogg" preload="auto" controls></audio>

    These controls differ from browser to browser and operating system to operating system, but all have the same features as shown in the following image:

    audio player with controls

    You can easily hide or display the audio element’s controls whenever appropriate (like when the UI state changes) with a simple bit of JavaScript:

    var myAudio = document.getElementById( "TimerBellSound" );
    if ( myAudio.hasAttribute("controls") ) {
      myAudio.removeAttribute("controls") ;
    else {
      myAudio.setAttribute("controls", "controls")

    As Terrill Thompson explains in his blog post HERE, we can easily create a custom player as well. Not only does this provide us with the flexibility of defining our own user interface but it lets us address accessibility concerns as well. His player looks like this and has a consistent look and feel across browsers and operating systems:

    So what could sound do in your app? As an example, consider the follow application prototype:

    This application will be a timer for athletes. When in use, the athletes won’t be sitting in front of the device that is running the app. It will be running on their computer, tablet or phone and, while they may glance at it to check the time, for the most part they will rely on audible feedback for when to start working out, when to rest, and when to increase or decrease the intensity of their workout.

    The audio element in HTML5 makes adding sound to your app both easy and straight forward.

  7. Weekly HTML5 Apps Developer Resources, October 17th 2012

    Weekly Resources for HTML5 Apps Developers



    Bonus Link

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

  8. Weekly HTML5 Apps Developer Resources, August 29th 2012

    Weekly Resources for HTML5 Apps Developers



    Bonus Link

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

  9. Weekly HTML5 Apps Developer Resources, May 30th 2012

    Weekly Resources for HTML5 Apps Developers



    Bonus Link

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

  10. Weekly HTML5 Apps Developer Resources, July 11th 2012

    Weekly Resources for HTML5 Apps Developers



    Bonus Link

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