Mozilla

Articles

Sort by:

View:

  1. Creating a Multiplayer Game with TogetherJS and CreateJS

    Bubble Hell Duel is a multiplayer HTML5 dogfighting game. The object of the game is to dodge bubbles launched from your opponent while returning fire. This game was written mainly as a prototype for learning and the source code is available on GitHub. You can try the game out in single or multiplayer here. Currently the game does not contain any sound effects but uses CreateJS and TogetherJS.

    screenshot

    In this post I would like to share some of my experiences when developing the game. Please share your thoughts in the comments if you agree or have other suggestions.

    Game Engines

    When developing a 2d game you can write you own engine or make use of some fantastic libraries that are available. After spending a few days looking at the various options available I decided to use CreateJS. As I have some experience with Flash, CreateJS made sense for my needs as there was not much of a learning curve. I also wanted to make use of some Flash animations and CreateJS supported this feature. I will elaborate a bit more on animations later in the article.

    As I am a C++ developer I believe emscripten is also a good choice. It allows C/C++ code to be compiled to JavaScript, which can be executed in the browser. I am of the opinion that the static type checking and compile-time optimizations are great assets when developing large code bases. I have used emscripten before and it works very well, but for this project I wanted the fast and convenient prototyping capabilities of JavaScript. I also wanted to expand my JavaScript knowledge.

    I’d like to mention a few other libraries that seem very interesting: Cocos2d-x is making an emscripten port and they already support HTML5 binding. I also like pixi.js as it provides a webGL renderer but also supports Canvas fallback when the browser does not support webGL.

    C++ vs JavaScript

    At first I was a little bit worried about the performance of JavaScript, and that was the reason my decision between using CreateJS or emscripten was difficult. Fortunately a simple benchmark showed that a naive collision detection algorithm with about 400 balls on screen could still reach 40+ fps, which was enough for my simple experiment.

    As someone who has coded more in C++ than JavaScript I loved how quickly I could translate my thoughts into code and test them out on multiple browsers. On the other hand it was not very comfortable debugging my JavaScript. C++ compilers are quite good at pointing out misspellings and other mistakes that cause runtime issues. While the “use strict” directive and other mechanisms like closure compilers have their purpose they were not very helpful to me especially when variables became undefined. Rooting for the cause of errors can be somewhat difficult comparatively.

    As an example of difficult debugging, I encountered the following issue. I was using float numbers for coordinates and other geometric values like angles. These values were passed to the other player using the TogetherJS.send method for synchronization:

    var player = { x: 10.0, y: 10.0 };
    TogetherJS.send({type:'sync',x:player.x,y:player.y});
    TogetherJS.hub.on('sync', function(msg){
        enemy.x = msg.x;
        enemy.y = msg.y;
    });

    This worked, but lots of decimals were sent in this way, so I decided to relax the accuracy:

    TogetherJS.send({type:'sync', x:Math.round(player.x), y:Math.round(player.y) });

    Then I thought integers might not be accurate enough for collision detection, so I added more digits to the messages:

    TogetherJS.send({type:'sync', x:player.x.toFixed(2), y:player.y.toFixed(2) });

    While this seemed a reasonable solution, it actually induced a bug that was very hard to find and I did not notice it until I tested the game after implementing some more features. I noticed while playing the game the opponent would never move.

    It took me hours in debugging before I could locate the cause. I do not think I would have made this mistake using C++.

    If you would like to see this bug in action take a look at this jsFiddle project. Look at the three canvas tag outputs and you will notice the third canvas contains the bug. This issue occurs because toFixed returns a string representation.

    I am not sure using a closure compiler would have avoided this issue, but I did find in another project that it definitely helps with optimizations.

    Animation with Flash

    As with most games I wanted to use a good deal of animation. I was very familiar with creating animations in Flash and found that CreateJS supported several ways of consuming the Flash animations and presenting them in HTML5. CreateJS is a set of libraries and tools used to create interactive HTML5 content. So by using CreateJS I could consume my animations as well as use the other libraries available for loop handling, resource management and in the future, sound manipulation. For a quick introduction to CreateJS take a look at this video.

    CreateJS, which Mozilla now sponsors, offers great support for Flash animations.

    There are two ways of using Flash animations in HTML5 with CreateJS. The first option is to directly export the Flash animation in a way that you can access all the elements in their original form, including paths, transformations and tweens. The advantage to this approach is that it produces smaller files, and CreateJS allows you to transfer them into a sprite sheet on the client side, for faster rendering. Adobe Flash CS6 offers the CreateJS Toolkit plugin that allows the designer to export all the content of an animation to HTML5 files. This generally results in a JavaScript file with all the graphics and tweens, an HTML file, and a set of image files. You can open up the HTML document in your browser and see the animation.

    Another option is to export the animation into a sprite sheet, that is an image containing all the frames with a JavaScript file describing the position and size of each frame. These files can be easily integrated into HTML based games or applications via the SpriteSheet class in CreateJS. This is the approach I used for this game. To see the code where I use the SpriteSheet have a look at this link. If you want some more detail on this approach take a look at this video.

    I should also note that you can use a tool called Zoë to export directly to a sprite sheet or a JSON file from a Flash Animation as well.

    marisa

    The above image is an example of a sprite sheet that I use in the game and was generated as described above. The original image came from the game Touhou Hisouten ~ Scarlet Weather Rhapsody, which is availabe at http://www.spriters-resource.com.

    Multiplayer with TogetherJS

    On my first iteration of the code the game was not multiplayer. Originally it was a single-player bullet hell game, with a boss foe randomly moving across the screen. I could not last more than 30 seconds before succumbing to withering fire. It was interesting enough that I thought multiplayer would be exciting.

    I had heard of Together.js not long after it was released. The jsFiddle project is powered by Together.js and offers an impressive collaboration mode. This led me to using Together.js in my game. It is also very nice that Mozilla offers a default hub server simplifying the process of creating a multiplayer web based game. To learn more about Together.js be sure to check out this article.

    It was easy and comfortable integrating Together.js into my game, as it works like other event dispatcher/listeners frameworks.

    With Together.js, I was able to implement random match and invitation only multiplayer modes in the game. I did face a few design challenges that I had to overcome when designing the communication protocol.

    First off, I did not put code in to prevent cheating with two-party communications and assumed a certain level of trust between players. In the game design currently all collision detection of a player is done locally. Theoretically if you block corresponding messages you can mask that you have taken damage.

    Another area that I hacked a bit is that the bubbles of the enemy avatar are generated locally and randomly. This means that the bubbles seen from your character avatar are not necessarily the same as your opponent is seeing.

    In practice neither of these shortcuts should ruin the fun of the game.
    I did encounter a couple of issues or caveats with Together.JS.

    • I did not find a way to disable the cursor updating in Together.js. While this is useful in collaborative tools I did not need it in my game.
    • I am using Together.js in an asymmetric way, where both players see themselves as the red skirted Avatar (Reimu). This allows for easier placement of the player at the bottom of the screen and the opponent at the top. This also means that when you move the main player from an opponent’s view of the game your move is seen as the opponents move and vice versa.

    The Fun of Making Mistakes

    There are two visual effects in the game that came as unexpected surprises:

    • When a round finishes and the message ‘You Win’ or ‘You Lose’ appears, the time is frozen for a few seconds. This acts like a dramatic pause.
    • When a charge attack is released, the bullets are fixed and then gradually blown away toward the enemy.

    Neither of these effects was designed in this way. I didn’t want the pause and I wanted the bullets to continue rotating around the player upon releasing. However I made mistakes, and the result seemed to be much better than I had planned, so they made the final cut.

    Conclusion and Future Plans

    It is always fun learning new things. I like the fact that I could prototype and visualize pretty quickly. In the future I might add more patterns for the bullet curtains, and a few sound effects. In addition I will probably also draw more background images or possibly animate them.

    While developing the game I did realize in order to get a natural and intuitive feel required more effort than I expected. This is something I have always taken for granted while playing game.

    The code is open source, so feel free to fork and play. Be sure to comment if you have any suggestions for improving the game or the existing code.

  2. Developer Tools feedback channels, one week in

    Last week we launched Feedback channels, with the first one out on Developer Tools in Firefox. The feedback channel on UserVoice is the place to go for any ideas or thoughts about the Firefox Developer Tools.

    Looking at the first week for Developer Tools feedback

    During the first week for our Developer Tools feedback channel, we got:

    • 99 new ideas
    • 1382 votes
    • 4080 unique users

    Mozilla has responded to 97% of the ideas, out of which:

    Notable is that many ideas that came up are things that we already have bugs for in Bugzilla and ideas and approaches that have been talked about and considered.

    Thank you!

    So, sincerely, thank you for all the input and constructive ideas and comments! We appreciate it a lot and by having this direct dialog and communication with you, it helps us to build better and more useful Developer Tools!

    Please continue to express your ideas, vote on existing ones and stay on track with the progress!

  3. Reconciling Mozilla’s Mission and W3C EME

    May 19 Update: We’ve added an FAQ below the text of the original post to address some of the questions and comments Mozilla has received regarding EME.

    With most competing browsers and the content industry embracing the W3C EME specification, Mozilla has little choice but to implement EME as well so our users can continue to access all content they want to enjoy. Read on for some background on how we got here, and details of our implementation.

    Digital Rights Management (DRM) is a tricky issue. On the one hand content owners argue that they should have the technical ability to control how users share content in order to enforce copyright restrictions. On the other hand, the current generation of DRM is often overly burdensome for users and restricts users from lawful and reasonable use cases such as buying content on one device and trying to consume it on another.

    DRM and the Web are no strangers. Most desktop users have plugins such as Adobe Flash and Microsoft Silverlight installed. Both have contained DRM for many years, and websites traditionally use plugins to play restricted content.

    In 2013 Google and Microsoft partnered with a number of content providers including Netflix to propose a “built-in” DRM extension for the Web: the W3C Encrypted Media Extensions (EME).

    The W3C EME specification defines how to play back such content using the HTML5 <video> element, utilizing a Content Decryption Module (CDM) that implements DRM functionality directly in the Web stack. The W3C EME specification only describes the JavaScript APIs to access the CDM. The CDM itself is proprietary and is not specified in detail in the EME specification, which has been widely criticized by many, including Mozilla.

    Mozilla believes in an open Web that centers around the user and puts them in control of their online experience. Many traditional DRM schemes are challenging because they go against this principle and remove control from the user and yield it to the content industry. Instead of DRM schemes that limit how users can access content they purchased across devices we have long advocated for more modern approaches to managing content distribution such as watermarking. Watermarking works by tagging the media stream with the user’s identity. This discourages copyright infringement without interfering with lawful sharing of content, for example between different devices of the same user.

    Mozilla would have preferred to see the content industry move away from locking content to a specific device (so called node-locking), and worked to provide alternatives.

    Instead, this approach has now been enshrined in the W3C EME specification. With Google and Microsoft shipping W3C EME and content providers moving over their content from plugins to W3C EME Firefox users are at risk of not being able to access DRM restricted content (e.g. Netflix, Amazon Video, Hulu), which can make up more than 30% of the downstream traffic in North America.

    We have come to the point where Mozilla not implementing the W3C EME specification means that Firefox users have to switch to other browsers to watch content restricted by DRM.

    This makes it difficult for Mozilla to ignore the ongoing changes in the DRM landscape. Firefox should help users get access to the content they want to enjoy, even if Mozilla philosophically opposes the restrictions certain content owners attach to their content.

    As a result we have decided to implement the W3C EME specification in our products, starting with Firefox for Desktop. This is a difficult and uncomfortable step for us given our vision of a completely open Web, but it also gives us the opportunity to actually shape the DRM space and be an advocate for our users and their rights in this debate. The existing W3C EME systems Google and Microsoft are shipping are not open source and lack transparency for the user, two traits which we believe are essential to creating a trustworthy Web.

    The W3C EME specification uses a Content Decryption Module (CDM) to facilitate the playback of restricted content. Since the purpose of the CDM is to defy scrutiny and modification by the user, the CDM cannot be open source by design in the EME architecture. For security, privacy and transparency reasons this is deeply concerning.

    From the security perspective, for Mozilla it is essential that all code in the browser is open so that users and security researchers can see and audit the code. DRM systems explicitly rely on the source code not being available. In addition, DRM systems also often have unfavorable privacy properties. To lock content to the device DRM systems commonly use “fingerprinting” (collecting identifiable information about the user’s device) and with the poor transparency of proprietary native code it’s often hard to tell how much of this fingerprinting information is leaked to the server.

    We have designed an implementation of the W3C EME specification that satisfies the requirements of the content industry while attempting to give users as much control and transparency as possible. Due to the architecture of the W3C EME specification we are forced to utilize a proprietary closed-source CDM as well. Mozilla selected Adobe to supply this CDM for Firefox because Adobe has contracts with major content providers that will allow Firefox to play restricted content via the Adobe CDM.

    Firefox does not load this module directly. Instead, we wrap it into an open-source sandbox. In our implementation, the CDM will have no access to the user’s hard drive or the network. Instead, the sandbox will provide the CDM only with communication mechanism with Firefox for receiving encrypted data and for displaying the results.

    Traditionally, to implement node-locking DRM systems collect identifiable information about the user’s device and will refuse to play back the content if the content or the CDM are moved to a different device.

    By contrast, in Firefox the sandbox prohibits the CDM from fingerprinting the user’s device. Instead, the CDM asks the sandbox to supply a per-device unique identifier. This sandbox-generated unique identifier allows the CDM to bind content to a single device as the content industry insists on, but it does so without revealing additional information about the user or the user’s device. In addition, we vary this unique identifier per site (each site is presented a different device identifier) to make it more difficult to track users across sites with this identifier.

    Adobe and the content industry can audit our sandbox (as it is open source) to assure themselves that we respect the restrictions they are imposing on us and users, which includes the handling of unique identifiers, limiting the output to streaming and preventing users from saving the content. Mozilla will distribute the sandbox alongside Firefox, and we are working on deterministic builds that will allow developers to use a sandbox compiled on their own machine with the CDM as an alternative. As plugins today, the CDM itself will be distributed by Adobe and will not be included in Firefox. The browser will download the CDM from Adobe and activate it based on user consent.

    While we would much prefer a world and a Web without DRM, our users need it to access the content they want. Our integration with the Adobe CDM will let Firefox users access this content while trying to maximize transparency and user control within the limits of the restrictions imposed by the content industry.

    There is also a silver lining to the W3C EME specification becoming ubiquitous. With direct support for DRM we are eliminating a major use case of plugins on the Web, and in the near future this should allow us to retire plugins altogether. The Web has evolved to a comprehensive and performant technology platform and no longer depends on native code extensions through plugins.

    While the W3C EME-based DRM world is likely to stay with us for a while, we believe that eventually better systems such as watermarking will prevail, because they offer more convenience for the user, which is good for the user, but in the end also good for business. Mozilla will continue to advance technology and standards to help bring about this change.

    FAQ

    What did Mozilla announce?
    In a sentence: Mozilla is adding a new plug-in integration point to Firefox to allow an external DRM component from Adobe to supply the function of decrypting and decoding video data in a black box which is designed to make it difficult for the user to extract the decryption keys or the decrypted compressed data.

    A plug-in of this new type is called a Content Decryption Module (CDM) and is exposed to the Web via the Encrypted Media Extensions (EME) API proposed at the W3C by Google, Microsoft and Netflix (Here is a short technical explanation of EME). A CDM integrates with the HTML5 <video> and <audio> support provided by the Gecko engine instead of the <embed> or <object> elements that third parties have historically used to enable playback for video wrapped in DRM to Firefox, via software such as Adobe Flash Player and Microsoft Silverlight. We have formed a relationship with Adobe, who will distribute to end users a Firefox-compatible CDM implementing the Adobe Access DRM scheme, and Firefox will facilitate the download and installation of that CDM. Streaming services requiring DRM and implementing the EME-compatible version of Adobe Access should thereby, if they choose to, be able to stream media to Firefox Desktop users on Windows, Mac or Linux.

    Does this mean Mozilla is adding DRM to Firefox?
    No. Mozilla is providing a new integration point for third-party DRM that works with Firefox. Third-party DRM that works with Firefox is not new. Firefox (and every other browser) already provides another integration point for third parties to ship DRM: the Netscape Plugin API (NPAPI), which has been part of web browsers since 1995. What’s new is the ability of the third-party DRM to integrate with the HTML <video> element and its APIs when previously third-party DRM instead integrated with the <embed> and <object> elements. When integrating with <video>, the capabilities of the DRM component are more limited, and the browser has control over the style and accessibility of the playing video.

    Firefox, as shipped by Mozilla, will continue to be Free Software / Open Source Software.

    Why is Mozilla adding a new DRM integration point when the NPAPI already exists?
    NPAPI plug-ins come with much more than just DRM. In addition to the Adobe Access DRM component, Adobe Flash Player comes with an entire ActionScript runtime, a broad set of APIs, a graphics stack, a media stack and a networking stack. Likewise, in addition to the PlayReady DRM component, Microsoft Silverlight comes with a CLI virtual machine, a broad set of APIs, a graphics stack, a media stack and a networking stack. Driven in major part by Mozilla, the Open Web Platform is growing to match almost all the functionality that Adobe Flash Player or Microsoft Silverlight provide—with one big exception being DRM, which is necessarily non-open. The use of NPAPI plug-ins in most other situations is not as sustainable as it once was. As plugin owners start to migrate from supporting their plugins (for example, Microsoft appears to be ending Silverlight support and Adobe has discontinued Flash for Android), Firefox cannot continue to rely on NPAPI plug-ins for providing video DRM (and thereby allow users to watch movies from major Hollywood studios).

    The new CDM integration point is a much more focused plug-in API than the NPAPI. It permits a third-party component to provide the one function that an Open Source implementation of the Open Web Platform cannot provide to Hollywood’s satisfaction: decrypting and decoding video while aiming to make it very difficult for the end-user to tamper with the process. The browser’s media stack and the associated HTML5 APIs can be used for everything else. Since a CDM has less functionality than NPAPI plug-ins, it is easier to sandbox a CDM and easier to port it to new platforms.

    Why isn’t DRM dying together with NPAPI plug-ins?
    Mozilla’s competitors don’t appear to be letting DRM die together with NPAPI (or ActiveX) plug-ins. In fact, the Encrypted Media Extensions API was developed by Microsoft, Google and Netflix and Microsoft and Google have already implemented EME in their respective browsers.

    Netflix operates a massively popular (where available) online service that allows end-users to watch movies from major Hollywood studios and they are already serving content to Internet Explorer and Chrome OS using EME with Microsoft’s and Google’s own DRM schemes (PlayReady and Widevine).

    If Mozilla didn’t enable the possibility of installing the Adobe Access CDM for use with EME, we’d be in a situation similar to the one we were in when we did not support the H.264 codec in HTML5 video. Instead of moving away from H.264, Web sites still delivered H.264 video to Firefox users—but did it via the NPAPI using Adobe Flash Player or Microsoft Silverlight rather than via the <video> tag.

    Similarly, if Mozilla didn’t enable the use of a Hollywood-approved DRM scheme with HTML5 video using EME, Firefox users would need to continue using Flash, Silverlight or another NPAPI plugin to view Hollywood movies on Windows and Mac. As noted in the previous answer, the long-term future of that capability is in doubt, and the experience (both in terms of installation and in terms of performance) would be worse than the experience in Chrome and IE with their bundled EME CDMs. On other operating systems, Firefox users would be locked out of viewing Hollywood movies (as is the case today), but other browsers, for example Chrome on Linux and Android, would be in a position to support them.

    The ability to watch movies from major Hollywood studios is a feature users value. Netflix alone accounts for fully 1/3 of bandwidth usage in North America during the evening peak time. We expect that many users around the world would switch browsers in pursuit of this ability, or of a better experience, if Firefox provided either no experience or a worse experience (depending on operating system).

    How will Firefox facilitate the installation of the Adobe Access CDM?
    The user experience for EME in Firefox is still being considered. Users will have choice whether to enable use of the CDM.

    What does this mean for interoperability of the EME specification?
    The Adobe Access CDM as used with Firefox will support ISO Common Encryption (CENC). This is a way of encrypting individual tracks within an MP4 container using 128-bit AES-CTR such that the MP4 file declares the key identifiers for the AES keys needed for decryption but doesn’t contain the keys themselves. It is then up to the CDM to request the AES keys by ID from a key server that knows how to talk with the CDM. (The communication between the CDM and the key server is mediated through the EME API and a JavaScript program that can relay the EME messages to the key server over XMLHttpRequest.)

    It follows that a site can serve the same MP4/CENC files and the same JavaScript program to different browsers that have CDMs for different DRM schemes, as long as the site runs a distinct key server for each DRM scheme, since each DRM scheme has its format for the EME-mediated messages between the CDM and the key server.

    So there is expected to be interoperability on the level of media files and on the level of JS code served to different browsers, but CDMs from different vendors are expected to acquire keys using mutually incompatible protocols. (The EME API sees byte buffers whose contents are opaque to EME.)

    Whether EME+CENC is an interoperability improvement depends on what you compare it to. When a content provider operates a full array of key servers for the various DRM schemes that different players may support, it will be an interoperability improvement compared to video delivered via Adobe Flash Player or Microsoft Silverlight, or via apps written for a small set of specific mobile platforms. However, if a content provider doesn’t operate a full array of key servers and caters only to a subset of the EME-relevant DRM schemes, interoperability may not be as good as that provided by current plug-ins. And no DRM scheme can provide the full interoperability benefits of DRM-less HTML5 video.

    Won’t having to support multiple key servers with mutually incompatible DRM protocols (in order to get cross-browser support) make Web publishing prohibitively expensive for independent publishers?
    DRM is a requirement imposed by the major studios onto services that license movies from them. Independent video publishers can avoid the cost of DRM by not imposing a DRM requirement on themselves.

    Which streaming services will be supported?
    This is a new agreement with Adobe and it’s too early to be certain exactly which streaming services will support it.

    Since the Adobe Access CDM contains an H.264 decoder, does this mean that the decoder can be used for non-DRM content?
    Yes. The CDM component could also be used to provide non-DRMed H.264 and/or AAC support in the <video> tag. It is not yet determined for certain where, when and if this capability will be used—that depends on the availability of other options (such as OpenH264).

    The market conditions regarding the need for H.264 support in the browser have not changed significantly since Mozilla made the decision in 2012 to provide support for it (via OS libraries or third party software). Mozilla continues to believe that patent un-encumbered codecs are best for the web, and encourages video producers to use open codecs (WebM for example) without the use of DRM.

    What does this mean for downstream users of the Firefox code base?
    The solution consists of three parts: the browser, the CDM host and the CDM.

    The CDM host is an executable distinct from the browser that communicates with the browser using an inter-process communication (IPC) mechanism. The CDM is a shared library loaded by the CDM host. The CDM host drops privileges, such as disk and network access, before calling into the CDM.

    Mozilla will develop the CDM host and is planning on making its code open source as is the norm for Mozilla-developed code. However, the CDM will refuse to work if it finds itself in a host that isn’t identical to the Mozilla-shipped CDM host executable. In other words, downstream recipients of the source code for the CDM host won’t be able to exercise the freedom to modify the CDM host without rendering it useless (unless they also make arrangements with Adobe).

    This leaves downstream users of the Firefox code base with the following options:

    1. Not supporting the Adobe Access CDM.
    2. Distributing their own browser build that retains Firefox’s IPC behavior and distributing a copy of Mozilla’s CDM host executable.
    3. Distributing their own browser build that retains Firefox’s IPC behavior and distributing a self-built CDM host executable that is bit-identical to Mozilla’s CDM host executable. (I.e. this requires doing the work to achieve deterministic builds for the CDM host.)
    4. Making arrangements directly with Adobe to get a non-Mozilla CDM host executable recognized by the CDM.

    Do I have to run proprietary software in order to use Firefox?
    No. The Adobe Access CDM is entirely optional. However, we expect Hollywood studios, via their video streaming partners, to deny you access to view their content using the <video> tag if you choose not to use it.

    Does this mean applying DRM to HTML?
    No, this is about enabling DRM to be applied to video and audio tracks when played using HTML facilities. The DRM doesn’t apply to the HTML document that contains the video or audio element, to page images, or anything else other than video and audio tracks. There are no plans to support DRM for captioning data, for example. Mozilla strongly opposes any future expansion in scope of the W3C EME specification.

    Why is DRM supported for the <audio> element?
    “Audio” is a subset of “video with audio,” so if we restricted DRM to the <video> element, those who wished to use DRM with audio would just use a “video-less video.”

    Also, even though record labels gave up on DRM for music files which are sold to users, they still require DRM for music subscription services (that is, services where the user loses the ability to play the music upon terminating the subscription). Support for EME in the <audio> element helps move those services move off NPAPI plug-ins.

  4. Introducing TranslationTester and localization support for Open Web Apps

    When building Open Web Apps, one important factor is to make your content available to as many possible, and one way to do that is to make it available in more than one language. Therefore we want to make it as easy as possible for you, both with a complete code repository to get started and updated documentation and possibilities to get translations for your apps.

    We are now also offering a way to have your app set up and to get connected to localizers directly!

    Presenting TranslationTester

    Based on the great work and content by Jason in Localizing Firefox OS Apps and Christie in Localizing the Firefox OS Boilerplate App, I’ve been working on simplifying the set-up for localization.

    Above articles describe many facets and possibilities available, and to complement that, I wanted to be able to offer the most basic code and structure for most use cases: basically, just add translations and you’re good to go!

    This lead to the creation of the TranslationTester code repository, available on GitHub.

    From no translation to localized app in less than 4 minutes!

    Based on the TranslationTester, Will Bamberg has put together a nice and short screencast showing the exact process of going from no translations to having support in just a few minutes!

    In the app-l10n-example repository you have versions of the before and after stages in this screencast, and all of the localization process is described on MDN.

    How to localize an app

    These are the things needed to localize an app. All of them are included in the TranslationTester repository, but included here to show easy it is to get started, or continue to build on the TranslationTester platform for your app.

    Mark up the HTML

    For any element that you want to have its text localized, add a data-l10n-id attribute to the desired element. For example:

    <p data-l10n-id="winter-for-real">Winter for real</p>

    Create translations

    In the locales directory, you have a directory for each language, and can just add new ones for new languages. In each language directoy you create an app.properties file which will contain all your translations for that language (optionally you can also create a manifest.properties file for the name and description of the app, unless you edit it in the main manifest.webapp for your app).

    Include l10n.js

    By including the l10n.js file, the translations for respective language’s app.properties file will be applied to element with the corresponding data-l10n-id attribute.

    Add “name” and “description” translations

    The translations for the name and description for your app could be added to the main manifest.webapp file, or in an optional manifest.properties under each locale’s directory.

    How to view different locales

    To view your app with a different locale, change the language in Firefox/App Manager:

    All platforms
    Set the desired locale to test in JavaScript, e.g:

    document.webL10n.setLanguage("es");
    App Manager/Firefox OS
    Language setting in the Settings app
    Firefox
    Choose language under Preferences > Content > Languages. More information in Set content language in Firefox

    Get help with translations

    We have a Mozilla localization app pilot offered through the Transifex service. As part of that, we’re offering you to add your apps as part of this pilot, to be connected to localizers and quickly offer your app in more languages, to more people.

    Please apply in the Localize My Firefox App form to get started!

  5. How fast is PDF.js?

    Hi, my name is Thorben and I work at Opera Software in Oslo, not at Mozilla. So, how did I end up writing for Mozilla Hacks? Maybe you know that there is no default PDF viewer in the Opera Browser, something we would like to change. But how to include one? Buy it from Adobe or Foxit? Start our own?

    Introducing PDF.js

    While investigating our options we quickly stumbled upon PDF.js. The project aims to create a full-featured PDF viewer in the browser using JavaScript and Canvas. Yeah, it sounds a bit crazy, but it makes sense: browsers need to be good at processing text, images, fonts, and vector graphics — exactly the things a PDF viewer has to be good at. The draw commands in PDFs are a subset of Postscript, and they are not so different from what Canvas offers. Also security is virtually no issue: using PDF.js is as secure as opening any other website.

    Working on PDF.js

    So Christian Krebs, Mathieu Henri and myself began looking at PDF.js in more detail and were impressed: it’s well designed, seems fast and big parts of the code are just wow!

    But we also discovered some problems, mainly with performance on very large or graphics-heavy PDFs. We decided that the best way to get to know PDF.js better and to push the project further, was to help the project and address the major issues we found. This gave us a pretty good understanding of the project and its high potential. We were also very impressed by how much the performance of PDF.js improved while we worked on it. This is an active and well managed project.

    Benchmarking PDF.js

    Of course, our tests gave us the wrong impression about performance. We tried to find super large, awkward and hard-to-render PDFs, but that is not what most people want to view. Most PDFs you actually want to view in PDF.js are fine. But how to test that?

    Well, you could check the most popular PDFs on the Internet – as these are the ones you probably want to view – and benchmark them. A snapshot of 5 to 10k PDFs should be enough … but how do you get them?

    I figured that search engines would be my friend. If you tell them to search for PDFs only, they give you the most relevant PDFs for that keyword, which in turn are probably the most popular ones. And if you use the most searched keywords you end up with a good approximation.

    Benchmarking that many PDFs is a big task. So I got myself a small cluster of old computers and built a nice server application that supplied them with tasks. The current repository has almost 7000 PDFs and benchmarking one version of PDF.js takes around eight hours.

    The results

    Let’s skip to the interesting part with the pretty pictures. This graph

    histogram

    gives us almost all the interesting results at one look. You see a histogram of the time it took to process all the pages in the PDFs in relation to the average time it takes to process the average page of the Tracemonkey Paper (the default PDF you see when opening PDF.js). The User Experience when viewing the Tracemonkey Paper is good and from my tests even 3 to 4 times slower is still okay. That means from all benchmarked pages over 96% (exclude pdfs that crashed) will translate to a good user experience. That is really good news! Or to use a very simple pie chart (in % of pages):

    overview

    You probably already noticed the small catch: around 0.8% of the PDFs crashed PDF.js when we tested them. We had a closer look at most of them and at least a third are actually so heavily damaged that probably no PDF viewer could ever display them.

    And this leads us to another good point: we have to keep in mind that these results just stand here without comparison. There are some PDFs on the Internet that are so complex that there is no hope that even native PDF viewers could display them nice and fast. The slowest tested PDF is an incredibly detailed vector map of the public transport system of Lisbon. Try to open it in Adobe Reader, it’s not fun!

    Conclusion

    From these results we concluded that PDF.js is a very valid candidate to be used as the default PDF viewer in the Opera Browser. There is still a lot of work to do to integrate PDF.js nicely into it, but we are working right now on integrating it behind an experimental flag (BTW: There is an extension that adds PDF.js with the default Mozilla viewer. The “nice” integration I am talking about would be deeper and include a brand new viewer). Thanks Mozilla! We are looking forward to working on PDF.js together with you guys!

    PS: Both the code of the computational system and the results are publicly available. Have a look and tell us if you find them useful!

    PPS: If anybody works at a big search engine company and could give me a list with the actual 10k most used PDFs, that would be awesome :)

    Appendix: What’s next?

    The corpus and the computational framework I described, could be used to do all kinds of interesting things. In the next step, we hope to classify PDFs by used fonts formats, image formats and the like. So you can quickly get PDFs to test a new feature with. We also want to look at which drawing instructions are used with which frequency in the Postscript so we can better optimise for the very common ones, like we did with HTML in browsers. Let’s see what we can actually do ;)

  6. Editable box model, multiple selection, Sublime Text keys + much more – Firefox Developer Tools Episode 31

    A new set of the Firefox Developer Tools features has just been uplifted to the Aurora channel. These features are available right now in Aurora, and will be in the Firefox 31 release in July. This release brings new tools, editor improvements, console and inspector features:

    Editable box model

    The Box Model tab in the Inspector is now editable for easy experimentation. Double-click any of the margin, border, or padding values to change its value for the currently selected element. Enter any valid CSS <length> value and use the Up/Down keys to increment or decrement the value by 1. Alt-Up increments by 0.1 and Shift-Up increments by 10. (development notes)

    Editing the box model

    Eyedropper

    New to the color picker in the Inspector is an Eyedropper tool that grabs the color from any pixel on the page. Select the current color by clicking or pressing Enter. Abort the operation by pressing Esc. Use the Up/Down keys to move by one pixel, and Shift-Up/Shift-Down to move by 10 pixels.

    Eyedropper tool

    You can also use the eyedropper directly to copy a color to the clipboard by accessing it from Web Developer menu, or the toolbar icon that’s enabled by going to the settings panel and checking Available Toolbox Buttons > Grab a color from the page. (development notes)

    Console stack traces

    console.error, console.exception, and console.assert logs in the console now include the full stack from where the call was made. (development notes)

    Stack trace in console.error() printout

    Styled console logs

    On parity with other browser developer tools, you can now add style to console logging with the %c directive.
    (development notes)

    Using %c in console.log() to format output

    Copy as cURL

    Replay any network request in the Network Monitor from the comfort of your own terminal. Right-click a request and select the copy as cURL menu item to copy a cURL command to the clipboard, including arguments for headers and data. (development notes)

    Copy as cURL in Network tool

    Editor – multiple selection, Sublime Text keys

    The source editor used in the developer tools has been upgraded to CodeMirror 4. With that brings:

  7. Multiple selection. Hold down Ctrl/Cmd while selecting to get multiple selections.
  8. Rectangle selection. Hold down Alt to select a column-aligned block of text.
  9. Undo selection. Undo the last selection action with Ctrl-U/Cmd-U and redo with Alt-U/Shift-Cmd-U.
  10. Sublime Text keybindings. To enable, go to about:config in the url bar and set devtools.editor.keymap to sublime.
  11. Multiple selection in action:

    animation of multiple selection in the editor

    development notes

    Canvas Debugger

    Debug animation frames in WebGL and 2d canvas contexts with the newly-landed canvas debugger. The canvas debugger is an experimental feature that has to be enabled in the setting panel. Multiple canvases are not yet supported (bug) as well as animations generated with setInterval (bug). The canvas debugger is described in more in this blog post.
    (development notes)

    Add-on Debugger

    If you develop Firefox add-ons using the Add-on SDK, there’s now a much easier way to debug your add-on’s JavaScript modules. See the blog post for more details. (development notes)

    Firefox 31: Add-on Debugger from Jordan Santell on Vimeo.

    Other features

    • Expand descendants. Hold Alt while double-clicking a node in the Inspector to expand all of its children and descendants. (development notes)
    • Persist network logs. Check Enable persistent logs in the settings panel to keep Network panel logs across reloads and navigations. (development notes)
    • JS warnings on by default. JavaScript warnings now show up in the Console by default. (development notes)
    • Scratchpad View menu. The Scratchpad tool now has a View menu with options for changing font size, hiding line numbers, wrapping text, and highlighting trailing spaces. (development notes)

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

    Questions or suggestions? Comment here or shoot feedback to @FirefoxDevTools on Twitter or our brand new feedback channel for Firefox Developer Tools. If you’d like to help out, check out the guide to getting involved.

  12. Launching feedback channels – let us know your ideas for Firefox Developer Tools

    One thing that is vital for us at Mozilla is to listen to developers and users, and care to your needs to make the web a better place. We’re strong believers in constructive communication and discussions, and that’s why I’m happy to announce our latest initiative! Feedback channels for developers.

    We’ve been looking into various ways to make it as easy as possible for developers to express their thoughts and opinions on a number of topics, and also for how we at Mozilla can be as transparent as possible around the projects we work on.

    Making the web a better place isn’t only about trying to figure out what’s right – it’s about listening to people, gather their thoughts and ideas and let that help us in achieving better results.

    Introducing UserVoice

    With that in mind, we’ve been evaluating third party services available as well as our own projects such as Mozilla Support and Firefox Input.

    For this specific use case and to match our requirements, we’ve decided to do it through the UserVoice service. We want to make it dead simple for you to enter ideas and vote for existing ones, both through an easy and intuitive user interface but also with requiring no account registration.

    Currently all you need to do know is enter a name and an e-mail address and you’re good to go! You will also have 10 votes dedicated to your e-mail address/account, which you can dispose as you seem fit for other ideas there.

    Naturally, if we see an abuse of this simplicity, we will have to add an element of moderation to process. We sincerely hope that won’t be needed, though, and that you will act and write respectfully.

    First project: Firefox Developer Tools

    The first project out the door that we will have a feedback channel for is the Developer Tools in Firefox. We have made great great progress with the Developer Tools over the last year – outlined in more detail in Dev Tools articles here on Hacks and the extensive documentation on MDN – but we want to hear the ideas you have to make them even better, what’s important to you, what could be a game changer and much more.

    People from the Developer Tools team will interact directly with you in this feedback channel, giving you a unique opportunity to influence and inspire us, resulting in a better product for you.

    A first test

    This try with UserVoice and feedback channels is our first attempt at this, with the ambition to be able to listen to your thoughts and ideas, and utilize that to make sure we focus on the most important areas.

    If we see that we can make a difference with this initiative and that you appreciate the direct contact and transparency, we will do our best to keep this going and to introduce channels for more topics in the future!

    Will you automatically implement the feature with the highest votes?

    Not automatically. The voting and ideas will help us see what you truly care about and interact with you around those, but we will also need to compare developing time and resources vs. the possible gain we see for a certain feature.

    It will however be of immense help for us weighing ideas, features and items in the roadmap against each other, and a helpful tool for prioritizing our work.

    Working with UserVoice

    Here are the most common things you can do at UserVoice – what they are and what they look like.

    Viewing ideas

    You can easily view a list of ideas, the number of votes they’ve gotten, current state (e.g. Started, Under Review), click the link to see comments and more.

    You also have a quick navigation to sort the listing based on what’s Hot, Top ideas, New or their current status. You can also list them based on your feedback or comments as well.

    Enter an idea

    To enter an idea, simply type the idea in the text box at the top:

    When you start typing, you will get suggestions for existing ideas that might match your topic, highlighting the word(s)in question. Please make sure to vote for existing ideas instead of creating duplicate ones.

    Search existing ideas

    In the right-hand side of the web site, you can also quickly search through existing topics and ideas, and see both matches and their current state.

    Official comment from Mozilla

    It also gives us the possibility to give you a reply to the state of the current feature. Whether it’s already in there, planned or if there’s something that’s not currently on our roadmap.

    Complement to Bugzilla and Stack Overflow

    At Mozilla, we use Bugzilla for tracking bugs and Stack Overflow for developer support. Our feedback channels at UserVoice are intended for conversations, constructive feedback and transparency around what we work on. Therefore, for reporting bugs or getting support for a product or challenge:

    Help us help you

    We really hope you will like this opportunity to have a discussion with us and be able to influence our thinking and work! If this works out well, we’d be glad to take it to other areas as well.

    So help us help you! Let’s work together to make a better web with better products for developing for it.

    Go to our Developer Tools feedback channel and get started!

  13. asm.js performance improvements in the latest version of Firefox make games fly!

    The latest version of Firefox which launched last week includes a major update to the user interface as well as to features like Sync. Another area in which this release brings significant improvements is in asm.js performance, which as we will see below is very important for things like games. To put that aspect of Firefox’s performance in context, we’ll take a look at benchmark results comparing Firefox to other browsers, which show that Firefox is faster at executing asm.js code.

    asm.js speedups

    asm.js is a subset of JavaScript that is very easy to optimize and is particularly useful for porting code in C or C++ to the Web. We’ve blogged about how Firefox can optimize asm.js code using 32-bit floating point operations, which, together with all the other work on optimizing asm.js, allows it to run at around 1.5x slower than the speed of the same C/C++ when compiled natively. So, while not quite native speed yet, things are getting very close. At the time of that blog post those optimizations were only on nightly builds, but they are now reaching hundreds of millions of Firefox users in Firefox 29, which is now the release version of Firefox.

    Another important set of asm.js optimizations concern startup speed. As blogged about by Luke a few months ago, Firefox performs ahead of time (AOT) compilation and can cache the results, for significant speedups in startup times. Those optimizations also shipped to users in Firefox 29.

    Web browser comparisons

    Now that all those optimizations have shipped, it’s interesting to look at up-to-date browser comparisons on asm.js code. The above graph shows the Emscripten benchmark suite running the latest stable versions of Google Chrome, Internet Explorer and Firefox on Windows 8.1. Lower numbers are better in all the results here, which are real-world codebases compiled to asm.js (see notes in the graph).

    Unity, Emscripten and asm.js

    asm.js is a subset of JavaScript, so it is just one of many styles of JavaScript out there. But it represents an important use case. As we announced at GDC, Unity, one of the most popular game creation tools on the market, will support the Web by using Emscripten to compile their engine to asm.js.

    But videos are no substitute for the real thing! You can try the games shown there in your browser right now, with Unity’s recently released Dead Trigger 2 and Angry Bots demos. If you run those in the latest version of Firefox, you’ll see many of the asm.js optimizations mentioned earlier in action. For example, if you visit one of those links more than once then asm.js caching will allow it to avoid recompiling the game (so it starts up faster), and also gameplay will be smoother due to faster asm.js execution.

    Being able to execute asm.js-style code efficiently makes it possible for games like this to run well on the Web, without proprietary, nonstandard plugins. That’s why it’s exciting to see more asm.js optimizations reach Firefox users in Firefox 29. And while benchmark results can sometimes seem like nothing more than abstract numbers, speedups on asm.js benchmarks directly improve things like games, where performance is extremely important and very noticeable.

    (Thanks to Marc Schifer for helping with the benchmark measurements.)

  14. Mozilla hits one million bugs – thanks for making the Web better with us

    We passed a significant milestone on Wednesday. Mozilla’s installation of the Bugzilla bug-tracking software reached the landmark of bug number 1,000,000.

    Our Bugzilla installation has been running since Mozilla started in 1998, and tracked bugs, issues, enhancement requests, work projects and almost any other kind of task, across the whole breadth of Mozilla. There are over a thousand other projects and companies that use Bugzilla, including Yahoo! and Red Hat. At Mozilla, anyone who gets an account can file a bug – that’s part of what it means to be an open, transparent and participatory project. Some of the people who filed the earliest bugs are still involved in the project today, and have amassed quite astounding bug-filing counts. Most of the bugs are now resolved, one way or another, and it’s probably fitting that the oldest open one is a request for an enhancement to Bugzilla itself.

    So thanks to all those who have filed, triaged, processed or fixed bugs in our Bugzilla installation over the years, and to all those who have hacked on the software. (Bugzilla the project is very much alive and used widely across the industry; if you want to help, here’s how.) Bugzilla has been an essential tool in making our software as great as it is, and we couldn’t have done it without you.

    Here’s to the next 1,000,000!

  15. Take the Developer Economics 7th Global Survey

    I’ve always preferred to think of myself as anything but a Marketer. In business school, there was a clear hierarchy assigned to the functional classifications amongst us. At the very top sat the investment bankers, commanding the most respect and highest paying job offers. And always at the very bottom the Marketing folks groveled, earning less and often viewed by their peers as having a “softer,” less competitive skillset.

    However much I disagreed with this classification — knowing that the digital age has made modern day marketing every bit as analytical and numbers-intensive as corporate financing jobs — it didn’t change the fact that I didn’t want to be called a Marketing person anyway. With the success of the Mad Men series and the constant headlines about privacy invasion and digital media, it seemed impossible to completely shake the Marketing job function from the stereotype of scumbag executives on Madison Avenue, or even a dirty car salesman whose only real skill is the ability to smoothly tell lies.

    In corporate America, no matter what job function you’re in, you’re all there for the same purpose – to drive profits (also referred to by business-schoolers as “maximizing shareholder value”). But the Marketing folks are more directly involved with sales metrics, and so the stereotypes live on. But being a Marketer at Mozilla is different. As a non-profit, mission oriented company, we’re not trying to sell you anything at all. Our only goal is to provide greater value – to our developers, our users, our community, and the world.

    As a Developer (un)Marketer, my job is to make you successful. Does this mean I’m never going to try to get you to do anything? Or could this mean I’m ready to be embrace the Marketing title? Okay, no on both counts. But it does mean that when I ask you to do something, I’m really asking just so I can, in the end, help you.

    Take the Survey

    Surprise – the Marketer that won’t call herself a Marketer writes her first blog post asking you to do something. Mozilla has teamed up with research company VisionMobile to get the latest, most accurate facts and insights surrounding the mobile app economy and developer ecosystem. We need this to make sure we’re prioritizing our efforts to provide you with the tools and resources that help you the most. The research relies heavily on developer surveys, and we want to ensure we get a representative sample of Firefox OS and HTML5 developers around the world. We also need this sample to be large enough to for the data to be statistically significant.

    If you’re an HTML5 or Firefox OS developer, we’d love you to participate in this 10-minute survey for their research report on Developer Economics. This report provides a comprehensive analysis of the app economy and developer ecosystems based on the largest and most global developer surveys. The results of the survey will be available as a free download in July, plus I’ll be back to talk about some of the best challenges and opportunities for developers based on insights from the full report.

    The survey will run until May 9th, and there is also a lucky draw for survey respondents to win prizes! Please help us generate the best research possible with your participation. And please comment or tweet us (@mozhacks) with any thoughts or ideas on the survey questions!

    Survey Methodology

    The research in VisionMobile’s Developer Economics report is based on survey responses from its global developer survey, in addition to one-to-one interviews with mobile app developers. The developer survey is entirely administered online. Respondents for the 5th edition of Developer Economics came from 115+ different countries, led by the US (18.7%), India (13.9%), and the UK (5.9%), followed by Russia, Germany, and France. This is outlined in more detail in Developer Economics: Methodology.

    About the Survey

    Developer Economics is a semi-annual report series published by VisonMobile, providing benchmarking of developer attitudes, trends and monetization by region. The report is now the largest and most global research available on the apps economy, surveying over 6.000 developers worldwide. You can also download a free copy of the 5th Edition (Q3 2013) of the report.

    About VisionMobile

    A leading research firm in the app economy and mobile business models, VisionMobile’s team includes PhDs, MBAs, economists and engineers that analyze the strategies behind the world’s most successful technology companies. Visit their website to learn more.