Mozilla

Firefox Articles

Sort by:

View:

  1. Firefox Developer Tools work week wrap-up

    Last week in Sunnyvale we had the first Developer Tools work week to include the recently-integrated Jetpack team ( for a slightly different take on the week, see Paul’s post. ). And what a week! I was a bit shocked by how many things I thought were just interesting ideas suddenly became real things that actually worked. By Friday morning we had some amazing demos from the team, which I will try to group together according to theme:

    Remote everything, everywhere.

    Within the next 3 months we will land remote protocol support for all of the development tools we ship. The remote protocol is a network client/server protocol that exposes the developer tools to each other external tools like editors as well as Firefox on Android and Firefox OS. We had some awesome demos that leverage or extend these capabilities:

    • Based on Heather Arthur’s work on implementing remote style editing, Paul Rouget amazed us and soon many others with remote CSS editing from popular editor Sublime Text 2: (Tweet, Youtube, Github).
    • Joe Walker showed off how to run gcli commands remotely between different instances of Firefox Desktop.
    • Jim Blandy walked us through some important platform fixes that will enable content process debugging on Firefox OS. This will allow us to support remote on-device debugging of B2G apps.

    Revolutionary Dev Tools hacks

    Many team members got a ton of work done on their existing projects and showed us some great enhancements by the end of the week:

    • Mihai Sucan showed off progress on the Global Console, which now understands all network requests and also supports stdin/stdout and some handy timing utilities.
    • Anton Kovalyov showed off an initial integration of Codemirror as the source editor for the devtools, replacing the current Orion editor.
    • Nick Fitzgerald got sourcemaps working with the debugger and gave us a demo of Coffeescript debugging.
    • Joe Walker re-factored gcli commands to de-couple processing from presentation, making it much easier to implement multiple commands that use a common data formatter.
    • Last but not least, Victor Porov walked us through a fully-operational Network Panel that is nearly ready to land!
    • Stephen Shorlander showed off some great first steps on defining what in-browser web app development might look like.

    Developer tools + Jetpack == Super Powers!

    On Tuesday Paul Rouget walked us through the fledgling developer tools API and challenged the Jetpack team to see how working with the developers could be made simpler. By Friday Irakli answered the challenge by showing us a Jetpack add-on called ‘Add-on Pad’ for live-coding SDK-based add-ons.

    Dave Camp had a slightly different take on Jetpack’s possibilities and by the end of the week was able to show off a version of the Developer Tools code-base that could be dynamically re-loaded from disk using Jetpack’s CommonJS loader, without the need to re-build or even restart Firefox.

    Not to be outdone, Dave Townsend made some tweaks to tilt mode to expose it to add-ons and even scratchpad hacks to change how tilt visualizes a page based on arbitrary code that could be injected either via an add-on or from scratchpad.

    Paul also released a new version of his excellent Firefox Terminal add-on recently which you should go install it immediately! Right now! I’ll still be here when you get back.

    Add-on developer love

    The developer tools team has been focused like a laser on improving life for web developers, but Firefox itself is created and extended with web technologies like JS and CSS. At this first Devtools work week that included the Jetpack team we saw some really promising work:

    • Eddy Bruel tackled several bugs I don’t completely understand and by the end of the week showed us debugging for almost all browser chrome and add-on Javascript code. There are still some known limitations to work through ( not all add-ons or content scripts can be debugged currently ) but the Browser is already very useful to developers as of today’s Nightly build.
    • Mihai Sucan and Alexandre Poirot made changes to both the SDK and the Global Console that will pipe any calls to console.log in Jetpack code to the Global Console, greatly improving ‘printf’-style debugging for add-on developers.

    Some of these hacks landed last week during the work week, many will be landing over the next couple weeks. If you’d like to get involved in driving these features home, find us in #devtools and #jetpack on irc.mozilla.org or the Developer Tools project mailing list at mozilla.dev.developer-tools.

  2. Font Inspector and <time> and <data> elements – Firefox Development Highlights

    Time for another look at the latest developments with Firefox. This is part of our Bleeding Edge and Firefox Development Highlights series, and most examples only work in Firefox Nightly (and could be subject to change).

    Font Inspector

    A Font Inspector is now available in the Firefox DevTools.

    image

    In the Firefox Inspector, a “Fonts” panel is now available. It exposes different information about the @font-faces used in the page:

    • Font name and font family
    • Its location (system vs. remote, and URL)
    • A preview (you can change it)
    • @font-face code

    HTML5 and

    We have implemented support for two new elements:

    <time> element

    The HTML time element (

    Example:

    <p>The concert took place on <time datetime="2001-05-15 19:00">May 15</time>.</p>

    More information can be found in the MDN documentation for the <time> element, and in the W3C specification.

    <data> element

    The data element represents its contents, along with a machine-readable form of those contents in the value attribute. The value attribute must be present and its value must be a representation of the element’s contents in a machine-readable format.

    The <data> element adds a new attribute, value, which contains a string representation of the data. In script we can use the .value property to get the reflected value:

    Example:

    <data id="user" value="humphd">David Humphrey</data>
    document.getElementById("user").value; // "humphd"

    It’s available in the WHATWG specification, and David Humphrey’s wrote more about it in HTML5 time and data elements in Firefox.

  3. WebRTC enabled, H.264/MP3 support in Win 7 on by default, Metro UI for Windows 8 + more – Firefox Development Highlights

    Time again for looking at the latest progress with Firefox. These posts are part of our Bleeding Edge and Firefox Development Highlights series – take note that most examples only work in Firefox Nightly (and could be subject to change).

    WebRTC enabled by default

    Previously, you needed to go to about:config in Firefox and set the media.peerconnection.enabled option to true, but now it’s enabled by default. This is a huge step forward, to be able to run WebRTC directly in a web browser without it needing any special settings or configuration.

    For more details behind this decision, please read Pref on WebRTC by default.

    Want to get started with WebRTC? Then we recommend our article Cross-browser camera capture with getUserMedia/WebRTC.

    Metro UI

    The new Firefox User Interface for Windows 8 has landed (if you had Firefox Nightly as your default browser, reset that permission to see the new UI).

    There are more screenshots available too.

    H.264 & MP3 support enabled by default in Windows 7

    We talked about H.264 & MP3 support before, and now that support is activated by default.

    We are still working on supporting Mac OS X and Linux.

    WebAudio API progress

    We are working on implementing the WebAudio API, and the first parts of support has just started appearing.

    It’s available in about:config in the media.webaudio.enabled preference – set it to true to enable it and be able to access things such as AudioContext.decodeAudioData.

    Crypto API: window.crypto.getRandomValues

    If you provide an integer-based TypedArray (i.e. Int8Array, Uint8Array, Int16Array, Uint16Array, Int32Array, or Uint32Array), window.crypto.getRandomValues is going fill the array with cryptographically random numbers:

    /* assuming that window.crypto.getRandomValues is available */
     
    var array = new Uint32Array(10);
    window.crypto.getRandomValues(array);
     
    console.log("Your lucky numbers:");
    for (var i = 0; i < array.length; i++) {
        console.log(array[i]);
    }

    canvas: ctx.isPointInStroke

    This has been uplifted to Firefox 19 Beta.

    From the WHATWG mailing list:

    “We have recently implemented isPointInStroke(x,y) in Firefox (https://bugzilla.mozilla.org/show_bug.cgi?id=803124). This is a parallel to isPointInPath(x,y) and returns true if the point is inside the area contained by the stroking of a path.”

    JavaScript: Math.imul

    Math.imul allows for fast 32-bit integer multiplication with C-like semantics. This feature is useful for projects like Emscripten.

    Polyfill:

    function imul(a, b) {
        var ah  = (a >>> 16) & 0xffff;
        var al = a & 0xffff;
        var bh  = (b >>> 16) & 0xffff;
        var bl = b & 0xffff;
        // the shift by 0 fixes the sign on the high part
        return (al * bl) + (((ah * bl + al * bh) << 16) >>> 0);
    }
  4. Firefox Development Highlights – H.264 & MP3 support on Windows, scoped stylesheets + more

    Time for the first look this year into the latest developments with Firefox. This is part of our Bleeding Edge and Firefox Development Highlights series, and most examples only work in Firefox Nightly (and could be subject to change).

    H.264 & MP3 support on Windows

    Firefox for Android and Firefox OS already support H.264 and MP3. We are also working on bringing these formats to Firefox Desktop. On Windows 7 and above, you can already test it by turning on the preference media.windows-media-foundation.enabled in about:config. Decoding is done on the OS side (no decoder included in Firefox source code, not like WebM or Ogg Theora). For Linux and Mac, work is in progress.

    The new Downloads panel has been enabled

    We have now enabled the new Downloads panel:

    Scoped style attribute

    It’s now possible to define scoped style elements. Usually, when we write a stylesheet, we use <style>...</style>, and CSS code is applied to the whole document. If the <style> tag is nested inside a node (let’s say a <div>), and the <style> tag includes the scoped attribute (<style scoped>), then the CSS code will apply only to a subtree of the document, starting with the parent node of the <style> element. The root of the subtree can also be referred via the :scope pseudo-class.

    Demo

    Scoped style demo support on JS Bin.

    Our friends over at HTML5Rocks have also written about it in A New Experimental Feature: scoped stylesheets.

    @supports and CSS.supports

    In Firefox 17, we shipped the @supports CSS at-rule. This lets you define specific CSS code only if some features are supported. For example:

    @supports not (display: flex) {
      /* If flex box model is not supported, we use a different layout */
      #main {
          width: 90%;
      }
    }

    In Firefox 20, it’s now possible to do the same thing, but within JavaScript:

    if (CSS.supports("display", "flex")) {
      // do something relying on flexbox
    }
  5. Firefox Development Highlights – Per Window Private Browsing & Canvas’ globalCompositeOperation new values

    On a regular basis, we like to highlight the latest features in Firefox for developers, as part of our Bleeding Edge series, and most examples only work in Firefox Nightly (and could be subject to change).

    Per Window Private Browsing

    Private browsing is very useful for web developers. A new private session doesn’t include existing persistent data (cookies and HTML5 storage). It’s convenient if we want to test a website that stores data (login and persistent informations) without cleaning every time these cached data, or if we want to login to a service with 2 different users.

    Until now, when entering Private Browsing in Firefox, it was closing the existing session to start a new one. Now, Firefox will keep the current session and open a new private window. You can test it in Firefox Nightly (to be Firefox 20). There’s still some frontend work to do, but the feature works.

    Canvas’ globalCompositeOperation new values

    The ‘globalCompositeOperation’ canvas property lets you define how you want canvas to draw images over an existing image. By default, when canvas draws an image over existing pixels, the new image is just replacing the pixels. But there are other ways to mix pixels. For example, if you set ctx.globalCompositeOperation = "lighter", pixel color values are added, and it creates a different visual effect.

    There are several effects available, and more on them can be found in globalCompositeOperation on MDN.

    Rik Cabanier from Adobe has extended the Canvas specification to include more effects. He has also implemented these new effects in Firefox Nightly. These new effects are called “blend modes”. These are more advanced ways of mixing colors.

    Please take a look at the list of these new blending modes.

    And here’s an example of how to use them:

    JS Bin demo.

    If you don’t use Firefox Nightly, here is a (long) screenshot:

    image

  6. Firefox Development Highlights: video.playbackRate and download attribute

    Here are the latest features in Firefox for developers, as part of our Bleeding Edge series, and most examples only work in Firefox Nightly (and could be subject to change).

    <video>: support for custom playbackRate

    Setting video.playbackRate changes the “video speed”. 1.0 is regular speed, 2.0 is 2 times faster. From the MDN documentation on HTMLMediaElement:

    The default playback rate for the media. 1.0 is “normal speed,” values lower than 1.0 make the media play slower than normal, higher values make it play faster.

    Example:

    <video src="v.webm" id="v" controls autoplay></video>
    <button onclick="fastForward()">fast foward</button>
    <script>
      fastFoward() {
        v.playbackRate = 2;
      }
    </script>

    Interactive demo:

    video playbackRate demo

    <a> “download” attribute

    From Downloading resources in the Living standard at Whatwg.org:

    In some cases, resources are intended for later use rather than immediate viewing. To indicate that a resource is intended to be downloaded for use later, rather than immediately used, the download attribute can be specified on the a or area element that creates the hyperlink to that resource.

    This attribute is particularly useful with blobs. With Blobs, You can create files in JavaScript. A binary blob can be an image built in a canvas element for example. Linking binary blobs to a <a> element (with a URL constructor) and marking this <a> element as downloadable with this new attribute, the user will be able to save the blob as a file on his hard-drive.

    Example from Tom Schuster’s blog post about his work on the HTML5 download attribute: ]

    var blob = new Blob(["Hello World"]);
    var a = document.createElement("a");
    a.href = window.URL.createObjectURL(blob);
    a.download = "hello-world.txt";
    a.textContent = "Download Hello World!";

    It has also been covered on HTML5Rocks in Downloading resources in HTML5.

  7. H.264 video in Firefox for Android


    Firefox for Android
    has expanded its HTML5 video capabilities to include H.264 video playback. Web developers have been using Adobe Flash to play H.264 video on Firefox for Android, but Adobe no longer supports Flash for Android. Mozilla needed a new solution, so Firefox now uses Android’s “Stagefright” library to access hardware video decoders. The challenges posed by H.264 patents and royalties have been documented elsewhere.

    Supported devices

    Firefox currently supports H.264 playback on any device running Android 4.1 (Jelly Bean) and any Samsung device running Android 4.0 (Ice Cream Sandwich). We have temporarily blocked non-Samsung devices running Ice Cream Sandwich until we can fix or workaround some bugs. Support for Gingerbread and Honeycomb devices is planned for a later release (Bug 787228).

    To test whether Firefox supports H.264 on your device, try playing this “Big Buck Bunny” video.

    Testing H.264

    If your device is not supported yet, you can manually enable H.264 for testing. Enter about:config in Firefox for Android’s address bar, then search for “stagefright”. Toggle the “stagefright.force-enabled” preference to true. H.264 should work on most Ice Cream Sandwich devices, but Gingerbread and Honeycomb devices will probably crash.

    If Firefox does not recognize your hardware decoder, it will use a safer (but slower) software decoder. Daring users can manually enable hardware decoding. Enter about:config as described above and search for “stagefright”. To force hardware video decoding, change the “media.stagefright.omxcodec.flags” preference to 16. The default value is 0, which will try the hardware decoder and fall back to the software decoder if there are problems (Bug 797225). The most likely problems you will encounter are videos with green lines or crashes.

    Giving feedback/reporting bugs

    If you find any video bugs, please file a bug report here so we can fix it! Please include your device model, Android OS version, the URL of the video, and any about:config preferences you have changed. Log files collected from aLogcat or adb logcat are also very helpful.

  8. Progress on OMTC, unprefixed Visibility API and CSS improvements – Firefox Development Highlights

    To keep all you web developers in the loop about new features and improvements in Firefox, and to be able to test and experiment in an early stage, here’s the latest Firefox Development Highlights. This is part of our Bleeding Edge series, and most examples only work in Firefox Nightly (and could be subject to change).

    Good progress on OMTC (“Off Main Thread Compositing”)

    A direct advantage of OMTC is a more responsive user interface. Rendering a web page is a complex process that involves different operations, like computing the layout of the page, downloading the different resources, decoding images, or executing JavaScript code.
    Some of these operations are executed in a same thread. Some of them are executed in the main thread, where most of the User Interface interactions are handled. If an operation takes times in this main thread, it would then block the UI and makes the UI feel sluggish.

    So, we want to move as many operations as possible into another thread. One of these operations we want to move is called “Compositing”. It’s responsible for “flattening” the page. A page is made of layers. For example, a layer for the fixed-background, a layer for a piece of test, and a layer for a video element. Flattening the page, compositing it, will merge these layers into one texture.

    In Firefox OS and Firefox for Android, the Compositing operations are made in a different thread. And we are making some good progress to get OMTC working for Firefox Desktop.

    To delve more into this, we recommend reading Off Main Thread Compositing (OMTC) and why it matters.

    The visibility API has been unprefixed

    The Page Visibility API lets you know when a webpage is visible or in focus. With tabbed browsing, there is a reasonable chance that any given webpage is in the background and thus not visible to the user.

    When the user minimizes the webpage or moves to another tab, the API sends a visibilitychange event regarding the visibility of the page. You can detect the event and perform some actions or behave differently. For example, if your web app is playing a video, it would pause the moment the user looks at another browser, and plays again when the user returns to the tab. The user does not lose her place in the video and can continue watching.

    To that end, for mozHidden and mozvisibilitychange, the moz prefix is not required anymore.

    CSS improvements

    We always need more CSS support, right? Here are the latest changes:

    @page CSS at-rule

    The @page CSS at-rule is used to modify some CSS properties when printing a document. You can’t change all CSS properties with @page. You can only change the margins, orphans, widows, and page breaks of the document. Attempts to change any other CSS properties will be ignored.

    For example, you can write a specific style for left pages, and one for right pages (think “book”) with the :left and :right pseudo classes, or for the very first page with :first.

    page-break-inside CSS property

    The page-break-inside CSS property adjusts page breaks inside the current element:

    page-break-inside:auto;
    

    Automatic page breaks (default behavior):

    page-break-inside:avoid;
    

    Avid page breaks before the element:

    /* avoid page break inside the paragraph */
    p { page-break-inside: avoid; } 
    

    text-transform:full-width

    For CSS text-transform, full-width forces the writing of a character, mainly ideograms and latin scripts inside a square, allowing them to be aligned in the usual East Asian scripts (like Chinese or Japanese).

  9. Hacking Firefox OS

    This blog post is written by Luca Greco, a Mozilla community member who loves to hack, especially on JavaScript and other web-related technologies.

    A lot of developers are already creating mobile applications using Web technologies (powered by containers like Phonegap/Cordova as an example),
    usually to develop cross platform applications or leverage their current code and/or expertise.

    As a consequence Firefox OS is a very intriguing project for quite a few reasons:

    • Web apps have first class access to the platform
    • Web apps are native (less abstraction levels and better performance)
    • Platform itself is web-based (and customizable using web technologies)

    Mobile platforms based on web technologies can be the future, and we can now touch it, and even more important, we can help to define it and push it further thanks to a platform (Firefox OS) developed completely in the open. I could not resist the temptation, so I started to dive into Firefox OS code, scrape it using MXR and study documentation on the wiki.

    Hack On Firefox OS

    In a couple of weeks I was ready to put together an example app and an unofficial presentation on the topic (presented at the local LinuxDay 2012):



    Slides: “Hack On Firefox OS”

    Example App: Chrono for Gaia (user interface of Firefox OS):

    During this presentation I tried to highlight an important strength I believe Firefox OS and Firefox have in common:

    “It’s not a static build, it’s alive! a truly interactive environment. Like the Web”

    I can telnet inside a B2G instance and look around for interesting stuff or run JavaScript snippets to interactively experiment the new WebAPIs. There’s more than one option to get a remote JavaScript shell inside B2G:

    • Marionette, mainly used for automated tests
    • B2G Remote JS Shell, a minimal JavaScript shell optionally exposed on a tcp port (which I think will be deprecated in future releases)

    Unfortunately these tools currently lack integrated inspection utils (e.g. console.log/console.dir or MozRepl repl.inspect and repl.search), so during the presentation I opted to install MozRepl as extension on the B2G simulator, but in the last weeks Remote WebConsole landed into Firefox Nightly.

    Obviously RemoteWebConsole isn’t mature yet, so we need to be prepared for bugs and silent errors (e.g. we need to be sure B2G has “remote debugger” enabled or it will fail without errors), but it features objects inspection, network progress logging, JavaScript and CSS errors (like our local Firefox WebConsole).

    Developing for Firefox OS

    In my experience, developing an OpenWebApps for Firefox OS isn’t really different from hybrid applications based on Phonegap-like technologies:

    We’ll try to code and test major parts of our application on desktop browsers and their development tools, using mockups/shims in place of native functionalities. But during my 2 weeks of studying, I’ve collected an interesting amount of working notes that can be useful to share, so in next sections I’m going to:

    • Review development workflow and tools
    • Put together a couple of useful tips and tricks
    • Release to the public (independently and in the Mozilla Marketplace)

    As an example app, I’ve chosen to create a simple chronometer:

    Workflow and Tools

    During this experience my toolset was composed by:

    • VoloJS – development server and automated production build (minify js/css, generate manifest.appcache)
    • Firefox Nightly Web Developer Tools – Markup View, Tilt, Responsive Design View and Web Console
    • R2D2B2G – integrate/interoperate with B2G from a Firefox Addon

    Using Volo, I can test my app from volo integrated http server, split JavaScript code into modules using Require.js, and finally generate a production version, minified and optionally equipped of an auto-generated manifest.appcache.

    During my development cycle I iteratively:

    • Make a change
    • Reload and inspect changes on desktop browser
    • Try changes on b2g-simulator using R2D2B2G
    • Debug on desktop browser or remotely on b2g-simulator
    • Restart the loop :-)

    Using my favorite desktop browser (Firefox, obviously :-P), I have the chance to use very powerful inspection/debugging tools, not usually available on mobile web-runtimes:

    • Markup Viewer to inspect and change DOM tree state
    • Styles Editor to inspect and change CSS properties
    • Tilt to check where offscreen dom elements are located
    • Web Console to inspect and change the JavaScript environment

    Thanks to new Mozilla projects like “Firefox OS” and “Firefox for Android”, more and more of these tools are now available as “Remote Web Tools” and can be connected to a remote instance.

    Tips and Tricks

    Gaia UI Building Blocks

    Gaia isn’t only a B2G UI implementation, it’s a design style guide and a collection of pre-built CSS styles which implements these guidelines:

    We can import components’ styles from the repo above and apply them to our app to achieve a really nice native Look & Feel on Firefox OS. Some components are not stable, which means they can interact badly with other components’ styles or doesn’t work perfectly on all platforms (e.g. Firefox Desktop or Firefox for Android), but usually it’s nothing we can’t fix by using some custom and more specific CSS rules.

    It doesn’t feel like a mature and complete CSS framework (e.g. Bootstrap) but it’s promising and I’m sure it will get better.

    Using Responsive Design View we can test different resolutions (and orientations), which helps to reach a good and consistent result even without test our app on Firefox OS or Firefox for Android devices, but we should keep an eye on dpi related tweaks, because we currently can’t fully recognize how it will looks using our Desktop browser.

    App Panels

    A lot of apps needs more than one panel, so first I looked inside official Gaia applications to understand how native apps implements this almost mandatory feature. This is how Gaia Clock application appear from a “Tilt” eye:

    Panels are simple DOM elements (e.g. a section or a div tag) initially positioned offscreen and moved on screen using a CSS transition:

    In the “Chrono” app, you will find this strategy in the Drawer (an unstable Gaia UI Building Block):

    and in the Laps and About panels (combinated with :target pseudo class):

    The Fascinating -moz-element trick

    This is a very fascinating trick, used in the time selector component on Firefox OS:

    and in the Markup View on Firefox Nightly Desktop (currently disabled):

    Thanks to this non-standard CSS feature we can use a DOM Element as background image on another one, e.g. integrating a complex offscreen visual component into the visible space as a single DOM element.

    Fragments from index.html

    Fragments from chrono.css

    Fragments from chrono.js

    Using -moz-element and -moz-calc (compute components size into CSS rules and already included into CSS3 as calc) is really simple, but you can learn more on the subject on MDN:

    Release to the public

    WebApp Manifest

    During our development cycle we install our application into B2G simulator using an R2D2B2G menu option, so we don’t need a real manifest.webapp, but we have to create a real one when ready for a public release or to release it to test users.

    Creating a manifest.webapp is not difficult, it’s only a simple and well documented json file format: App/Manifest on MDN.

    Debugging problems related to this manifest file is still an unknown territory, and some tips can be useful:

    • If the manifest file contains a syntax error or cannot be downloaded and error will be silently reported into the old Error Console (no, they will not be reported inside the new Web Console)
    • If your application is accessible as a subdirectory in its domain, you have to include this path in resources path specified inside the manifest (e.g. launch_path, appcache_path, icons), more on this later
    • You can add an uninstall button in your app to help you as a developer (and test users) to uninstall your app in a platform independent way (because “how to uninstall” an installed webapp will be different if you are on Desktop, Android or Firefox OS)

    Using OpenWebApps APIs, I added to “Chrono” some code to give users the ability to install itself:

    Install an app from your browser to your desktop system

    Check if it’s already installed (as a webapp runtime app or a self-service installer in a browser tab):

    On a Linux Desktop, when you install an OpenWebApp from Firefox, it will create a new launcher (an “.desktop” file) in your “.local/share/applications” hidden directory:

    $ cat ~/.local/share/applications/owa-http\;alcacoop.github.com.desktop 
    [Desktop Entry]
    Name=Chrono
    Comment=Gaia Chronometer Example App
    Exec="/home/rpl/.http;alcacoop.github.com/webapprt-stub"
    Icon=/home/rpl/.http;alcacoop.github.com/icon.png
    Type=Application
    Terminal=false
    Actions=Uninstall;
    [Desktop Action Uninstall]
    Name=Uninstall App
    Exec=/home/rpl/.http;alcacoop.github.com/webapprt-stub -remove

    As you will notice, current conventions (and implementation) supports only one application per domain, if you give a look inside the hidden directory of our installed webapp you will find a single webapp.json config file:

    $ ls /home/rpl/.http\;alcacoop.github.com/
    Crash Reports  icon.png  profiles.ini  webapp.ini  webapp.json  webapprt-stub  
    z8dvpe0j.default
    

    Reasons for this limitations are documented on MDN: FAQs about app manifests

    To help yourself debugging problems when you app is running inside the webapp runtime you can run it from command line and enable the old (but still useful) Error Console:

    $ ~/.http\;alcacoop.github.com/webapprt-srt -jsconsole

    Uninstalling an OpenWebApp is really simple, you can manually removing it using the “wbapprt-stub” executable in the “OpenWebApp hidden directory” (platform dependent method):

    $ ~/.http\;alcacoop.github.com/webapprt-stub -remove

    Or from JavaScript code, as I’ve done in “Chrono” to give users the ability to uninstall the app from a Firefox Browser tab:

    AppCache Manifest

    This is a feature integrated a lot of time ago into major browsers, but now, thanks to OpenWebApps, it’s becoming really mandatory: without a manifest.appcache, and proper JavaScript code to handle upgrades, our WebApp will not works offline correctly, and will not feel like a real installed application.

    Currently Appcache it’s a kind of black magic and it deserves a “Facts Page” like Chuck Norris: AppCacheFacts.

    Thanks to volo-appcache command, generate a manifest.appcache it’s simple as a single line command:

      $ volo appache
      ...
      $ ls -l www-build/manifest.appcache
      ...
      $ tar cjvf release.tar.bz2 www-build
      ...

    Unfortunately when you need to debug/test your manifest.appcache, you’re on your own, because currently there isn’t any friendly debugging tool integrated into Firefox:

    • appcache downloading progress (and errors) are not currently reported into the WebConsole
    • appcache errors doesn’t contains an error message/description
    • Firefox for Android and Firefox OS doesn’t have an UI to clean your applicationCache

    Debug appcache problems can be very tricky, so here a couple of tricks I learned during this experiment:

    • Subscribe every window.applicationCache events (‘error’, ‘checking’, ‘noupdate’, ‘progress’, ‘downloading’, ‘cached’, ‘updateready’ etc) and log all received events / error messages during development and debugging
    • Add upgrade handling code in your first public release (or prepare yourself to go house by house to help your users to upgrade :-D)
    • On Firefox for Desktop you can remove applicationCache from the Preferences dialog
    • Analyze server side logs to understand where the “appcache updating” is stuck
    • Activate logging on applicationCache internals when you run Firefox or B2G to understand why it’s stuck
      (from https://mxr.mozilla.org/mozilla-central/source/uriloader/prefetch/nsOfflineCacheUpdate.cpp#62):

      export NSPR_LOG_MODULES=nsOfflineCacheUpdate:5
      export NSPR_LOG_FILE=offlineupdate.log
      firefox -no-remote -ProfileManager &
       
      tail -f offlineupdate.log
      -1614710976[7fc59e91f590]: nsOfflineCacheUpdate::Init [7fc55959ce50]
      -1614710976[7fc59e91f590]: nsOfflineCacheUpdate::AddObserver [7fc56a9fcc08] to update [7fc55959ce50]
      -1614710976[7fc59e91f590]: nsOfflineCacheUpdate::AddObserver [7fc55c3264d8] to update [7fc55959ce50]
      -1614710976[7fc59e91f590]: nsOfflineCacheUpdate::Schedule [7fc55959ce50]
      -1614710976[7fc59e91f590]: nsOfflineCacheUpdateService::Schedule [7fc57428dac0, update=7fc55959ce50]
      -1614710976[7fc59e91f590]: nsOfflineCacheUpdateService::ProcessNextUpdate [7fc57428dac0, num=1]
      -1614710976[7fc59e91f590]: nsOfflineCacheUpdate::Begin [7fc55959ce50]
      -1614710976[7fc59e91f590]: nsOfflineCacheUpdate::NotifyState [7fc55959ce50, 2]
      -1614710976[7fc59e91f590]: 7fc559d0df00: Opening channel for http://html5dev:8888/gaia-chrono-app/manifest.appcache
      -1614710976[7fc59e91f590]: loaded 3981 bytes into offline cache [offset=0]
      -1614710976[7fc59e91f590]: Update not needed, downloaded manifest content is byte-for-byte identical
      -1614710976[7fc59e91f590]: done fetching offline item [status=0]
      -1614710976[7fc59e91f590]: nsOfflineCacheUpdate::LoadCompleted [7fc55959ce50]
      -1614710976[7fc59e91f590]: nsOfflineCacheUpdate::NotifyState [7fc55959ce50, 3]
      -1614710976[7fc59e91f590]: nsOfflineCacheUpdate::Finish [7fc55959ce50]
      -1614710976[7fc59e91f590]: nsOfflineCacheUpdateService::UpdateFinished [7fc57428dac0, update=7fc55959ce50]
      -1614710976[7fc59e91f590]: nsOfflineCacheUpdateService::ProcessNextUpdate [7fc57428dac0, num=0]
      -1614710976[7fc59e91f590]: nsOfflineCacheUpdate::NotifyState [7fc55959ce50, 10]
      -1614710976[7fc59e91f590]: nsOfflineCacheUpdate::RemoveObserver [7fc56a9fcc08] from update [7fc55959ce50]
      -1614710976[7fc59e91f590]: nsOfflineCacheUpdate::RemoveObserver [7fc55c3264d8] from update [7fc55959ce50]

    Adding applicationCache support to “Gaia Chrono App”, I used all this tricks to finally discover Firefox didn’t send me an “updateready” event, so I was not able to tell the user to reload the page to start using the new (and already cached) version. With a better understanding of the problem, and searching in the code on MXR and in tickets on Bugzilla, I finally found an existing ticket in the bugtracker: Bug 683794: onupdateready event not fired when an html5 app cache app is updated.

    Workaround this bug its really simple (simpler than tracking it down): add a dummy “updateready” listener on applicationCache object in a script tag to be sure it will be fired:

    If you are going to start to use this feature (and soon or later you will), be prepared to:

    • Implement as suggested from the standard
    • Debug reason why it’s not behave as it should
    • Search an existent bug or file a bug if it’s not reported (NOTE: this is really important!!! :-D)
    • Find a workaround

    This is definitely a features that needs more supports into web developer tools, because a regular web developer doesn’t want to debug his webapp from “browser internals” point of view.

    Port to Firefox for Android

    An interesting feature of OpenWebApps is “they can be installed on any supported platform without (almost) any changes”. As an example we can install our “Chrono” App on our Desktop using Firefox Nightly and on Android using Firefox for Android Nightly.

    In my own opinion, Firefox for Android can be a strategic platform for the future of OpenWebApps and even Firefox OS: Android is an already popular mobile platform and give developers the option to release their application on Firefox OS and Android from a single codebase is a big plus.

    The only problem I faced porting “Chrono” App on Android was related to the different rendering behaviour of Firefox for Android (and as a consequence in the WebAppRT, which contains our application):

    A GeckoScreenshot service will force a repaint only when and where it detects changes. This feature interacts badly with the -moz-element trick and it needs some help to understand what really needs to be repainted:

    Release to the public

    GitHub pages are a rapid and simple option to release our app to the public, even simpler thanks to the volo-ghdeploy command:

      $ volo appcache && volo ghdeploy
      ...

    When you deploy your OpenWebApp in a subdirectory of a given domain (e.g. using Github Pages) you should take into account that paths from manifest.webapp needs to be relative to your origin (protocol+host+port) and not your current url:

    We can install only a single OpenWebApp from every origin, so if you wants to deploy more than one app from your Github pages you need to configure Github pages to be exposed on a custom domain: Github Help – Setting up a custom domain with pages.

    When our app is finally online and public accessible we can submit it to the Mozilla Marketplace and gain more visibility.

    During the app submission procedure, your manifest.webapp will be validated and you will be warned if and how you need to tweak it to be able complete your submission:

    • Errors related to missing info (e.g. name or icons)
    • Errors related to invalid values (e.g. orientation)

    As in other mobile marketplaces you should collect and fill into your submission:

    • manifest.webapp url (NOTE: it will be read-only in the developer panel and you can’t change it)
    • A longer description and feature list
    • Short release description
    • One or more screenshots

    Mini Market

    Mozilla Marketplace goal is to help OpenWebApps to gain more visibility, as other mobile store currently do for their ecosystem, but Mozilla named this project OpenWebApps for a reason:

    Mozilla isn’t the only one that could create a Marketplace for OpenWebApps! Mozilla designed it to give us the same freedom we have on the Web, no more no less.

    This is a very powerful feature because it open to developers a lot of interesting use cases:

    • Carrier Apps Market on Firefox OS devices
    • Non-Public Apps Installer/Manager
    • Intranet Apps Installer/Manager

    Conclusion

    Obviously Firefox OS and OpenWebApps aren’t fully completed right now (but improves at an impressive speed), Firefox OS doesn’t have an official released SDK, but the web doesn’t have an official SDK and we already use it everyday to do awesome stuff.

    So if you are interested in mobile platforms and you wants to learn how a mobile platform born and grow, or you are a web developer and you wants more and more web technologies into mobile ecosystems…

    You should seriously take a look at Firefox OS:

    We deserve a more open mobile ecosystem, let’s start to push it now, let’s help OpenWebApps and Firefox OS to became our new powerful tools!

    Happy Hacking!

  10. Progress update on WebRTC for Firefox on desktop

    WebRTC for desktop is now in Firefox Nightly and is also in Firefox Aurora, though Nightly has the hottest up-to-date fixes.

    We support mozGetUserMedia, mozRTCPeerConnection and DataChannels. We have a basic UI for mozGetUserMedia which we expect to be updating in the
    coming weeks.

    Enabling WebRTC in Firefox

    The code is behind a pref for now, pending more testing. To enable our WebRTC code in Firefox’s Nightly desktop build, browse to about:config
    and change the media.peerconnection.enabled preference to true.

    Here are the 3 relevant prefs to getUserMedia() and mozRTCPeerConnection():

    • media.navigator.enabled enables calls to mozGetUserMedia() only
    • media.navigator.permission.disabled automatically gives permission to access the camera/microphone and bypasses the permission/selection dialog
    • media.peerconnection.enabled enables use of mozRTCPeerConnection()

    Note: media.peerconnection.enabled implies media.navigator.enabled has been set to true.

    Demos & upcoming changes

    There’s a lot you can do with these APIs, even today. For examples, check out our test landing page on GitHub. We’ll try and put up notices if you’re running an out-of-date browser — as well as news updates about important bug fixes and API changes there!

    Upcoming changes include:

    • Support for constraints (to getUserMedia and createOffer/Answer)
    • Control of bandwidth, resolution, echo cancellation, etc.
    • Statistics
    • TURN support (to allow connections between devices behind symmetric NATs)
    • Fixes for audio drift (progressive loss of A/V sync)
    • Trickle ICE, rtcp-mux and BUNDLE support
    • getUserMedia() UI updates
    • And many bugfixes

    To give you an idea of the power of these APIs, in a couple of days our team whipped up a Social API integration demo that allows you to video +
    text chat with your friends, drag-and-drop files to each other, drop links, tabs, etc, all making simple use of the DataChannel API.

    The DataChannel API is quite simple on the surface, and has an API very similar to WebSockets. A quick example:

    Filing bugs & moving forward

    Progress on WebRTC (and bug-fixing) is rapid, and we encourage you to try it out and submit bugs. (We have plenty! But we’re nailing them as fast as we can, so make sure you’re on nightly and update regularly.)

    Bug reports are highly appreciated. Please file them on
    Bugzilla under “Product:Core”, “Component:WebRTC”.

    The team is both excited by all the progress, and exhausted. The work so far represents tons of hours of work from so many people on the Firefox team (too many people to name — especially because we don’t want to forget
    someone — but you know who you are!). Thank you to everyone who helped us land this “747″ on the flight deck.

    We’ll continue to blog regularly on our progress as we work to make this a great product feature for Firefox and the web.