Mozilla

Featured Articles

Sort by:

View:

  1. 350 posts on Hacks in 2 years!

    Two years ago, we made a number of changes to the Mozilla Hacks blog. Since then we’ve had over three million unique visitors and 350 quality posts in just less than two years – almost one every second day!

    Part of these changes included:

    • A clear focus on learning about the Open Web & open source – more detail in What Mozilla Hacks is
    • A dedicated Editor, me, working with ensuring consistency, quality & versatility of the articles
    • Articles covering both interesting technologies and possibilities but also learning lessons of how to build exciting solutions and work with a number of different technical opportunities
    • To be a credible and independent go-to resource for developers

    Testimonials

    I’ve gathered a few testimonials from authors behind the most popular articles during this time, with their experiences writing for Mozilla Hacks.

    And you know what? You could write for Hacks too!

    If you have experience with a great solution or idea for the Open Web/open source, just let me know and Mozilla can help you share it with a lot of developers out there! Send an e-mail to robert [at] mozilla [dot] com or talk to me via @robertnyman on Twitter and we’ll talk!

    Here are the thoughts from Peter Cooper of HTML5 Weekly & JavaScript Weekly, Dave Camp, Director of Firefox Developer Tools and Thorben Bochenek from Opera on writing for Mozilla Hacks.

    Austin Hallock from Clay.io:

    My co-founder Zoli and I have both written articles for Mozilla Hacks and we agree that it was a very worthwhile experience. The process of getting our posts on the site was easy and both articles generated more response than we expected. Mozilla has a fantastic mission, and the Mozilla Hacks blog is a great extension of that.

    Their articles:

    Also, thanks to the authors on Mozilla Hacks for their great contributions! And those in that page are only authors with 2 posts and more – in total we have 230 authors all time who have published a post on Hacks!

    Most popular content

    During these two years, these are the most popular posts, written by Mozilla staff:

    The most popular posts, written by 3rd party developers/writers:

    Read & write

    If you like our articles, please spread the word about them! Ask your friends to read too and follow @mozhacks on Twitter for the latest articles and announcements.

    And if you have experiences and learnings to share, let us know and help you with sharing that knowledge!

  2. Enabling Voice Input into the Open Web and Firefox OS

    With the advent of smartphones triggered by iPhone in 2007, Touch became the primary mode of input for interacting with these devices. And now with the advent of wearables (and other hands-free technologies that existed before), Voice is becoming another key method of input. The possibilities of experiences Voice Input enables are huge, to say the least.

    They go beyond just merely interacting with in-vehicle devices, accessories and wearables. Just think of the avenues Voice Input opens up for bringing more technologies to more people. It’s enormous: Accessibility, Literacy, Gaming, VR and the list goes on. There is a social vibe there that definitely resonates with our mission at Mozilla detailed in our Mozilla Manifesto

    How it started

    Both current leading mobile OS/ecosystem providers of today- Apple & Google have their native experiences with Siri and “OK Google” (coupled with Google Now). We really needed an effort to enable Voice Input into the first ecosystem that existed – the open Web. Around MWC 2013 in Barcelona, when Desigan Chinniah introduced me to André Natal – Firefox contributor from Brazil, we had a conversation around this and we instantly agreed to do something about this in whichever way possible. Andre told me about being inspired from a talk by Brendan Eich in BrazilJS, so I did not have much convincing to do. :-)

    First steps

    We had numerous calls and meetings over the past year on the approach and tactics around this. Since “code wins arguments”, the basic work started in parallel with Firefox desktop and FxOS Unagi devices, later switching to Mozilla Flame devices over time. Over a period of the past year, we had several meetings with Mozilla engineering leads on exact approach and decided to break this effort into several smaller phases (“baby steps”).

    The first target was getting Web Speech API implemented, and getting acoustic/language modules integrated with a decoder and giving that a try. Lots of similar minded folks in Mozilla Engineering/QA & community helped along with guidance and code-reviews while Andre moonlighted (on top of his day job) with a very high focus. Things moved fast in past month or so. (Well, to be honest, the only day this effort slowed down was when Team Brazil lost to Germany in FIFA 2014. :-)) Full credit to André for his hard work!

    Where are we?

    Our current thinking is to get a grammar-based (limited commands) app working first and distribute it in our rich & diverse international Mozilla community for accent-based testing and enhancements. Once we have this stablilized, we will get into the phase 2 where we can focus more on natural language processing and get closer to a virtual assistant experience sometime in future that can give users voice based answers. There is lots of work to do there and we are just beginning.

    I will save the rest of the details for later and jump to the current status this month. Where are we so far?

    We now have the Web Speech API ready for testing and we have a couple demos for you to see!

    Desktop: Firefox Nightly on Mac

    Editor’s note: for full effect, start playing the two above videos at the same time.

    Firefox OS demo

    Come, Join us!

    If you want to follow along, please look at the SpeechRTC – Speech enabling the open web wiki and Bug 1032964 – Enabling Voice input in Firefox OS.

    So jump in and help out if you can. We need all of you (and your voices). Remember “Many Voices, One Mozilla”!

  3. PhoneGap Developer App preview for Firefox OS

    The cross-platform team at Mozilla is always looking for ways to improve how developers build apps with open web standards. We consider Cordova and PhoneGap to be great tools to achieve that. We are excited to work on improving support for PhoneGap by getting the PhoneGap Developer App into Firefox OS.

    The PhoneGap Developer App allows you to easily run PhoneGap apps in multiple platforms, without the need to install SDKs or have a developer subscription. The app is available for Android, iOS and Windows Phone at their respective app stores. You can pair your app with multiple devices at a time and any changes you make to your app’s code get propagated to all devices.

    Even though developing for Firefox OS does not require a beefy SDK or a developer subscription, being able to have your changes propagate to multiple devices at once is pretty cool!

    We have started working on support for Firefox OS and you can try it out today. In this post we’re going through the steps needed to get the preview version of the PhoneGap developer app in Firefox OS. As they say, a video is worth 1k images:

    Getting the dependencies

    We will be using a development version of Cordova combined with a development version of the PhoneGap command line interface to get it all working. Luckily, they are very compatible and work well together. You will need to have git, nodejs and npm installed before proceeding.

    Let’s first get all modules we’ll need from github:

      $ git clone https://github.com/apache/cordova-firefoxos.git
      $ git clone https://github.com/apache/cordova-cli.git
      $ git clone https://github.com/apache/cordova-lib.git
      $ git clone -b fxos https://github.com/rodms10/phonegap-app-developer.git
      $ git clone -b fxos https://github.com/rodms10/connect-phonegap.git
      $ git clone https://github.com/phonegap/phonegap-cli.git

    Now let’s set dependencies up:

      $ cd connect-phonegap
      $ npm link
      $ cd ../phonegap-cli
      $ npm link connect-phonegap
      $ npm install
      $ cd ../cordova-lib/cordova-lib
      $ npm link
      $ cd ../../cordova-cli
      $ npm link cordova-lib
      $ npm install
      $ cd ..

    Load the app to your device

    The app is available at phonegap-app-developer/platforms/firefoxos/www/, just point the app manager or webIDE to this path and load it to your device or simulator. Once you start the app, you should see a screen with an IP address. That’s where you enter the address of your server.

    Starting the server

    Let’s get the server going. It will serve your app’s content to the PhoneGap Developer App. Create a new Cordova app:

      $ cordova-cli/bin/cordova create myapp org.app.my "I Heart PhoneGap Dev App"
      $ cd myapp

    Now we need to point cordova to the development version of cordova-firefoxos. In your root app folder, myapp in our case, create a folder named .cordova (with the leading dot) and add a file named config.json to the new folder with the following contents:

    {
      "lib": {
        "firefoxos": {
          "uri": "/<Full/Path/To>/cordova-firefoxos",
          "version": "dev",
          "id": "cordova-firefoxos-dev"
        }
      }
    }

    Make sure you have the correct full path to cordova-firefoxos in the uri property above.

    Time to start the server, we’ll switch back to PhoneGap for that:

      $ ../phonegap-cli/bin/phonegap.js serve

    You should see a line saying [phonegap] listening on 10.0.0.1:3000. Enter that IP in the PhoneGap Developer App and see your app start running there! Easy.

    Ship It!

    If you got this far, you’re probably asking why isn’t the app in the marketplace already! As you saw, to get all up an running we required the development version of the PhoneGap command line interface. Once a new version with our new code is released, we can publish the app and not require development version of the command line.

    If you have any questions leave a comment, find us at the #apps channel on IRC or send us an email at mozilla-cordova@mozilla.org.

  4. Launching Open Web Apps feedback channels – help us make the web better!

    About three months ago we launched a feedback channel for the Firefox Developer Tools, and since it was a great success, we’re happy announce a new one for Open Web Apps!

    For Developer Tools, we have, and keep on getting, excellent suggestions at http://mzl.la/devtools, which has lead to features coming from ideas there being implemented in both Firefox 32 & 33 – the first ideas shipped in Firefox only 6 weeks after we launched the feedback channels!

    Your feedback as developers is crucial to building better products and a better web, so we want to take this one step further.

    A channel for Open Web Apps

    We have now just opened another feedback channel on UserVoice about Open Web Apps, available at http://mzl.la/openwebapps

    It is a place for constructive feedback around Open Web Apps with ideas and feature suggestions for how to make them more powerful and a first-class citizen on all platforms; desktop, mobile and more.

    What we cover in the feedback channel is collecting all your ideas and also updating you on the different areas we are working on. In many cases these features are non-standard, yet: we are striving to standardize Apps, APIs, and features through the W3C/WHATWG – so expect these features to change as they are transitioned to become part of the Web platform.

    If you want to learn more about the current state, there’s lots of documentation for Open Web Apps and WebAPIs on MDN.

    Contributing is very easy!

    If you have an idea for how you believe Open Web Apps should work, simply just go to the feedback channel, enter a name and an e-mail address (no need to create an account!) and you’re good to go!

    In addition to that, you have 10 votes assigned which you can use to vote for other existing ideas there.

    Just make sure that you have an idea that is constructive and with a limited scope, so it’s actionable; i.e. if you have a list of 10 things you are missing, enter them as a separate ideas so we can follow up on them individually.

    We don’t want to hear “the web sucks” – we want you to let us know how you believe it should be to be amazing.

    What do you want the web to be like?

    With all the discussions about web vs. native, developers choosing iOS, Android or the web as their main target, PhoneGap as the enabler and much more:

    Let us, and other companies building for the web, know what the web needs to be your primary developer choice. We want the web to be accessible and fantastic on all platforms, by all providers.

    Share your ideas and help us shape the future of the web!

  5. Using mozjpeg to Create Efficient JPEGs

    The mozjpeg project recently released version 2.1. It aims to improve the efficiency of JPEG encoding over existing encoders while maintaining compatibility with the vast majority of existing decoders.

    I’d like to explain how you can use this software to reduce the size of your JPEGs. Specifically, I’m going to go over usage of mozjpeg’s cjpeg command line utility.

    Building mozjpeg

    There are no official mozjpeg binaries available, so you’ll have to build the project from source. Do this by downloading the source code for the latest release and following the instructions in the file BUILDING.txt.

    Building on Linux and OS X is quite easy. Things are a little more complicated on Windows, but it’s still relatively easy. The mozjpeg project is considering providing binary releases in the future.

    When you build mozjpeg you’ll produce a command line tool called cjpeg. This is the encoding program that comes with mozjpeg. The decoder is called djpeg.

    Input Image Formats

    The cjpeg tool is capable of handling the following input file types: targa, bmp, ppm, and jpg.

    The ability to take JPEG files as input is a new feature in mozjpeg which doesn’t yet exists in the cjpeg tools provided by other projects. It was added to make re-compression workflows easier. Instead of converting JPEGs to BMP or something else and then re-encoding them, you can just pass the JPEG directly to the cjpeg encoder.

    If you want to create a JPEG from a file type not supported by cjpeg, take a look at the ImageMagick tools. They include a command-line utility called convert that can convert back and forth from many types of images.

    Basic Usage of the cjpeg Command Line Tool

    Most people who use mozjpeg’s cjpeg use it in its simplest form:

    $ cjpeg -quality 80 foo.bmp > bar.jpg

    This will create a JPEG called “bar.jpg” from the “foo.bmp” input file at quality level 80. cjpeg directly emits the contents of the resulting JPEG file, so if you want to write it to disk, which you probably do, you’ll need to pipe the results to a file with ‘>‘.

    Selecting a Quality Level

    Quality can range from 0 at the low end to 100 at the high end. Most people will want to pick quality a value somewhere between 60 and 90. You’ll want to use the lowest value that still produces and image at a quality you’re happy with, because lower values will produce images with smaller file sizes.

    The following image shows an original image as well as the same image encoded at five different quality levels with mozjpeg’s cjpeg. Click on it to enlarge.

    JPEG Quality Comparison

    Here are the image files one-by-one:

    (Image courtesy of Soulmatesphotography, via Wikimedia, Creative Commons Attribution-Share Alike 3.0 Unported License)

    Do some experimenting here. Lots of people don’t, and they miss out on significant reductions in file size. Their thinking is often something along the lines of “80 seems like a good compromise, and I hear that’s what most people do, so I’ll do that.” If you can’t tell the difference between an image at quality 77 vs 80, and you’re using 80, you’re missing out on significant file size savings at no cost to you in terms of quality.

    Progressive vs. Baseline JPEGs

    The mozjpeg version of cjpeg produces progressive JPEGs by default because their file sizes tend to be about 4% smaller than baseline JPEGs. Progressive JPEGs can appear at full size but blurry at first, and then progress to full resolution as the image downloads. Baseline JPEGs simply load from top to bottom.

    Baseline:
    jpeg-baseline

    Progressive:
    jpeg-progressive
    (Image courtesy of Soulmatesphotography, via Wikimedia, Creative Commons Attribution-Share Alike 3.0 Unported License)

    If you want to produce a baseline JPEG, you can do so like this:

    $ cjpeg -baseline -quality 80 foo.bmp > bar.jpg

    Targeting Metrics

    A cool feature of mozjpeg’s cjpeg is that you can optimize for any of four specific quality metrics: PSNR, PSNR-HVS-M, SSIM, and MS-SSIM. These metrics are algorithms that calculate the quality of an image compared to the original. More scientifically, this is often referred to as a distortion rate.

    These algorithms differ in how they define quality, so optimizing for one metric can hurt performance on another. See the July 2014 lossy compressed images study from Mozilla for many example of what this looks like.

    mozjpeg tunes for PSNR-HVS-M by default, because tuning for this does pretty well on all metrics.

    If you or your organization have decided that you trust a particular metric more than the others, you can tell mozjpeg’s cjpeg tool about your preference and it will tune for that metric.

    Conclusion

    Hopefully at this point you know enough to confidently start making use of mozjpeg to optimize your JPEGs. If you run into any issues, please report them on mozjpeg’s github issue tracker.

  6. Event listeners popup, @media sidebar, Cubic bezier editor + more – Firefox Developer Tools Episode 33

    A new set of Firefox Developer Tools features has just been uplifted to the Aurora channel. These features are available right now in Aurora, and will be in the Firefox 33 release in October. This release brings many new additions, especially to the Inspector tool:

    Event listeners popup

    Any node with a JavaScript event listener attached to it will now have an “ev” icon next to it in the Inspector. Clicking the icon will open a list of all the event listeners attached to that element. Click the pause icon to get taken to that function in the Debugger, where you can set breakpoints and debug it further. (development notes & UserVoice request)

    Event listener popup screenshot

    Keep in mind the events pane in the Debugger as well, which lists all the event listeners on the page

    @media sidebar

    There’s a new sidebar in the Style Editor which displays a list of shortcuts to every @media rule in the stylesheet (or Sass source) you’re editing. Click an item to jump to that rule. The condition text of the rule is greyed-out if the media query doesn’t currently apply. This works well in conjunction with the Responsive Design View (Opt+Cmd+M / Ctrl+Shift+M) for creating and debugging mobile layouts. (development notes)

    @media rules sidebar

    Add new rule

    Right-click anywhere in the Rules section of the Inspector to get an “Add Rule” option. Selecting this will add a new CSS rule, pre-populated with a selector that matches the currently selected node. (development notes & UserVoice request)

    Add rule screenshot

    Edit keyframes

    Any @keyframes rules associated with the currently selected element are now displayed in the Rules section of the Inspector, and are editable. This is the first step on the way to better debugging of CSS animations. (development notes)

    Editing @keyframe rules

    Cubic bezier editor

    To aid in editing easing animations, there’s now a cubic bezier editor that appears when you click the icon next to an animation timing function in a CSS rule. This feature used open source code from Lea Verou’s cubic-bezier.com. (development notes)

    Transform highlighter

    There’s a new awesome way to visualize how an element has been transformed from its original position and shape. Hovering over a CSS transform property in the Inspector will show the original position of the element on the page and draw lines mapping the original points to their new positions. (development notes)

    Transform highlighter screenshot

    Persistent disable cache

    You can disable the browser cache while you’re developing by checking Advanced Settings > Disable Cache in the Settings tab. Now this setting will persist the next time you open the devtools. As usual, caching is re-enabled for the tab when you close the tools. (development notes & UserVoice request)

    New Commands

    New commands have been added to the Developer Toolbar (Shift+F2):

    inject
    The new inject command lets you easily inject jQuery or other JavaScript libraries into your page. Use inject jQuery, inject underscore, or provide your own url with inject <url>. (development notes)
    highlight
    The highlight command takes a selector and highlights all the nodes on that page that match that selector. (video)(development notes)
    folder
    The folder command opens a directory in your system’s file explorer. Use folder openprofile to open your Firefox profile directory. (development notes)

    Editor preferences

    A host of editor preferences are now available in the Settings panel. From here you can change your indentation settings and change editor keybindings to Sublime Text, Vim, or Emacs. (development notes)

    WebIDE

    A big feature called WebIDE has landed, but is behind a preference for this release while it gets more testing. WebIDE is a tool for in-browser app development. See WebIDE lands in Nightly for more details.

    Other features

    Edit selectors
    Click the selector of any CSS rule in the Inspector to edit it. (development notes)
    Black boxed minified sources
    JavaScript sources with “min.js” extensions are now automatically black boxed. You can turn this option off in the Debugger settings menu. (development notes)
    Custom viewport dimensions
    The dimensions in the Responsive Design View are now editable so you can input the exact size you want the content to be. (development notes)

    Special thanks to the 33 contributors that added all the features and fixes in this release.

    Three of the features from this release came from feedback on the Developer Tools feedback channel, so that’s a great way to suggest features. You can also comment here or shoot feedback to @FirefoxDevTools on Twitter. If you’d like to help out, check out the guide to getting involved.

  7. Resources for HTML5 game developers

    Today we released Firefox 31 and it offers a couple of new features that help HTML5 game developers to code and debug sophisticated games. In addition Mozilla blogged about the first commercial games leveraging asm.js, Dungeon Defenders Eternity and Cloud Raiders both of which were cross-compiled in to JavaScript using the Emscripten compiler. Games like these show that HTML5 is ready as a game platform.

    If you are interested in working with Emscripten you can get more information at the main Emscripten wiki or grab the code on the github page. Another good resource is the getting started with Emscripten tutorial on MDN. If you are wondering about the performance of asm.js, read asm.js performance improvements in the latest version of Firefox make games fly! for details.

    In this post we’ll introduce you to some of the resources built by Mozillians that allow you to code and debug HTML5 based games. This list is not exhaustive and we appreciate feedback on any valuable resources that would help in this arena. Don’t be shy and tell us about them in the comments.

    Where To Start

    When developing an HTML5 based game, you have a lot of choices to make. These range from what editor to use, if the game will use Canvas 2d, WebGL, SVG, or CSS up to which specific rendering frameworks and game engines to use. Most of these decisions will be based on the developer experience and the platforms the game will be published on. No article will answer all these questions but we wanted to put together a post that would help get you started down the path.

    One of the key resources available for game developers on MDN is the Games Zone. This section of MDN contains general game development articles, demos, external resources and examples. It also includes detailed descriptions of some of the APIs that a developer will need to be aware of when implementing an HMTL5 game, including sound management, networking, storage and graphics rendering. We are currently in the process of adding content and upgrading the zone. In the future we hope to have content and examples for most common scenarios, frameworks and tool chains.

    In the meantime here are a few posts and MDN articles that help game developers getting started.

    Tools

    As an HTML5 developer you will have no shortage of tools at your disposal. In the Mozilla community we have been hard at work expanding the features that Firefox Developer Tools provide. These include a full-featured JavaScript Debugger, Style Editor, Page Inspector, Scratchpad, Profiler, Network Monitor and Web Console.

    In addition to these, some notable tools have been updated or introduced recently and offer some great functionality for the game developer.

    Canvas Debugger

    With the current release of Firefox, we added a Canvas Debugger to the browser.
    s_canvasdebugger
    The Canvas Debugger allows you to trace through all canvas context calls that are used to generate a frame. Calls are color coded for specific calls for things like drawing elements or using a specific shader program. The Canvas Debugger is not only useful when developing a WebGL based game but can also be used when debugging a Canvas 2D based game. In the game below you can see in the animation strip as each image is drawn to the canvas. You can click any of these lines to get directly to the part of your JavaScript responsible for this action.
    s_captainrogers
    Two very common issues that have been reported when using the Canvas Debugger are with animations generated using setInterval instead of requestAnimationFrame and inspecting canvas elements in an iFrame.

    To get more information about the Canvas Debugger be sure to read over Introducing the Canvas Debugger in Firefox Developer Tools.

    Shader Editor

    When developing WebGL based games it is very useful to be able to test and alter shader programs while the application is running. Using the Shader Editor within the developer tools makes this possible. Vertex and Fragment Shader programs can be modified without the need to reload the page, or black boxed to see what effect this has on the resulting output.
    s_ShaderEditor

    For more information on the Shader Editor, be sure to see Live editing WebGL shaders with Firefox Developer Tools post and take a look at this MDN article which contains a couple of videos showing live editing.

    Web Audio Editor

    The current version of Firefox Aurora (32) – has a Web Audio Editor. The Editor displays a graphical representation of all the Audio Nodes and their connections in the current AudioContext. You can drill down to specific attributes of each node to inspect them.
    s_webaudioeditor

    The Web Audio API provides more robust and complex sound creation, manipulation and processing than what is available in the HTML5 Audio tag. When using the Web Audio API make sure to read over Writing Web Audio API code that works in every browser as it contains pertinent information about support for the various audio nodes.

    For more information on the Web Audio Editor be sure to read this Hacks article introducing the Web Editor and this MDN article.

    Network Monitor

    When developing an HTML5 based game network impact can be not only cumbersome but also costly if the user is on mobile device. Using the Network Monitor you can visually inspect all network request for location, time spent on the operation, and the type and size of the artifact.
    s_networkmon
    In addition you can use the Network Monitor to get a visual performance analysis of your app when cached versus non-cached.
    s_networkcache

    To get more information on the Network Monitor see the MDN page.

    Web IDE

    When starting your game one of your first choices will be which editor to use. And there are a lot of them (Sublime, Eclipse, Dreamweaver, vi, etc). In most cases a you already have a favorite. If you are interested in doing your development within the Browser you may want to have a look at the Web IDE that was recently released in Firefox Nightly.
    s_webide

    The Web IDE project provides not only a fully functional editor but also acts as a publishing agent to various local and remote platforms, debugger, template framework and application manager. In addition the framework supporting this project provides APIs that will allow other editors to use functionality provided in the tool. To get more details on the work that is being done in this area have a look at this post.

    In order to keep up-to-date with news on the Firefox Developer Tools, follow their article series on the Hacks blog. For more detailed information on new, stable developer tools features, check out their documentation on MDN.

    APIs

    The MDN Games Zone lists various APIs and articles that are useful for beginning game development.
    s_apis
    In addition to these resources you may be interested in looking over some additional posts that can be valuable for development.

    If your game is going to support multiplayer interaction using either WebRTC or WebSockets you may also be interested in looking at Together.js which provides collaborative features for web apps. To get an idea what is possible take a look at Introducing TogetherJS.

    Many games will require storage and IndexedDB can be used to handle these needs. For information on extending the capabilities of IndexedDB read over Breaking the Borders of IndexedDB. You may also be interested in localForage which provides browser agnostic support for simple storage. To get more details about this library read over this Hacks post.

    Game Optimization

    HTML5 games today offer a great deal of power to the game developer. That said many of these games are going to be played on a mobile device, which in comparison to your desktop will pale in performance. So if you plan on your game being a success across platforms it is important that you optimize your code. The Optimizing your JavaScript Game for Firefox OS post has a lot of great techniques to help you build a game that performs well on low-end mobile devices.

    Localization

    In order to reach the most users of your game you may want to consider offering it in different languages. As part of this developers should start with localization built into the game. We are doing a great deal of work around recruiting translators to help you translate your game. To get more information about this initiative see this post.

    Your Voice

    As Mozilla is about the community of developers and users, we want your help and your feedback. If you have recommendations for specific features that you would like to see in the products make sure to either get involved in discussion on irc.mozilla.org or through our mailing lists. You can also log bugs at bugzilla.mozilla.org. In addition we are also provide additional feedback channels for our DevTools and Open Web Apps.

  8. ServiceWorkers and Firefox

    Since early 2013, Mozillians have been involved with the design of the Service Worker. Thanks to work by Google, Samsung, Mozilla, and others, this exciting new feature of the web platform has evolved to the point that it is being implemented in various web browser engines.

    What are Service Workers?

    At their simplest, Service Workers are scripts that act as client-side proxies for web pages. JavaScript code can intercept network requests, deliver manufactured responses and perform granular caching based on the unique needs of the application, a feature that the web platform has lacked before now. This powerful capability being made available to web developers enables, among other things, the creation of fully-functioning offline experiences. Jake Archibald has summarized some of these features in his blog post.

    Since Service Workers run in the “background”, they open up several possibilities for the Web that were previously only available on native platforms. Apart from the networking capabilities provided by the base specification, Service Workers are intended to be used by the Push API and the Background Sync API to deliver messages from the user-agent to web applications.

    Service Workers in Firefox

    A number of Mozillians have been hard at work implementing Service Workers in Gecko while Anne van Kesteren and Jonas Sicking help with the design and specification. Members of the Necko team and others have provided input from networking and related perspectives. Nikhil Marathe recently published a blog post about the status of Service Workers in Gecko.

    The Service Worker implementation in Gecko is landing in pieces as soon as they are finished and reviewed. For the time being, as the specification continues toward stability and other implementations — notably Blink’s — progress, all functionality in Gecko is behind the dom.serviceWorkers.enabled preference which is set to false by default but can be toggled in about:config.

    Our plan is that web developers will soon be able to exercise most Service Worker functionality in Firefox Nightly with the above preference flipped to true. The best plans can always be waylaid but we hope for this to happen by the end of September 2014 at the latest.

    Status of Service Worker implementations

    The inimitable Jake Archibald has written a tool to easily see the status of Service Worker implementations. You can follow along with the gecko implementation via the meta bug.

  9. What's new in Cordova 3.5.0 for Firefox OS

    The Cordova community recently released version 3.5.0 of the tools. This version includes some exciting improvements to the Firefox OS development workflow. Before we dive into the new features, make sure you have the latest version by running:

    $ sudo npm install -g cordova
    $ sudo npm install -g plugman

    Now that we’re all set up, let’s dive into the new features.

    Improved manifest management

    In previous versions of Cordova, developers had to manually edit the manifest.webapp file to add permissions and other app information. This file has crucial information that Firefox OS needs to interact with your app.

    Cordova has a configuration file called config.xml that already contains the same information needed for the manifest file. Cordova will create and update the manifest based on your config.xml file. In the new version, plugins can add configuration specifying which permissions are necessary. Whenever you run a cordova prepare, the manifest is updated based on your configuration. Now you can have all your app’s information in one place.

    Building packages with Cordova

    Firefox OS uses web technologies that do not require a compilation step to generate binaries. The related Cordova commands build and compile were left unimplemented and would throw an exception when called. That behavior was confusing and left some people wondering what went wrong.

    Now cordova build or Cordova compile will create a zip of your packaged app in the build folder inside the platform/firefoxos folder. A big thank you to the contributor Gert-Jan Braas for implementing this!

    Plugins

    A fresh batch of core plugins were released too. We added Firefox OS support to a few more plugins:

    To update to the latest version of the plugins, you need to remove and add them again. For example, to use the latest version of the file plugin run:

    $ cordova plugin rm org.apache.cordova.file
    $ cordova plugin add org.apache.cordova.file

    Replace the plugin name for the plugin you want to update. The geolocation and contacts plugins have been updated to support auto managing permissions, make sure you update them too.

    Check our status page for updated information on plugin status.

    What’s next

    A highly requested feature is support for emulate and run Cordova commands. We are working with the Dev Tools team to create an awesome experience for debugging Cordova applications using Firefox’s App Manager. Here is a sneak preview of what’s coming!

    Meanwhile you can debug your app by adding the platforms/firefoxos/www folder to the app manager in Firefox. For more information, check out Cordova for Firefox OS on MDN.

    We are working on creating default icons for a newly created app. They will serve as placeholders that can be easily replaced with your app’s brand.

    We also have a development status page where you can see up to the minute information on what is being worked on.

    We’d love to hear your feedback and feature requests. You can reach us in the #cordova channel on IRC, or through email at mozilla-cordova@mozilla.org or log your issues and requests on the Apache Cordova issue site. Also if you are interested in helping out with the project let us know.

  10. Introducing the Web Audio Editor in Firefox Developer Tools

    In Firefox 32, the Web Audio Editor joins the Shader Editor and Canvas Debugger in Firefox Developer Tools for debugging media-rich content on the web. When developing HTML5 games or fun synthesizers using web audio, the Web Audio Editor assists in visualizing and modifying all of the audio nodes within the web audio AudioContext.

    Visualizing the Audio Context

    When working with the Web Audio API‘s modular routing, it can be difficult to translate how all of the audio nodes are connected just by listening to the audio output. Often, it is challenging to debug our AudioContext just by listening to the output and looking at the imperative code that creates audio nodes. With the Web Audio Editor, all of the AudioNodes are rendered in a directed graph, illustrating the hierarchy and connections of all audio nodes. With the rendered graph, a developer can ensure that all of the nodes are connected in a way that they expect. This can be especially useful when the context becomes complex, with a network of nodes dedicated to manipulating audio and another for analyzing the data, and we’ve seen some pretty impressive uses of Web Audio resulting in such graphs!

    To enable the Web Audio Editor, open up the options in the Developer Tools, and check the “Web Audio Editor” option. Once enabled, open up the tool and reload the page so that all web audio activity can be monitored by the tool. When new audio nodes are created, or when nodes are connected and disconnected from one another, the graph will update with the latest representation of the context.

    Modifying AudioNode Properties

    Once the graph is rendered, individual audio nodes can be inspected. Clicking on an AudioNode in the graph opens up the audio node inspector where AudioParam‘s and specific properties on the node can be viewed and modified.

    Future Work

    This is just our first shippable release of the Web Audio Editor, and we are looking forward to making this tool more powerful for all of our audio developers.

    • Visual feedback for nodes that are playing, and time/frequency domain visualizations.
    • Ability to create, connect and disconnect audio nodes from the editor.
    • Tools for debugging onaudioprocess events and audio glitches.
    • Display additional AudioContext information and support multiple contexts.
    • Modify more than just primitives in the node inspector, like adding an AudioBuffer.

    We have many dream features and ideas that we’re excited about, and you can view all open bugs for the Web Audio Editor or submit new bugs. Be sure to check out the MDN documentation on the Web Audio Editor and we would also love feedback and thoughts at our UserVoice feedback channel and on Twitter @firefoxdevtools.