Mozilla

Featured Articles

Sort by:

View:

  1. Firefox OS – video presentations and slides on the OS, WebAPIs, hacking and writing apps

    In August, Mozilla’s Director of Research Andreas Gal, and one of the lead engineers for Firefox OS, Philipp von Weitershausen, gave a couple of presentations in Brazil about Firefox OS. We’re now happy to share both the videos and the slides, in various formats for you to see or use, giving your own presentations!

    Videos

    The videos are available on YouTube in the Mozilla Hacks channel, and they are split up into:

    Firefox OS – Introduction & Components

    FirefoxOS – Developer Enviroment, Apps, Marketplace

    FirefoxOS – WebAPIs & UI hacking

    Note: if you’ve opted in to HTML5 on YouTube you will get HTML5 video.

    Slides

    There were four different slide decks being used:

    They are also available in Portuguese:

    We’ve also made these slide decks available in other formats if you want to reuse them and give your own presentations about Firefox OS (and if you love talking about the Open Web, have you considered becoming an Evangelism Rep?).

    Keynote format

    PowerPoint format

  2. Tracking Down Memory Leaks in Node.js – A Node.JS Holiday Season

    This post is the first in the A Node.JS Holiday Season series from the
    Identity team at Mozilla, who last month delivered the first beta
    release of Persona
    . To make Persona, we built a collection tools addressing areas ranging from debugging, to localization, to dependency management, and more. This series of posts will share our learnings and tools with the community, tools which are relevant to anyone building a high availability service with Node.JS. We hope you enjoy the series, and look forward to your thoughts and contributions.

    We’ll start off with a topic about a nitty-gritty Node.js problem: memory leaks. We present node-memwatch – a library to help discover and isolate memory leaks in Node.

    Why Bother?

    A fair question to ask about tracking down memory leaks is “Why bother?”. Aren’t there always more pressing problems that need to be tackled first? Why not just restart your service from time to time, or throw more RAM at it? In answer to these questions, we would suggest three things:

    1. You may not be worried about your increasing memory footprint, but V8 is. (V8 is the engine that Node runs on.) As leaks grow, V8 becomes increasingly aggressive about garbage collection, slowing your app down. So in Node, memory leaks hurt performance.
    2. Leaks can trigger other types of failure. Leaky code can hang on to references to limited resources. You may run out of file descriptors; you may suddenly be unable to open new database connections. Problems of this sort may emerge long before your app runs out of memory and still leave you dead in the water.
    3. Finally, sooner or later, your app will crash. And you can bet it will happen right at the moment when you’re getting popular. And then everybody will laugh and say mean things about you on Hacker News and you’ll be sad.

    Where’s That Dripping Sound Coming From?

    In the plumbing of a complex app, there are various places where leaks can occur. Closures are probably the most well-known and notorious. Because closures maintain references to things in their scope, they are common sources for leaks.

    Closure leaks will probably be spotted eventually if somebody’s looking for them, but in Node’s asynchronous world we generate closures all the time in the form of callbacks. If these callbacks are not handled as fast as they are created, memory allocations will build up and code that doesn’t look leaky will act leaky. That’s harder to spot.

    Your application could also leak due to a bug in upstream code. You may be able to track down the location in your code from where the leak is emanating, but you might just stare in bewilderment at your perfectly-written code wondering how in the world it can be leaking!

    It’s these hard-to-spot leaks that make us want a tool like node-memwatch. Legend has it that months ago, our Lloyd Hilaiel locked himself in a closet for two days, trying to track down a memory leak that became noticeable under heavy load testing. (BTW, look forward to Lloyd’s forthcoming post on load testing.)

    After two days of bisecting, he discovered that the culprit was in the Node core: Event listeners in http.ClientRequest were not getting cleaned up. (When this was eventually fixed in Node, the patch consisted of a subtle but crucial two characters.) It was this miserable experience that made Lloyd want to write a tool to help find leaks.

    Tools for Finding Leaks

    There is already a good and continually growing collection of good tools for finding leaks in Node.js applications. Here are some of them:

    • Jimb Esser’s node-mtrace, which uses the
      GCC mtrace utility to profile heap usage.
    • Dave Pacheco’s node-heap-dump takes a snapshot of the V8 heap and serializes the whole thing out in a huge JSON file. It includes tools to traverse and investigate
      the resulting snapshot in JavaScript.
    • Danny Coates’s v8-profiler and node-inspector provide Node bindings for the V8 profiler and a Node debugging interface using the WebKit Web Inspector.
    • Felix Gnass’s fork of the same that un-disables the retainers graph
    • Felix Geisendörfer’s Node Memory Leak Tutorial is a short and sweet explanation of how to use the v8-profiler and node-debugger, and is presently the state-of-the-art for most Node.js memory leak debugging.
    • Joyent’s SmartOS platform, which furnishes an arsenal of tools at your disposal for debugging Node.js memory leaks

    We like all of these tools, but none was a perfect fit for our environment. The Web Inspector approach is fantastic for applications in development, but is difficult to use on a live deployment, especially when multiple servers and subprocess are involved in the mix. As such, it may be difficult to reproduce memory leaks that bite in long-running and heavily-loaded production environments. Tools like dtrace and libumem are truly awe-inspiring, but don’t work on all operating systems.

    Enter node-memwatch

    We wanted a platform-independent debugging library requiring no instrumentation to tell us when our programs might be leaking memory, and help us find where they are leaking. So we wrote node-memwatch.

    It gives you three things:

    • A 'leak' event emitter

      memwatch.on('leak', function(info) {
      // look at info to find out about what might be leaking
      });
    • A 'stats' event emitter

      var memwatch = require('memwatch');
      memwatch.on('stats', function(stats) {
      // do something with post-gc memory usage stats
      });
    • A heap diff class

      var hd = new memwatch.HeapDiff();
      // your code here ...
      var diff = hd.end();
    • And there is also a function to trigger garbage collection which can be
      useful in testing. Ok, four things.

      var stats = memwatch.gc();

    memwatch.on('stats', ...): Post-GC Heap Statistics

    node-memwatch can emit a sample of memory usage directly after a full garbage collection and memory compaction, before any new JS objects have been allocated. (It uses V8′s post-gc hook, V8::AddGCEpilogueCallback, to gather heap usage statistics every time GC occurs.)

    The stats data includes:

    • usage_trend
    • current_base
    • estimated_base
    • num_full_gc
    • num_inc_gc
    • heap_compactions
    • min
    • max

    Here’s an example that shows how this data looks over time with a leaky application. The graph below is tracking memory usage over time. The green crazy line shows what process.memoryUsage() reports, and the red line shows the current_base reported by node_memwatch. The box on the lower-left shows additional statistics.

    leak-gc-events

    Note that the number of incremental GCs is very high. This is a warning sign that V8 is working overtime to try to clean up allocations.

    memwatch.on('leak', ...): Heap Allocation Trends

    We have a simple heuristic to warn you that your app may be leaky. If, over five consecutive GCs, you continue to allocate memory without releasing it, node-memwatch will emit a leak event. The message tells you in nice, human-readable form what’s going on:

    { start: Fri, 29 Jun 2012 14:12:13 GMT,
      end: Fri, 29 Jun 2012 14:12:33 GMT,
      growth: 67984,
      reason: 'heap growth over 5 consecutive GCs (20s) - 11.67 mb/hr' }

    memwatch.HeapDiff(): Finding Leaks

    Finally, node-memwatch can compare snapshots of object names and allocation counts on the heap. The resulting diff can help isolate offenders.

    var hd = new memwatch.HeapDiff();
     
    // Your code here ...
     
    var diff = hd.end();

    The contents of diff will look something like this:

    {
      "before": {
        "nodes": 11625,
        "size_bytes": 1869904,
        "size": "1.78 mb"
      },
      "after": {
        "nodes": 21435,
        "size_bytes": 2119136,
        "size": "2.02 mb"
      },
      "change": {
        "size_bytes": 249232,
        "size": "243.39 kb",
        "freed_nodes": 197,
        "allocated_nodes": 10007,
        "details": [
          {
            "what": "Array",
            "size_bytes": 66688,
            "size": "65.13 kb",
            "+": 4,
            "-": 78
          },
          {
            "what": "Code",
            "size_bytes": -55296,
            "size": "-54 kb",
            "+": 1,
            "-": 57
          },
          {
            "what": "LeakingClass",
            "size_bytes": 239952,
            "size": "234.33 kb",
            "+": 9998,
            "-": 0
          },
          {
            "what": "String",
            "size_bytes": -2120,
            "size": "-2.07 kb",
            "+": 3,
            "-": 62
          }
        ]
      }
    }

    HeapDiff triggers a full GC before taking its samples, so the data won’t be full of a lot of junk. memwatch‘s event emitters will not notify of HeapDiff GC events, so you can safely put HeapDiff calls in your 'stats' handler.

    In the graph below, we’ve added the objects with the most heap allocations:

    heap-allocations

    Where to Go From Here

    node-memwatch provides:

    • Accurate memory usage tracking
    • Notifications about probable leaks
    • A means to produce a heap diff
    • That is cross-platform
    • And that does not require any extra instrumentation

    We want it to do more. In particular, we want node-memwatch to be able to provide some examples of a leaked object (e.g., names of variables, array indices, or closure code).

    We hope you’ll find node-memwatch useful in debugging leaks in your Node app, and that you’ll fork the code and help us make it better.

  3. Aurora 18: HiDPI & Touch Events

    In this Aurora cycle, Firefox gained several new interesting features:

    • HiDPI displays are now supported (like Mac’s Retina)
    • Performance and Memory improvements (with IonMonkey and a huge improvement for people using HTTP proxies)
    • Web standard support: HTML5, JS & CSS new features, with the full support of the W3C Touch events.

    Let’s look at this in more details!

    Some new HiDPI iconsMac users with a Retina displays will be pleased to have an adapted Firefox: support for HiDPI screens has landed and it is gorgeous. Not only the text is using the whole resolution, but all icons have been redone.

    A lot of performance improvements have landed during this cycle:

    • IonMonkey is the codename for the latest JavaScript improvements, and that’s a huge boost in our performance.
    • CSS Gradients use a new caching mechanism that leads to speed gains on page heavily using them.
    • Also work on reactivity led us to lower our start-up times: an unnecessary certificate validation has been removed, but the most significant gains will be seen by people using Firefox behind a proxy, like a lot of business users.
    • Finally, tab switching is quicker as Jared Wein replaced a costly regular expression by more efficient code.

    Memory management continues to get some significant work, though most progress is seen on special cases:

    • We introduced coalescing of inline style rules across nodes, when possible, leading to a significant reduction (up to 20%) of memory on pages with a lot of nodes.
    • Optimizations of our event queues led to less memory used by pages with a lot of HTML and CSS errors (when the console is closed).
    • Also tabs not yet restored are using less memory.

    As expected DThe new preset of the Responsive Design Vieweveloper Tools see steady improvements. Paul Rouget made some nice videos of these features. Of special notice we have:

    • The live preview of the DOM Tree is available.
    • The Responsive design view has now presets and the scroll bars behave more similarly of how they do on mobile phones.
    • On Mac OS, the Scratchpad now supports the native fullscreen feature.
    • New commands, dbg open & dbg close, have been added to our Command line.

    Implementation of CSS3, HTML5 & JavaScript features continues at a quick pace:

    • The W3C Touch events are now implemented on Windows too. That means that our experimental MozTouch event is no more necessary on any platform and should be replaced by the standard way of doing them. We plan to remove support of these deprecated events very soon.
    • The HTML5 reversed attribute of the <ol> element is implemented.
    • The EcmaScript 6 proxies landed.
    • WebWorkers now supports transferable objects.
    • CSS Animations have been adapted to the latest evolution of the CSS cascade.
    • SVG Glyphs can now be integrated into OpenType fonts.

    Like always, this cycle brought its fair share of novelties. And more to come in the future: CSS3 Flexible boxes layout landed and is in Aurora, but the implementation is still experimental and behind a pref, layout.css.flexbox.enable. Not yet ready for prime time, but we are getting close. Similarly WebRTC is available behind a pref, and feedback is welcomed.

    Exciting time ahead for Web developers.

  4. Creating the future of mobile with Firefox OS – resources, docs and more!

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

    What is Firefox OS?

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

    Firefox OS screenshots

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

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

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

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

    Why Firefox OS?

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

    Why build a mobile OS using JavaScript?

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

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

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

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

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

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

    OK, but why Firefox OS?

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

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

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

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

    Plenty of challenges

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

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

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

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

    Beyond the mobile phone

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

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

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

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

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

    Getting started with Firefox OS

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

    Documentation

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

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

    Source code

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

    Getting involved

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

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

    Development options

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

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

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

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

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

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

    Go forth and be part of something big

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

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

  5. r2d2b2g: an experimental prototype Firefox OS test environment

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

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

    How It Works

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

    B2G Desktop Menu Item

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

    Install Page As App Menu Item

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

    B2G Desktop

    Try It Out!

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

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

  6. First Beta release of Mozilla Persona – Login without Passwords

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

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

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

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

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

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

  7. It’s Opus, it rocks and now it’s an audio codec standard!

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

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

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

    A highly flexible codec

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

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

    Most importantly, it can adapt seamlessly within these operating points. Doing all of this with proprietary codecs would require at least six different codecs. Opus replaces all of them, with better quality.
    Illustration of the quality of different codecs
    The specification is available in RFC 6716, which includes the reference implementation. Up-to-date software releases are also available.

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

    Use cases

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

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

    For more information, visit the Opus website.

  8. Full WebRTC support is soon coming to a web browser near you!

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

    What is WebRTC?

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

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

    The three corner stones in WebRTC are:

    MediaStream
    Granting web apps/sites access to the camera and microphone on your computer, via the getUserMedia API.
    DataChannel
    Communicating data peer to peer.
    PeerConnection API
    Enabling direct peer to peer connections between two web browsers for audio and video.

    Code simplicity

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

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

    We believe WebRTC will become successful for the same reason.

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

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

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

    Coming to a web browser near you!

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

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

  9. Announcing the No JavaScript Challenge (July Dev Derby) winners!

    What can I say? Wow.

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

    Dev Derby

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

    Winners

    Runners-up

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

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

  10. Aurora 17 it out, bringing better security and support for new standards

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

    Aurora 17 brings significant improvements to standards support:

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

    Aurora 17 also brings two major security-related changes:

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

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

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

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

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

    Numerous improvements have been made to Mac OS integration:

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

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

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

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

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