1. Firefox Aurora: Playing With Upcoming Features is Now Safe

    Aurora Logo

    Firefox Aurora is a preview of the next version of Firefox, released every six weeks. It provides a safe way to play with the latest Web technologies the Mozilla team is working on.

    What is Aurora?

    Aurora is a new preview version that fits between the Nightly builds and Betas:

    • Firefox Nightly (firefox.com/channel) is released every day and includes the latest (potentially unstable) features and patches.
    • Firefox Aurora (firefox.com/channel) is released every six weeks and includes the newest features not known to cause problems.
    • Firefox Beta (firefox.com/channel) is released every six weeks and includes the features that are ready to be used and be tested by a large audience.

    Should I use Aurora?

    Amongst other things, Aurora already lets you play with CSS3 Animations and the new tabs management of Firefox. You can help us debug and test these features simply by installing Aurora from firefox.com/channel.

    Switching between channels

    Once you have downloaded and installed Aurora, you can switch to other channels at will. Simply click on the Help menu and open the About window.

    Aurora About window

    Update: The channel switcher will be removed from future versions of Aurora as explained by Johnathan Nightingale on the channels blog.

    Start using it right away and let us know what you think about it.

  2. Using client-side storage, today.

    I recently tried to store locally the content of a form to make it resilient to inadvertent tab closing and crashes. Here is what I learned about the different ways to achieve client-side storage.

    Cookies can crumble

    Cookies are not a valid storage mean, as their size is limited to roughly 4000 characters (4KB) and act as a ball and chain, slowing down the responsiveness of websites. localStorage on the other hand, has been designed for that exact purpose, but is not available in IE6, IE7 and Firefox3.

    store.js to the rescue

    The first task was thus to search for a fallback solution (or shim or polyfill) available in those older browsers. It turns out that store.js, by Marcus Westin (@marcuswestin), wraps localStorage and fallbacks together in a concise API, with a light file-size (2KB once minified and gzipped along with json2.js). Here is a short usage example:

    How does it work?

    On Firefox2 and Firefox 3, it uses the globalStorage API, and on IE6 and IE7 it falls back to userData behavior, which has two important limitations you should be aware of:

    • storage is limited to 128KB (vs. 5-10MB for localStorage), that’s still a lot of text,
    • storage is subject to a same folder policy, meaning that pages in different folders should not be able to access the same stored items.

    The second limitation can be really annoying, but it is possible to work around it by loading the code in an iframe. This trick will likely be integrated into Marcus’ own code.

    Although localStorage can only store strings, store.js uses the JSON API to make it possible to store Javascript objects and arrays as well.

    Crash proof forms

    With this script, I was able to build Persival, a simple jQuery plugin that can watch a form for changes and persist the values immediately:

    A more complex demonstration page features the form people face when they want to report a bug affecting Firefox (you’ll see that it’s actually not as hard as it seems). If you start to fill the form, then close the tab and click on the same link again you should see the magic happening. A simple but welcome improvement to the user experience, isn’t it?

    Chris Heilmann also demonstrated how client-side storage can be used to cache Web services data and maintain the state of a User Interface: localStorage and how to use it.

    Your turn

    Persival is young but already yours, feel free to use it, learn from it and improve it.

    Maybe there is a similar topic you would like to see covered in a next blog post? Let us know!

  3. How to resume a paused or broken file upload

    This is a guest post written by Simon Speich. Simon is a web developer, believer in web standards and a lover of Mozilla since Mozilla 0.8 (!).

    Today, Simon is experimenting with the File API and the new Slice() method introduced in Firefox 4. Here is how he implements a resume upload feature in a file uploader.

    Uploading a file is done with the XHR Level2 object. It provides different methods and events to handle the request (e.g., sending data and monitoring its progress) and to handle the response (e.g., checking if uploading was OK or an error occurred). For more information, read How to develop a HTML5 Image Uploader.

    Unfortunately, the XHR object does not provide a method to pause and resume an upload. But it is possible to implement that functionality by combining the new File API’s slice() method with the XHR’s abort() method. Let’s see how.

    Live demo

    You can check out the live fileUploader demo or download the JavaScript and PHP code from github.com.

    Pause and resume an upload

    The idea is to provide the user with a button to pause an upload in progress and to resume it again later. Pausing the request is simple. Just abort the request with the abort() method. Make sure your user interface doesn’t report this as an error.

    The harder part is resuming the upload, since the request was aborted and the connection closed. Instead of sending the whole file again, we use the blob’s mozSlice() method to first create a chunk containing the remaining part of the file. Then we create the new request, send the chunk, and append it to the part already saved on the server before the request was aborted.

    Creating a chunk

    The chunk can be created as:

    var chunk = file.mozSlice(start, end);

    All we need to know is where to start slicing, that is, the number of bytes that was already uploaded. The easiest way would be to save the ProgressEvent’s loaded property before we aborted the request. However, this number is not necessarily exactly the same as the number of bites written on the server. The most reliable approach is to send an additional request to fetch the size of the partially written file from the server before we upload again. Then this information can be used to slice the file and create the chunk.

    Summarizing the above chain of events

    (assuming an upload is already in progress):

    1. user pauses upload
    2. state of UI is set to paused
    3. uploading is aborted
    4. server stops writing file to disk
    5. user resumes upload
    6. state of UI is set to resuming
    7. get size of partially written file from server
    8. slice file into remaining part (chunk)
    9. upload chunk
    10. state of UI is set to uploading
    11. server appends data

    JavaScript code

    // Assuming that the request to fetch the already written bytes has just
    // taken place and xhr.result contains the response from the server.
    var start = xhr.result.numWrittenBytes;
    var chunk = file.mozSlice(start, file.size);
     
    var req = new XMLHttpRequest();
    req.open('post', 'fnc.php?fnc=resume', true);
     
    req.setRequestHeader("Cache-Control", "no-cache");
    req.setRequestHeader("X-Requested-With", "XMLHttpRequest");
    req.setRequestHeader("X-File-Name", file.name);
    req.setRequestHeader("X-File-Size", file.size);
     
    req.send(chunk);

    PHP code

    The only difference on the server side between handling a normal upload and a resumed upload is that in the latter case you need to append to your file instead of creating it.

    $headers = getallheaders();
    $protocol = $_SERVER[‘SERVER_PROTOCOL’];
    $fnc = isset($_GET['fnc']) ? $_GET['fnc'] : null;
    $file = new stdClass();
    $file->name = basename($headers['X-File-Name']));
    $file->size = $headers['X-File-Size']);
     
    // php://input bypasses the php.ini settings, so we have to limit the file size ourselves:
    $maxUpload = getBytes(ini_get('upload_max_filesize'));
    $maxPost = getBytes(ini_get('post_max_size'));
    $memoryLimit = getBytes(ini_get('memory_limit'));
    $limit = min($maxUpload, $maxPost, $memoryLimit);
    if ($headers['Content-Length'] > $limit) {
      header($protocol.' 403 Forbidden');
      exit('File size to big. Limit is '.$limit. ' bytes.');
    }
     
    $file->content = file_get_contents(’php://input’);
    $flag = ($fnc == ‘resume’ ? FILE_APPEND : 0);
    file_put_contents($file->name, $file->content, $flag);
     
    function getBytes($val) {
     
    $val = trim($val);
          $last = strtolower($val[strlen($val) - 1]);
          switch ($last) {
              case 'g': $val *= 1024;
     
    case 'm': $val *= 1024;
     
    case 'k': $val *= 1024;
          }
     
    return $val;
    }

    Caution!

    The PHP code example above does not do any security checks. A user can send and write any type of file to your disk or append to or even overwrite any of your files. So make sure you take the appropriate security measures when enabling uploading on your website.

    Resume upload after an error

    The sequence of events for pause-and-resume can also be used to continue uploading after a network error. Instead of trying to upload the whole file again, get the already written file size from the server and slice the file into a new chunk first.

    Note about resuming a paused or broken file upload

    Appending the chunk to the file might create a corrupted file, since you don’t have control over what the server writes after the request is aborted — if it writes anything at all.

    Resume upload after a browser crash

    You can take the pause-and-resume functionality even a step further. It is possible (at least in theory) to even recover uploading after an unexpected closing or crashing of the browser. The problem is that after the browser was closed, the file object, which was read into memory, is lost. The user would have to re-pick or drag over the file again first, before being able to slice the file to resume the upload.

    Instead, you could use the new IndexedDB API and store the file before any uploading is done. Then after a browser crash, load the file from the database, slice into the remaining chunk and resume the upload.

  4. Fun with new technologies at the Firefox 4 launch party in London

    For the Firefox 4 launch party in London, England we wanted to show off to the audience why it is such a big thing that we are moving leaps and bounds in the browser market. Here are the slides and notes explaining just how much fun we can have as developers these days if we use browsers to their capacity.

    The slides

    Detailed notes

    Currently there is a lot of confusion what HTML5 is – a lot of companies abuse the term for marketing of all kind of products and some of the demos showcasing HTML 5 don’t use it at all.

    Today I will promise not to try to sell you any operating system or hardware with it, I won’t show any comparisons between browsers (how many Goldfish they can show at the same time) and I promise not to go native (although that is the newest fad – calling HTML5 native).

    What HTML5 means to a large degree is that the web is the platform – more than ever. We used the web with web services and for storage for years but now we move towards a world where we deliver both data and the applications on it.

    The browser is the platform and is everything we need to help our end users fulfil the tasks they set out to do. Instead of having software packages for everything we just go to a web app and use this one. The browser offers us APIs and is fast enough nowadays to deliver great experiences. Webmail, collaborative document editing and image manipulation is just a first step in this direction.

    The information how to do all that is available for you for free. A lot of HTML5 resources are out there on the web with full documentation and examples of what can be done. The openness of web development makes it unnecessary to go to expensive corporate training courses or buy any software – all you need is a text editor and a browser.

    People are the key. If you look around you, you will find that the leading lights in the HTML5 world are not from one company or were known for years. Instead a lot of them come out of the woodwork totally unexpected which shows that this is much more about enthusiasm than about corporate backing.

    We have so many new toys as developers! If I had had all the technologies we can play with across browsers in the past, I am sure my career would have been twice as fast.

    Native HTML5 video and audio allows you to manipulate video in any which way and make it talk to the rest of the document. For example:

    The latter is very interesting as Canvas and SVG (which is not HTML5 but a “friends” technology) allows you to go very rich in the interface. Using Canvas and SVG you can also enhance data in the page to create beautiful visualisations.

    Another thing HTML5 offers are richer forms for the web including datepickers, sliders and autocomplete controls with in-built validation. This should safe us a lot of client side validation code that always gets out of sync and is hard to localise.

    Other technologies do very much add to what HTML5 gives us:

    Offline storage and local storage allows us to build applications that recognise the user’s connection state and keep them working whilst the connection is down.

    CSS3 is the natural progression of CSS and means that we don’t have to create gradients and rounded corners as graphics but can make them easy to change and maintain in our code itself.

    WebGL allows us to create 3D interfaces and animations in the browser. Google’s Body Browser is a great example of how rich that can get.

    All this becomes very powerful when you mix and match the technologies. You can clip, transform and run filters like blur over video content, you can simulate green screen in video+canvas, apply shape detection to video content or even detect nudity in photos.

    Give this technology to creative people and give them some time and beautiful things can happen. One example is Nike’s better world which looks and acts like a Flash interface but it clean HTML5. Other, ongoing examples of great use of HTML5 technology can be found at the Mozilla demo gallery.

    Don’t think this is not you! We need everyone to play with HTML5 to make it work and be used. So if you have a cool HTML5 demo, please send it to us so we can pimp it for you!

    The future of the web is a team effort and can and should not be in the hands of a chosen few following a corporate agenda, so please help us and join in! HTML5 is a debate and the more voices coming from different angles, the better the solution will be.

  5. Wiki Wednesday: April 6, 2011

    Here are today’s Wiki Wednesday articles! If you know about these topics, please try to find a few minutes to look over these articles that are marked as needing technical intervention and see if you can fix them up. You can do so either by logging into the wiki and editing the articles directly, or by emailing your notes, sample code, or feedback to mdnwiki@mozilla.org.

    Contributors to Wiki Wednesday will get recognition in next week’s Wiki Wednesday announcement. Thanks in advance for your help!

    JavaScript

    Thanks to BYK for contributing last week.

    SpiderMonkey

    Developing Mozilla

    Thanks to Neil Rashbrook for contributing last week.

    Extensions

    Thanks to John J. Barton and Ms2ger for contributing last week.

    XUL

    Thanks to John J. Barton and Ms2ger for contributing last week.

    XPCOM

    Thanks to Neil Rashbrook for contributing last week.

    Interfaces

    Plugins

    CSS

    Thanks to stopsatgreen and Florian Scholz for contributing last week.

    SVG

    Thanks to Jeremie Patonnier for contributing last week.

    HTML

    DOM

    Thanks to BYK for contributing last week.

  6. Wiki Wednesday: April 20, 2011

    Here are today’s Wiki Wednesday articles! If you know about these topics, please try to find a few minutes to look over these articles that are marked as needing technical intervention and see if you can fix them up. You can do so either by logging into the wiki and editing the articles directly, or by emailing your notes, sample code, or feedback to mdnwiki@mozilla.org.

    Contributors to Wiki Wednesday will get recognition in next week’s Wiki Wednesday announcement. Thanks in advance for your help!

    JavaScript

    Thanks to zhangpin04 for contributing last week.

    SpiderMonkey

    Thanks to pbiggar for contributing last week.

    Developing Mozilla

    Extensions

    XUL

    XPCOM

    Thanks to Neil Rashbrook for his contributions last week.

    Interfaces

    Thanks to Neil Rashbrook for contributing last week.

    Plugins

    CSS

    SVG

    HTML

    DOM

    Thanks to Nickolay for contributing last week.

  7. Accessibility and web innovation – a constant struggle

    I just came back from a small “accessibility tour” giving a talk about accessibility and web innovation in Stockholm, Sweden at Funkas Tillgänglighetsdagar and then in Paris at the W3Cafe meetup.

    In essence what I was musing about is that there is still a massive disconnect between accessibility and the development world. Accessibility is not seen as something that is cool and bleeding edge but as a necessary evil. If you ask about accessibility on developer mailing lists that juggle HTML5, Node.js, CSS3 and other cool technologies with ease you are very likely to hear that people are considering as an afterthought or make sure that “the interface degrades gracefully”.

    When you ask the accessibility world about cool new technologies you are very likely to hear that they may be interesting in a few years but are not ready yet and certainly will never be accessible in a legal sense.

    Having been positioned in between these two parties for a long time I am getting tired of this and I want the two fractions to move closer to each other.

    Accessibility is part of everything we do – the physical world has become much better in the last decades because we care for the needs of people with disabilities. Lowered kerbs on sidewalks, OCR Scanning, subtitles and captions on movies and TV programs – these are all things invented for a disability need but we all now benefit from it. The same can and should happen in interface design and web development. If you think about it, the features that make a good mobile interface also cover a lot of needs of different disability groups. So why don’t we work together?

    You can see the slides of the talk on Slideshare:

    You can get the slide deck on Slideshare:

    The audio of the talk is available at archive.org:

    There are also extensive notes on the talk available on my blog.

  8. Another successful MDN doc sprint

    While this weekend’s documentation sprint was smaller than the previous one, it represented significant steps toward achieving the goal of making Mozilla Developer Network a comprehensive, usable, and accurate resource for everyone developing for the web.

    • Eric Shepherd created and refined (and the rest of us began implementing) a format and related templates for browser compatibility tables for web technology reference pages. These tables will contain information about support for features in the major browsers, for both desktop and mobile platforms. Now the big task is to add the tables and browser support information to all of the many pages that need them.
    • In addition, Kang-Hao Lu created a template for indicating prefixed CSS properties, and used it in compatibility tables on several CSS property reference pages.
    • Collaboration with Google continued, with Kathy W updating the article on requestAnimationFrame with compatibility info for Chrome and Safari.
    • Jeremie Pationnier continued rocking the SVG reference, adding 17 new pages, improving several others, and adding the NeedsCompatTable tag to all of them.
    • Florian Scholz documented three more MathML elements, and added compatibility tables.
    • Trevor Hobson updated XUL elements and attributes to use templates for interface references.
    • David Bruant created compatibility tables and tested compatibility for JavaScript get and set operators.
    • Matheus Svolenski translated two more pages into Brazilian Portuguese.
    • Janet Swisher created a compatibility table for the HTML <input> element. The Firefox version information for the attributes and for values of the type attribute is now in this table rather than interspersed in the body of the page.

    Thanks to everyone who participated!

  9. MarbleRun, an HTML5 Game

    Take the HTML5 Canvas element, a Javascript library to do the physics (box2d), add a nice design, a social touch, and you have an awesome HTML5 Game called MarbleRun!

    MarbleRun was the winner of the last Mozilla Game On Challenge, among other exciting HTML5 games (check them out), and had been added to Web O’ Wonder.

    The authors of MarbleRun visited us a couple of weeks ago and gave the following talk about the story of their game:

  10. Wiki Wednesday: April 27, 2011

    Here are today’s Wiki Wednesday articles! If you know about these topics, please try to find a few minutes to look over these articles that are marked as needing technical intervention and see if you can fix them up. You can do so either by logging into the wiki and editing the articles directly, or by emailing your notes, sample code, or feedback to mdnwiki@mozilla.org.

    Contributors to Wiki Wednesday will get recognition in next week’s Wiki Wednesday announcement. Thanks in advance for your help!

    JavaScript

    Thanks to John J. Barton for contributing last week.

    SpiderMonkey

    Developing Mozilla

    Extensions

    XUL

    XPCOM

    Interfaces

    Thanks to Neil Rashbrook for contributing last week.

    Plugins

    CSS

    SVG

    HTML

    DOM