Mozilla

Featured Articles

Sort by:

View:

  1. Announcing the Firefox OS Developer Preview Phone!

    Firefox OS is a new mobile operating system built entirely using open web standards. In Firefox OS, HTML5 apps can do “phone things” – they can make the phone vibrate, make a phone call or send a text message.

    This week we are announcing our new Firefox OS developer preview phones because we believe that developers will help bring the power of the web to mobile. These developer phones are being developed by Geeksphone in partnership with Telefonica. We are looking to make them available in February.

    Updated: Added the two phone models and their specifications below.

    The Keon model

    • CPU Qualcomm Snapdragon S1 1Ghz
    • UMTS 2100/1900/900 (3G HSPA)
    • GSM 850/900/1800/1900 (2G EDGE)
    • Screen 3.5″ HVGA Multitouch
    • 3 MP Camera
    • 4GB ROM, 512 MB RAM
    • MicroSD, Wifi N, Light and proximity Sensor, G-Sensor, GPS, MicroUSB
    • 1580 mAh battery
    • Over the air updates
    • Unlocked, add your own SIM card

    The Peak model

    • CPU Qualcomm Snapdragon S4 1.2Ghz x2.
    • UMTS 2100/1900/900 (3G HSPA).
    • GSM 850/900/1800/1900 (2G EDGE).
    • Screen 4.3″ qHD IPS Multitouch.
    • Camera 8 MP (back) + 2 MP (front).
    • 4 GB (ROM) and 512 (RAM).
    • MicroSD, Wifi N, Light and proximity Sensor, G-Sensor, GPS, MicroUSB, Flash (camera).
    • Battery 1800 mAh.

    Developer preview phones will help make the mobile web more accessible to more people. Developers are critical to the web and to Mozilla’s mission to make the web accessible to everyone. Hundreds of millions of people worldwide use Firefox to discover, experience and connect to the Web. A web based on open standards and open technologies. We couldn’t have done this without web developers. Now we are working on bringing the power of the web to mobile, through Firefox OS, along with all the power of open standards and an open community, and once again, we’d like to invite web developers to join us.

    Firefox OS App Days

    We’d also like to invite you to participate in Firefox OS App Days, a worldwide set of 20+ hack days happening this week. At each App Day event, you’ll have the opportunity to learn, hack, share and celebrate Firefox OS, Mozilla’s open source operating system for the mobile web. Technologists and developers from the Mozilla community will present tools and technology built to extend and support the Web platform, including mobile Web APIs to access device hardware features such as the accelerometer.

    If you can’t get to an App Day, you can still sign up for Firefox Apps & Hacks, our email newsletter for Firefox OS app developers. We’ll let you know as soon as the phones are available from Geeksphone.

    Try out Firefox OS

    If you’re a developer interested in web technologies and mobile, now is the time to try out Firefox OS. Come learn how easy it is to create an app based on HTML that has access to all of the APIs on your device. Using the same web technologies you are used to, you can make your app give alerts by vibrating the phone, take a picture with the camera or more. Play with it, experiment, try out your website, create an app.

    You can create an app for Firefox OS by making some small changes to your existing website.

    You can try out Firefox OS and your app (if you created one) in several different ways:

    • Install Marketplace for Android on your Android phone. (Your friends and family can also do this – it’s as easy as installing an app, so they can try out your app too.)
    • Use the browser-based Firefox OS Simulator to view and test your mobile app on the desktop.
    • Install Firefox OS on your own hardware.
    • Purchase a Firefox OS Developer Preview device! Working with Geeksphone and Telefonica we’ve created a Firefox OS Developer Preview phone especially for developers. Be the first to show off Firefox OS and your app! First phones will be available in February.

    Why develop an app for Firefox OS?

    • Keep the web open. Support the open web and help make sure the power of the web is available to everyone – even on mobile devices.
    • Simplicity. Develop on a single technology stack (HTML5/CSS/JavaScript/new WebAPIs) and deliver across the web and devices.
    • Freedom. You’re not locked in to a vendor-controlled ecosystem. You can distribute your app through the Firefox Marketplace, your own website, or any other store based on Mozilla’s open app store technology.

    If you have any more questions, please read the Firefox OS FAQ.

    Join us in bringing the web to mobile!

  2. Firefox 4: hardware acceleration

    The latest Firefox 4 beta has just been released. It comes with Direct2D acceleration activated by default.

    What is hardware acceleration?

    Hardware acceleration” is basically using the GPU when it’s possible (instead of the CPU). This makes page-drawing operations faster.

    There’s two different levels of acceleration going on:

    • Content acceleration speeds up rendering the actual page content, such as the text, images, CSS borders, etc. Content acceleration is also used to speed up the 2D HTML canvas. On Windows Vista/7, we use Direct2D for this and it has been activated in this new beta.
    • Compositing acceleration speeds up putting together chunks of already-rendered content (layers) together for final display in the window, potentially applying effects such as transforms along the way. For example, if you had a HTML5 video that was playing, and it had CSS effects applied to it that was making it rotate and fade in and out, that would be using compositing acceleration to make that go fast. (This feature is not activated by default yet.)

    >> Run the test yourself: Hardware Acceleration Stress Test. <<
    Credits for the photos: Paul (dex).

    Hardware Acceleration by operating system:

    These optimizations are available only if you have compatible hardware and the associated drivers.

    Operation Linux Windows XP Windows Vista/7 Mac OS X
    Content XRender None Direct2D Quartz1
    Compositing OpenGL Direct 3D Direct 3D OpenGL

    [1]: Quartz is basically CPU-only. QuartzGL (GPU acceleration for the Quartz 2D API) is not activated in Firefox for now (nor in other browsers).

    Important note: Don’t confuse hardware acceleration with WebGL. WebGL is an OpenGL-like API for Javascript to draw 3D objects into a <canvas> element. Obviously, WebGL is itself hardware accelerated since it uses OpenGL (or Direct3D through ANGLE on Windows if no OpenGL drivers are present).

    We need help!


    Help us to improve hardware acceleration in Firefox: Install the Grafx Bot extension (details here and add-on here).

    Firefox’s hardware acceleration interacts with a machine’s graphics hardware via DirectX or OpenGL, depending on platform. These interactions tend to be very sensitive to the graphics environment on the system (e.g., the specific video card(s) on the system, how much VRAM is available, the version of the video driver, the OS version, etc). In fact, there are so many permutations of the relevant factors that we can’t test them all internally.

    Grafx Bot runs a suite of automatic tests on your machine that exercises interesting aspects of hardware acceleration (for about 5 to 20 minutes). At the end of the tests, you can send your results to Mozilla (with anonymous video configuration information), where the data will be collected and analyzed, and hopefully lead to bug fixes and more reliable code for hardware acceleration than we’d otherwise have.

    We need help from the community, so we can get exposure on as many unique hardware environments as possible.

  3. Web Open Font Format for Firefox 3.6

    This article was written by John Daggett. John is a Mozilla contributor and has been working hard with font creators and web developers to improve the state of fonts on the web. This article is a high-level overview of whats different and shows some examples of WOFF in use. A full list of other supporting organizations can be found at the official Mozilla Blog.

    In Firefox 3.5 we included support for linking to TrueType and OpenType fonts. In Firefox 3.6 we’re including support for a new font format – the Web Open Font Format, or WOFF. This format has two main advantages over raw TrueType or OpenType fonts.

    1. It is compressed, which means that you will typically see much smaller download sizes compared with raw TrueType or OpenType fonts.
    2. It contains information that allows you to see where the font came from – without DRM or labeling for a specific domain – which means it has support from a large number of font creators and font foundries.

    The WOFF format originated from a collabaration between the font designers Erik van Blokland and Tal Leming with help from Mozilla’s Jonathan Kew. Each had proposed their own format and WOFF represents a melding of these different proposals. The format itself is intended to be a simple repackaging of OpenType or TrueType font data, it doesn’t introduce any new behavior, alter the @font-face linking mechanism or affect the way fonts are rendered. Many font vendors have expressed support for this new format so the hope is this will open up a wider range of font options for web designers.

    Details on Differences between TrueType, OpenType and WOFF

    First, compression is part of the WOFF format so web authors can optimize the size of fonts used on their pages. The compression format is lossless, the uncompressed font data will match that of the original OpenType or TrueType font, so the way the font renders will be the same as the original. Similar compression can be achieved using general HTTP compression but because compression is part of the WOFF format, it’s simpler for authors to use, especially in situations where access to server configuration is not possible.

    Second, the format includes optional metadata so that a font vendor can tag their fonts with information related to font usage. This metadata doesn’t affect how fonts are loaded but tools can use this information to identify the source of a given font, so that those interested in the design of a given page can track down the fonts used on that page. Fonts in WOFF format are compressed but are not encrypted, the format should not be viewed as a “secure” format by those looking for a mechanism to strictly regulate and control font use.

    Note: until Firefox 3.6 ships, users can test the use of WOFF fonts with Firefox nightly builds.

    Examples

    Below is a simple example that shows how to construct an @font-face rule that links to a WOFF font. To support browsers that only support direct linking to OpenType and TrueType fonts, the ‘src’ descriptor lists the WOFF font first along with a format hint (“woff”), followed by the TrueType version:

    /* Gentium (SIL International) */
     
    @font-face {
      font-family: GentiumTest;
      src: url(fonts/GenR102.woff) format("woff"),
           url(fonts/GenR102.ttf) format("truetype");
    }
     
    body {
      font-family: GentiumTest, Times, Times New Roman, serif;
    }

    Structured this way, browsers that support the WOFF format will download the WOFF file. Other browsers that support @font-face but don’t yet support the WOFF format will use the TrueType version. (Note: IE support is a bit trickier, as discussed below). As WOFF is adopted more widely the need to include links to multiple font formats will diminish.

    Other examples below demostrate the use of WOFF formatted fonts but each example has been constructed so that it will work in any browser that supports @font-face, including Internet Explorer.

    A font family with multiple faces

    Using a Postscript CFF font

    African Language Display

    Below is an example of how downloadable fonts can be used to render languages for which font support is usually lacking. The example shows the UN Declaration of Human Rights, translated into two African languages, and how these render with default browser fonts vs. with a downloadable font suited for rendering these languages.

    Note that in one of these examples that the font size goes from a 3.1MB TTF to a 1MB WOFF font and in the other from a 172KB TTF to an 80KB WOFF file.

    Another Postscript CFF font

    An example in Japanese

    Working With Other Browsers

    Firefox 3.6 will be the first shipping browser to support the WOFF format so it’s important to construct @font-face rules that work with browsers lacking WOFF support. One thing that helps greatly with this is the use of format hints to indicate the format of font data before it’s downloaded; browsers that don’t recognize a given format simply skip data in a format they don’t support.

    Internet Explorer, including IE8, only supports the EOT font format and only implements a subset of the @font-face rule descriptors. This makes creating cross-platform @font-face rules that work with IE especially tricky. One solution is to make different rules for IE:

    @font-face {
      font-family: GentiumTest;
      src: url(fonts/GenR102.eot);  /* for IE */
    }
     
    @font-face {
      font-family: GentiumTest;
      /* Works only in WOFF-enabled browsers */
      src: url(fonts/GenR102.woff) format("woff");
    }

    One minor downside of this is that IE doesn’t understand format hints and doesn’t parse @font-face URL’s correctly, it treats format hints as part of the URL, so web authors using the @font-face rules above will see the following in their access logs:

    GET /fonts/GenR102.eot HTTP/1.1" 200 303536
    GET /fonts/GenR102.woff)%20format(%22woff%22) HTTP/1.1" 404 335

    IE successfully pulls down and uses the EOT version of the font but also tries to pull down the WOFF font with the format hint included in the URL. This fails and doesn’t affecting page rendering but it wastes valuable server resources. For more discussion, see Paul Irish’s blog post for one interesting workaround.

    Another problem is that IE currently tries to download all fonts on the page, whether they are used or not. That makes site-wide stylesheets containing all fonts used on site pages difficult, since IE will always try to download all fonts defined in @font-face rules, wasting lots of server bandwidth.

    Further Resources

    Documentation

    Latest draft WOFF specification
    Original blog post on using @font-face
    CSS3 Fonts working draft
    MDC @font-face documentation

    Tools

    Jonathan Kew’s sample encoding/decoding code
    woffTools – tools for examining and validating WOFF files
    FontTools/TTX – Python library and tool for manipulating font data
    Web-based font subsetting tool

    General @font-face Examples

    CSS @ Ten: The Next Big Thing
    Example layout using Graublau Sans
    Examples of Interesting Web Typography
    The Elements of Typographic Style Applied to the Web

    Font Resources

    Font Squirrel
    10 Great Free Fonts for @font-face
    40 Excellent Free Fonts by Smashing Magazine

  4. 5 years of Firefox

    5 Years of Firefox Cake at the Firefox Developer Day in Tokyo, Japan

    5 Years of Firefox Cake at the Firefox Developer day in Tokyo, Japan

    Firefox is five years old. We thought that we would celebrate that by talking about how the web has changed over the last five years and Firefox’s role in those changes.

    Where We’re At

    2009 has been an interesting year. We’re at a crossroads for the Internet. In the next 12 months or so we’re likely to see regulation of the Internet in the United States – possibly for good, possibly for bad. We’ve seen increased interest in the browser space with the entrace of Google with their minimalist Chrome browser. Mozilla put a vastly improved rendering engine into the hands of hundreds of millions of users with the release of Firefox 3.5. The EU is working with Microsoft to implement a ballot to make users aware of browser choice. No one could possibly say that things are boring right now. And this has only been over the last year.

    But what has changed over the last five years? What are the main themes? We’ve picked a few to talk about and we hope that it helps put things into perspective for the next five.

    The Rise of the Modern Browser

    One thing that’s become obvious over the last five years is the wide gap that’s emerging between the field of modern browsers – Firefox, Safari, Opera and Chrome – with the world’s most popular browser – IE. The modern browser is built for the future of web applications – super fast JavaScript, modern CSS, HTML5, support for the various web-apps standards, downloadable font support, offline application support, raw graphics through canvas and WebGL, native video, advanced XHR capabilities mixed with new security tools and network capabilities.

    Over the last five years we’ve been setting ourselves up for the next five. The web is moving faster, not slower, and modern browsers are set to handle it.

    In this sense we’ve done our jobs at Mozilla. We were first on the scene with fast JavaScript, CORS, mixing HTML and SVG, WebGL is based on Canvas3D work we pioneered, we’re scripting hardware with geolocation and orientation. We’re helping to standardize and implement some new CSS capabilities that are being developed in other browsers, we’re leading the web towards a modern font system and giving web authors and users more security tools. Our job is to help keep the web rich and moving forward – this is a huge part of our public benefit mission. This is the opportunity that Firefox’s five years have offered us.

    The browsers that are on the horizon aren’t just incremental changes – they represent the pieces to build the next generation web – rich with standards-based graphics, new JavaScript libraries and full blown applications.

    Standards Won

    Firefox’s growth on the web has had another important effect – bringing standards to the forefront of development. Very early in the Mozilla project almost half of the web’s HTML pages started using DOCTYPE in order to opt-in to standards mode for many web browsers. Developers signaled that they wanted to use a standards-based method for development.

    That’s important. It set up the current frame for development on the web that we have today. It allowed Apple to take KHTML and turn it into Safari which then allowed Chrome to pick up that work and enter the market and render a standards-based web. Now we don’t have just one or two browsers, but many, and a lot of that has to do with the way that early web developers approached development.

    Standards matter, and they should continue to matter. When they do those individual human beings we like to call users benefit with greater choice and fast innovation.

    Customizing Your Experience

    Led by Firefox’s add-ons system there’s been an explosion in the number of people who are customizing their experiences – both in browsers and on the web. Anywhere from one third to one half of Firefox users have some kind of add-on installed.

    The web is unique, and was built to be hacked. No other widely-deployed system in the world delivers itself as source code like the web does. And this transparency has made it possible for the distributed innovation that we’re seeing in Firefox and on the web. People patching new UI into their favorite web sites, mashing up data from multiple sources or radically changing the feel of the browser itself – this is a source for inspiration for browser vendors and web site operators alike. For the first time individual people have the ability to take an active part in the future of their computing experience.

    It’s also worth noting that Gecko and Firefox are unique in this space. The highly modular nature of Gecko mixed with the fact that Firefox itself is written in HTML and XUL (another UI-focused markup language) means that it’s the only browser that’s hackable like the web is. Every other browser is built as a monolithic desktop application from the last millennium. This natural advantage not only means that Firefox has the widest array of add-ons and developers, but is also a source of inspiration for most of the rest of the market.

    RSS and Data

    In the last five years one of the big changes we’ve seen is web sites offering up data and feeds. Feeds in particular have reached the point where even non-technical people know what they are and how to use them. The ubiquitous RSS icon, which was originally created for the Firefox browser and given away by Mozilla, now exists on millions of web sites offering users the ability to get updates on their terms.

    But we’ve gone far beyond just simple feeds. Advanced APIs are now appearing for web sites so you can integrate native applications, build a Firefox extension or be able to pull your data out of a web site.

    And we’ve also moved from the promise of XML to the reality of JSON as the data format of choice.

    Video

    It’s important to remember that Youtube didn’t exist when Firefox was launched. At that time your only options were native QuickTime, Windows Media or Real Player. (Anyone remember Real Player?)

    In the last few years we’ve seen Youtube become one of the largest sites of the Internet, the launch of Hulu, and sites like Netflix offering premium on-demand video right over the Internet to web browsers and devices alike. We’ve also seen millions of people create their own videos and publish them to the web.

    We’ve also seen the launch of open video and native video support in browsers to bring the creativity and hackability of the web to currently closed video platforms.

    Users as Creators

    The rise of the web is a story of anyone being able to create a web site. But that’s still a largely technical exercise, even with tools. What we have seen, thanks to tools like WordPress and blogger, is the growth of weblogs, feeds and data which make it possible for anyone with a web browser to become a publisher or journalist.

    And it has moved well beyond just text. People with low-cost tools are making movies and posting them. Remix culture is alive and well, creating comentary and new and exciting creations – all in the hands of pretty normal people.

    Mobile

    The iPhone taught us that you could build a decent browser for mobile phones and that data was important. Phones, really just in the last five years or so, have shown us that access to data plans that look like what you can get to your house can unleash developer and user creativity.

    In the last five years at Mozilla we’ve also made the commitment to build a browser for mobile devices. We’re still in an early pre-1.0 beta stage, but that browser is already getting excellent reviews.

    So what about the next five years?

    Mozilla has been at the heart of many of the issues of the Internet over the last five years. We’ve vastly improved the browsing experience for hundreds of millions of people around the world. We’ve managed to keep Microsoft honest and forced them to release newer versions of their browsers. Firefox’s presence was a large factor in Apple being able to ship a browser to its user base as the Mac came back to the market. We’ve made it possible for third party browser vendors like Google to enter the market. We’ve proven that people care about improving their experiences on the web. We’ve given over 330 million people the taste of what it’s like to use an open source product. And we’ve overseen the technical growth of the web through direct action and standardization.

    It’s hard to beat that, but we’re going to try. We’ll continue to make competitive browser releases and improve people’s experiences on the web. We’ll continue to innovate on behalf of developers and bring those improvements to the standards space. And we’ll continue to grow our amazing global community of users, developers and activists.

    Over the next five years everyone can expect that the browser should take part in a few new areas – to act as the user agent it should be. Issues around data, privacy and identity loom large. You will see the values of Mozilla’s public benefit mission reflected in our product choices in these areas to make users safer and help them understand what it means to share data with web sites.

    Expect to see big changes in the video space. HTML5-based video and open video codecs are starting to appear on the web as web developers make individual choices to support a standards-based, royalty-free approach. Expect to see changes in the expectations around the licensing of codecs.

    And over the next five years mobile will play an increasingly important role in our lives, and in the future of the web. The decisions of users, carriers, governments and the people who build phones will have far-reaching effects on this new extension to the Internet and how people will access information for decades to come.

    Mozilla has a unique place on the Internet. Driven to help improve it as part of our mission expect us to express opinions on decisions that affect its future. We act both through direct action but also through indirect action – sometimes our effects are as important as our actions. We will continue to protect users and we’ll continue to do everything they can to make it possible for the next set of people to come along and build the next great web site.

    It’s been a great five years. Let’s make it another five and keep the web moving forward for the benefit of everyone.

  5. Video, Mobile, and the Open Web

    [Also posted at brendaneich.com.]

    I wrote The Open Web and Its Adversaries just over five years ago, based on the first SXSW Browser Wars panel (we just had our fifth, it was great — thanks to all who came).

    Some history

    The little slideshow I presented is in part quaint. WPF/E and Adobe Apollo, remember those? (Either the code names, or the extant renamed products?) The Web has come a long way since 2007.

    But other parts of my slideshow are still relevant, in particular the part where Mozilla and Opera committed to an unencumbered <video> element for HTML5:

    • Working with Opera via WHATWG on <video>
      • Unencumbered Ogg Theora decoder in all browsers
      • Ogg Vorbis for <audio>
      • Other formats possible
      • DHTML player controls

    We did what we said we would. We fought against the odds. We carried the unencumbered HTML5 <video> torch even when it burned our hands.

    We were called naive (no) idealists (yes). We were told that we were rolling a large stone up a tall hill (and how!). We were told that we could never overcome the momentum behind H.264 (possibly true, but Mozilla was not about to give up and pay off the patent rentiers).

    Then in 2009 Google announced that it would acquire On2 (completed in 2010), and Opera and Mozilla had a White Knight.

    At Google I/O in May 2010, Adobe announced that it would include VP8 (but not all of WebM?) support in an upcoming Flash release.

    On January 11, 2011, Mike Jazayeri of Google blogged:

    … we are changing Chrome’s HTML5 <video> support to make it consistent with the codecs already supported by the open Chromium project. Specifically, we are supporting the WebM (VP8) and Theora video codecs, and will consider adding support for other high-quality open codecs in the future. Though H.264 plays an important role in video, as our goal is to enable open innovation, support for the codec will be removed and our resources directed towards completely open codec technologies.

    These changes will occur in the next couple months….

    A followup post three days later confirmed that Chrome would rely on Flash fallback to play H.264 video.

    Where we are today

    It is now March 2012 and the changes promised by Google and Adobe have not been made.

    What’s more, any such changes are irrelevant if made only on desktop Chrome — not on Google’s mobile browsers for Android — because authors typically do not encode twice (once in H.264, once in WebM), they instead write Flash fallback in an <object> tag nested inside the <video> tag. Here’s an example adapted from an Opera developer document:

    <video controls poster="video.jpg" width="854" height="480">
     <source src="video.mp4" type="video/mp4">
     <object type="application/x-shockwave-flash" data="player.swf"
             width="854" height="504">
      <param name="allowfullscreen" value="true">
      <param name="allowscriptaccess" value="always">
      <param name="flashvars" value="file=video.mp4">
      <!--[if IE]><param name="movie" value="player.swf"><![endif]-->
      <img src="video.jpg" width="854" height="480" alt="Video">
      <p>Your browser can't play HTML5 video.
     </object>
    </video>
    

    The Opera doc nicely carried the unencumbered video torch by including

     <source src="video.webm" type="video/webm">
    

    after the first <source> child in the <video> container (after the first, because of an iOS WebKit bug, the Opera doc said), but most authors do not encode twice and host two versions of their video (yes, you who do are to be commended; please don’t spam my blog with comments, you’re not typical — and YouTube is neither typical nor yet completely transcoded [1]).

    Of course the ultimate fallback content could be a link to a video to download and view in a helper app, but that’s not “HTML5 video” and it is user-hostile (profoundly so on mobile). Flash fallback does manage to blend in with HTML5, modulo the loss of expressiveness afforded by DHTML playback controls.

    Now, consider carefully where we are today.

    Firefox supports only unencumbered formats from Gecko’s <video> implementation. We rely on Flash fallback that authors invariably write, as shown above. Let that sink in: we, Mozilla, rely on Flash to implement H.264 for Firefox users.

    Adobe has announced that it will not develop Flash on mobile devices.

    In spite of the early 2011 Google blog post, desktop Chrome still supports H.264 from <video>. Even if it were to drop that support, desktop Chrome has a custom patched Flash embedding, so the fallback shown above will work well for almost all users.

    Mobile matters most

    Android stock browsers (all Android versions), and Chrome on Android 4, all support H.264 from <video>. Given the devices that Android has targeted over its existence, where H.264 hardware decoding is by far the most power-efficient way to decode, how could this be otherwise? Google has to compete with Apple on mobile.

    Steve Jobs may have dealt the death-blow to Flash on mobile, but he also championed and invested in H.264, and asserted that “[a]ll video codecs are covered by patents”. Apple sells a lot of H.264-supporting hardware. That hardware in general, and specifically in video playback quality, is the gold standard.

    Google is in my opinion not going to ship mobile browsers this year or next that fail to play H.264 content that Apple plays perfectly. Whatever happens in the very long run, Mozilla can’t wait for such an event. Don’t ask Google why they bought On2 but failed to push WebM to the exclusion of H.264 on Android. The question answers itself.

    So even if desktop Chrome drops H.264 support, Chrome users almost to a person won’t notice, thanks to Flash fallback. And Apple and Google, along with Microsoft and whomever else might try to gain mobile market share, will continue to ship H.264 support on all their mobile OSes and devices — hardware-implemented H.264, because that uses far less battery than alternative decoders.

    Here is a chart of H.264 video in HTML5 content on the Web from MeFeedia:

    MeFeedia.com, December 2011

    And here are some charts showing the rise of mobile over desktop from The Economist:

    The Economist, October 2011

    These charts show Bell’s Law of Computer Classes in action. Bell’s Law predicts that the new class of computing devices will replace older ones.

    In the face of this shift, Mozilla must advance its mission to serve users above all other agendas, and to keep the Web — including the “Mobile Web” — open, interoperable, and evolving.

    What Mozilla is doing

    We have successfully launched Boot to Gecko (B2G) and we’re preparing to release a new and improved Firefox for Android, to carry our mission to mobile users.

    What should we do about H.264?

    Andreas Gal proposes to use OS- and hardware-based H.264 decoding capabilities on Android and B2G. That thread has run to over 240 messages, and spawned some online media coverage.

    Some say we should hold out longer for someone (Google? Adobe?) to change something to advance WebM over H.264.

    MozillaMemes.tumblr.com/post/19415247873

    Remember, dropping H.264 from <video> only on desktop and not on mobile doesn’t matter, because of Flash fallback.

    Others say we should hold out indefinitely and by ourselves, rather than integrate OS decoders for encumbered video.

    I’ve heard people blame software patents. I hate software patents too, but software isn’t even the issue on mobile. Fairly dedicated DSP hardware takes in bits and puts out pixels. H.264 decoding lives completely in hardware now.

    Yes, some hardware also supports WebM decoding, or will soon. Too little, too late for HTML5 <video> as deployed and consumed this year or (for shipping devices) next.

    As I wrote in the newsgroup thread, Mozilla has never ignored users or market share. We do not care only about market share, but ignoring usability and market share can easily lead to extinction. Without users our mission is meaningless and our ability to affect the evolution of open standards goes to zero.

    Clearly we have principles that prohibit us from abusing users for any end (e.g., by putting ads in Firefox’s user interface to make money to sustain ourselves). But we have never rejected encumbered formats handled by plugins, and OS-dependent H.264 decoding is not different in kind from Flash-dependent H.264 decoding in my view.

    We will not require anyone to pay for Firefox. We will not burden our downstream source redistributors with royalty fees. We may have to continue to fall back on Flash on some desktop OSes. I’ll write more when I know more about desktop H.264, specifically on Windows XP.

    What I do know for certain is this: H.264 is absolutely required right now to compete on mobile. I do not believe that we can reject H.264 content in Firefox on Android or in B2G and survive the shift to mobile.

    Losing a battle is a bitter experience. I won’t sugar-coat this pill. But we must swallow it if we are to succeed in our mobile initiatives. Failure on mobile is too likely to consign Mozilla to decline and irrelevance. So I am fully in favor of Andreas’s proposal.

    Our mission continues

    Our mission, to promote openness, innovation, and opportunity on the Web, matters more than ever. As I said at SXSW in 2007, it obligates us to develop and promote unencumbered video. We lost one battle, but the war goes on. We will always push for open, unencumbered standards first and foremost.

    In particular we must fight to keep WebRTC unencumbered. Mozilla and Opera also lost the earlier skirmish to mandate an unencumbered default format for HTML5 <video>, but WebRTC is a new front in the long war for an open and unencumbered Web.

    We are researching downloadable JS decoders via Broadway.js, but fully utilizing parallel and dedicated hardware from JS for battery-friendly decoding is a ways off.

    Can we win the long war? I don’t know if we’ll see a final victory, but we must fight on. Patents expire (remember the LZW patent?). They can be invalidated. (Netscape paid to do this to certain obnoxious patents, based on prior art.) They can be worked around. And patent law can be reformed.

    Mozilla is here for the long haul. We will never give up, never surrender.

    /be

    [1] Some points about WebM on YouTube vs. H.264:

    • Google has at best transcoded only about half the videos into WebM. E.g., this YouTube search for “cat” gives ~1.8M results, while the same one for WebM videos gives 704K results.
    • WebM on YouTube is presented only for videos that lack ads, which is a shrinking number on YouTube. Anything monetizable (i.e., popular) has ads and therefore is served as H.264.
    • All this is moot when you consider mobile, since there is no Flash on mobile, and as of yet no WebM hardware, and Apple’s market-leading position.

  6. Hello Chrome, it's Firefox calling!

    Mozilla is excited to announce that we’ve achieved a major milestone in WebRTC development: WebRTC RTCPeerConnection interoperability between Firefox and Chrome. This effort was made possible because of the close collaboration between the open Web community and engineers from both Mozilla and Google.

    RTCPeerConnection (also known simply as PeerConnection or PC) interoperability means that developers can now create Firefox WebRTC applications that make direct audio/video calls to Chrome WebRTC applications without having to install a third-party plugin. Because the functionality is now baked into the browser, users can avoid problems with first-time installs and buggy plugins, and developers can deploy their apps much more easily and universally.

    To help celebrate this momentous milestone, we thought it would be fun to call up our friends at Google to discuss it with them. Check out this Firefox-Chrome demonstration call between Mozilla’s Chief Innovation Officer, Todd Simpson, and Google’s Director of Product Management, Hugh Finnan, and read what Google had to say about this momentous occasion in their blog post.

    This milestone builds on an earlier demo we showed late last year of WebRTC integrated with Social API. There we demonstrated an industry first with our implementation of DataChannels, a powerful component of WebRTC that can combined with an audio/video chat to allow users to share almost anything on their computer or device. Send vacation photos, memorable videos, links news stories etc., simply by dragging the item into your video chat window. Look out for more on this to come.

    The purpose of WebRTC, an open standard being defined jointly at the W3C and IETF standards organizations, is to provide a common platform for all user devices to communicate and share audio, video and data in real-time. This is a first step toward that vision of interoperability and true, open, real-time communication on the web.

    Posted by:
    Serge Lachapelle, Chrome Product Manager and Maire Reavy, Firefox Media Product Lead

    Start Developing Using RTCPeerConnection in Firefox

    For JavaScript developers who haven’t tried RTCPeerConnection in Firefox yet (since it is a brand new feature for us), you can try this out using the most recent Firefox Nightly by setting the media.peerconnection.enabled pref to “true” (browse to about:config and search for the media.peerconnection.enabled pref in the list of prefs). Here is a snippet of code from a sample app that shows off how to initiate, accept, and end a WebRTC call in Firefox using RTCPeerConnection:

    function initiateCall(user) {
      document.getElementById("main").style.display = "none";
      document.getElementById("call").style.display = "block";
     
      // Here's where you ask user permission to access the camera and microphone streams
      navigator.mozGetUserMedia({video:true, audio:true}, function(stream) {
        document.getElementById("localvideo").mozSrcObject = stream;
        document.getElementById("localvideo").play();
        document.getElementById("localvideo").muted = true;
     
        // Here's where you set up a Firefox PeerConnection
        var pc = new mozRTCPeerConnection();
        pc.addStream(stream);
     
        pc.onaddstream = function(obj) {
          log("Got onaddstream of type " + obj.type);
          document.getElementById("remotevideo").mozSrcObject = obj.stream;
          document.getElementById("remotevideo").play();
          document.getElementById("dialing").style.display = "none";
          document.getElementById("hangup").style.display = "block";
        };
     
        pc.createOffer(function(offer) {
          log("Created offer" + JSON.stringify(offer));
          pc.setLocalDescription(offer, function() {
            // Send offer to remote end.
            log("setLocalDescription, sending to remote");
            peerc = pc;
            jQuery.post(
              "offer", {
                to: user,
                from: document.getElementById("user").innerHTML,
                offer: JSON.stringify(offer)
              },
              function() { console.log("Offer sent!"); }
            ).error(error);
          }, error);
        }, error);
      }, error);
    }
     
    function acceptCall(offer) {
      log("Incoming call with offer " + offer);
      document.getElementById("main").style.display = "none";
      document.getElementById("call").style.display = "block";
     
      // Here's where you ask user permission to access the camera and microphone streams
      navigator.mozGetUserMedia({video:true, audio:true}, function(stream) {
        document.getElementById("localvideo").mozSrcObject = stream;
        document.getElementById("localvideo").play();
        document.getElementById("localvideo").muted = true;
     
        // Here's where you set up a Firefox PeerConnection
        var pc = new mozRTCPeerConnection();
        pc.addStream(stream);
     
        pc.onaddstream = function(obj) {
          document.getElementById("remotevideo").mozSrcObject = obj.stream;
          document.getElementById("remotevideo").play();
          document.getElementById("dialing").style.display = "none";
          document.getElementById("hangup").style.display = "block";
        };
     
        pc.setRemoteDescription(JSON.parse(offer.offer), function() {
          log("setRemoteDescription, creating answer");
          pc.createAnswer(function(answer) {
            pc.setLocalDescription(answer, function() {
              // Send answer to remote end.
              log("created Answer and setLocalDescription " + JSON.stringify(answer));
              peerc = pc;
              jQuery.post(
                "answer", {
                  to: offer.from,
                  from: offer.to,
                  answer: JSON.stringify(answer)
                },
                function() { console.log("Answer sent!"); }
              ).error(error);
            }, error);
          }, error);
        }, error);
      }, error);
    }
     
    function endCall() {
      log("Ending call");
      document.getElementById("call").style.display = "none";
      document.getElementById("main").style.display = "block";
     
      document.getElementById("localvideo").mozSrcObject.stop();
      document.getElementById("localvideo").mozSrcObject = null;
      document.getElementById("remotevideo").mozSrcObject = null;
     
      peerc.close();
      peerc = null;
    }

    You’ll notice that Firefox still prefixes the RTCPeerConnection API call as mozRTCPeerConnection because the standards committee is not yet done defining it. Chrome prefixes it as webkitRTCPeerConnection. Once the standards committee finishes its work, we will remove the prefixes and use the same API, but in the meantime, you’ll want to support both prefixes so that your app works in both browsers.

    Trying Interop Yourself

    For those eager to give interop a try, here are instructions and information about “trying this at home”.

    This is Firefox’s and Chrome’s first version of PeerConnection interoperability. As with most early releases, there are still bugs to fix, and interop isn’t supported yet in every network environment. But this is a major step forward for this new web feature and for the Web itself. We thank the standards groups and every contributor to the WebRTC community. While there’s more work to do, we hope you’ll agree that the Web is about to get a lot more awesome.

  7. There is no simple solution for local storage

    TL;DR: we have to stop advocating localStorage as a great opportunity for storing data as it performs badly. Sadly enough the alternatives are not nearly as supported or simple to implement.

    When it comes to web development you will always encounter things that sound too good to be true. Sometimes they are good, and all that stops us from using them is our notion of being conspicuous about *everything* as developers. In a lot of cases, however, they really are not as good as they seem but we only find out after using them for a while that we are actually “doing it wrong”.

    One such case is local storage. There is a storage specification (falsely attributed to HTML5 in a lot of examples) with an incredibly simple API that was heralded as the cookie killer when it came out. All you have to do to store content on the user’s machine is to access the navigator.localStorage (or sessionStorage if you don’t need the data to be stored longer than the current browser session):

    localStorage.setItem( 'outofsight', 'my data' );
    console.log( localStorage.getItem( 'outofsight' ) ); // -> 'my data'

    This local storage solution has a few very tempting features for web developers:

    • It is dead simple
    • It uses strings for storage instead of complex databases (and you can store more complex data using JSON encoding)
    • It is well supported by browsers
    • It is endorsed by a lot of companies (and was heralded as amazing when iPhones came out)

    A few known issues with it are that there is no clean way to detect when you reach the limit of local storage and there is no cross-browser way to ask for more space. There are also more obscure issues around sessions and HTTPS, but that is just the tip of the iceberg.

    The main issue: terrible performance

    LocalStorage also has a lot of drawbacks that aren’t quite documented and certainly not covered as much in “HTML5 tutorials”. Especially performance oriented developers are very much against its use.

    When we covered localStorage a few weeks ago using it to store images and files in localStorage it kicked off a massive thread of comments and an even longer internal mailing list thread about the evils of localStorage. The main issues are:

    • localStorage is synchronous in nature, meaning when it loads it can block the main document from rendering
    • localStorage does file I/O meaning it writes to your hard drive, which can take long depending on what your system does (indexing, virus scanning…)
    • On a developer machine these issues can look deceptively minor as the operating system cached these requests – for an end user on the web they could mean a few seconds of waiting during which the web site stalls
    • In order to appear snappy, web browsers load the data into memory on the first request – which could mean a lot of memory use if lots of tabs do it
    • localStorage is persistent. If you don’t use a service or never visit a web site again, the data is still loaded when you start the browser

    This is covered in detail in a follow-up blog post by Taras Glek of the Mozilla performance team and also by Andrea Giammarchi of Nokia.

    In essence this means that a lot of articles saying you can use localStorage for better performance are just wrong.

    Alternatives

    Of course, browsers always offered ways to store local data, some you probably never heard of as shown by evercookie (I think my fave when it comes to the “evil genius with no real-world use” factor is the force-cached PNG image to be read out in canvas). In the internal discussions there was a massive thrust towards advocating IndexedDB for your solutions instead of localStorage. We then published an article how to store images and files in IndexedDB and found a few issues – most actually related to ease-of-use and user interaction:

    • IndexedDB is a full-fledged DB that requires all the steps a SQL DB needs to read and write data – there is no simple key/value layer like localStorage available
    • IndexedDB asks the user for permission to store data which can spook them
    • The browser support is not at all the same as localStorage, right now IndexedDB is supported in IE10, Firefox and Chrome and there are differences in their implementations
    • Safari, Opera, iOS, Opera Mobile, Android Browser favour WebSQL instead (which is yet another standard that has been officially deprecated by the W3C)

    As always when there are differences in implementation someone will come up with an abstraction layer to work around that. Parashuram Narasimhan does a great job with that – even providing a jQuery plugin. It feels wrong though that we as implementers have to use these. It is the HTML5 video debate of WebM vs. H264 all over again.

    Now what?

    There is no doubt that the real database solutions and their asynchronous nature are the better option in terms of performance. They are also more matured and don’t have the “shortcut hack” feeling of localStorage. On the other hand they are hard to use in comparison, we already have a lot of solutions out there using localStorage and asking the user to give us access to storing local files is unacceptable for some implementations in terms of UX.

    The answer is that there is no simple solution for storing data on the end users’ machines and we should stop advocating localStorage as a performance boost. What we have to find is a solution that makes everybody happy and doesn’t break the current implementations. This might prove hard to work around. Here are some ideas:

    • Build a polyfill library that overrides the localStorage API and stores the content in IndexedDB/WebSQL instead? This is dirty and doesn’t work around the issue of the user being asked for permission
    • Implement localStorage in an asynchronous fashion in browsers – actively disregarding the spec? (this could set a dangerous precedent though)
    • Change the localStorage spec to store asynchronously instead of synchronously? We could also extend it to have a proper getStorageSpace interface and allow for native JSON support
    • Define a new standard that allows browser vendors to map the new API to the existing supported API that matches the best for the use case?

    We need to fix this as it doesn’t make sense to store things locally and sacrifice performance at the same time. This is a great example of how new web standards give us much more power but also make us face issues we didn’t have to deal with before. With more access to the OS, we also have to tread more carefully.

  8. Firefox 5 is here

    Today, three months after the release of Firefox 4, we release Firefox 5, thanks to our new development cycle. Developers will be able to create richer animations using CSS3 Animations. This release comes with various improvements, performance optimization and bug fixes.

    CSS3 Animations

    CSS Animations (check out the documentation) are a new way to create animations using CSS. Like CSS Transitions, they are efficient and run smoothly (see David Baron’s article), and the developers have a better controls over the intermediate steps (keyframes), and can now create much more complex animations.

    Notable changes

    Other Bug Fixes and Performance Improvements:

    HTML

    Canvas improvements

    • The <canvas> 2D drawing context now supports specifying an ImageData object as the input to the createImageData() method; this creates a new ImageData object initialized with the same dimensions as the specified object, but still with all pixels preset to transparent black.
    • Specifying non-finite values when adding color stops through a call to the CanvasGradient method addColorStop() now correctly throws INDEX_SIZE_ERR instead of SYNTAX_ERR.
    • The HTMLCanvasElement method toDataURL() now correctly lower-cases the specified MIME type before matching.
    • getImageData() now correctly accepts rectangles that extend beyond the bounds of the canvas; pixels outside the canvas are returned as transparent black.
    • drawImage() and createImageData() now handle negative arguments in accordance with the specification, by flipping the rectangle around the appropriate axis.
    • Specifying non-finite values when calling createImageData() now properly throws a NOT_SUPPORTED_ERR exception.
    • createImageData() and getImageData() now correctly return at least one pixel’s worth of image data if a rectangle smaller than one pixel is specified.
    • Specifying a negative radius when calling createRadialGradient() now correctly throws INDEX_SIZE_ERR.
    • Specifying a null or undefined image when calling createPattern() or drawImage() now correctly throws a TYPE_MISMATCH_ERR exception.
    • Specifying invalid values for globalAlpha no longer throws a SYNTAX_ERR exception; these are now correctly silently ignored.
    • Specifying invalid values when calling translate(), transform(), rect(), clearRect(), fillRect(), strokeRect(), lineTo(), moveTo(), quadraticCurveTo(), or arc() no longer throws an exception; these calls are now correctly silently ignored.
    • Setting the value of shadowOffsetX, shadowOffsetY, or shadowBlur to an invalid value is now silently ignored.
    • Setting the value of rotate or scale to an invalid value is now silently ignored.

    CSS

    • Support for CSS animations has been added, using the -moz- prefix for now.

    DOM

    • The selection object’s modify() method has been changed so that the “word” selection granularity no longer includes trailing spaces; this makes it more consistent across platforms and matches the behavior of WebKit’s implementation.
    • The window.setTimeout() method now clamps to send no more than one timeout per second in inactive tabs. In addition, it now clamps nested timeouts to the smallest value allowed by the HTML5 specification: 4 ms (instead of the 10 ms it used to clamp to).
    • Similarly, the window.setInterval() method now clamps to no more than one interval per second in inactive tabs.
    • XMLHttpRequest now supports the loadend event for progress listeners. This is sent after any transfer is finished (that is, after the abort, error, or load event). You can use this to handle any tasks that need to be performed regardless of success or failure of a transfer.
    • The Blob and, by extension, the File objects’ slice() method has been removed and replaced with a new, proposed syntax that makes it more consistent with Array.slice() and String.slice() methods in JavaScript. This method is named mozSlice() for now.
    • The value of window.navigator.language is now determined by looking at the value of the Accept-Language HTTP header.

    JavaScript

    • Regular expressions are no longer callable as if they were functions; this change has been made in concert with the WebKit team to ensure compatibility (see WebKit bug 28285).
    • The Function.prototype.isGenerator() method is now supported; this lets you determine if a function is a generator.

    SVG

    • The class SVG attribute can now be animated.
    • The following SVG-related DOM interfaces representing lists of objects are now indexable and can be accessed like arrays; in addition, they have a length property indicating the number of items in the lists: SVGLengthList , SVGNumberList , SVGPathSegList , and SVGPointList.

    HTTP

    • Firefox no longer sends the “Keep-Alive” HTTP header; we weren’t formatting it correctly, and it was redundant since we were also sending the Connection: or Proxy-Connection: header with the value “keep-alive” anyway.
    • The HTTP transaction model has been updated to be more intelligent about reusing connections in the persistent connection pool; instead of treating the pool as a FIFO queue, Necko now attempts to sort the pool with connections with the largest congestion window (CWND) first. This can reduce the round-trip time (RTT) of HTTP transactions by avoiding the need to grow connections’ windows in many cases.
    • Firefox now handles the Content-Disposition HTTP response header more effectively if both the filename and filename* parameters are provided; it looks through all provided names, using the filename* parameter if one is available, even if a filename parameter is included first. Previously, the first matching parameter would be used, thereby preventing a more appropriate name from being used. See bug 588781 .

    MathML

    Developer tools

    • The Web Console’s Console object now has a debug() method, which is an alias for its log() method; this improves compatibility with certain existing sites.