Mozilla Hacks

Firefox 4 Beta: Latest update is here — what’s in it for web developers?

By Paul Rouget

Posted on September 7, 2010 in Firefox

The latest Firefox 4 Beta has just been released. Here is a quick overview of the new features for web developers.

David’s Audio API demo:

(try the audio demo )

Myself about Hardware acceleration:

(try the hardware acceleration demo )

We need help!

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

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.

About Paul Rouget

Paul is a Firefox developer.

More articles by Paul Rouget…

10 comments

  1. Ryan

    Nice work on the HTML5 forms chapter additions. One question, correct me if I’m wrong, an invalid form shouldn’t submit until it’s constraint are met but FF4b5 submits regardless of it’s validity?

    The WhatWG working draft specifies:

    “Forms can be annotated in such a way that the user agent will check the user’s input before the form is submitted.”

    http://www.whatwg.org/specs/web-apps/current-work/#client-side-form-validation

    Which leads me to believe that this should block a user submitting a form until it’s valid?

    September 7th, 2010 at 18:24

    1. Anthony Ricaud

      You’re right, it should block. But we are still working on our implementation. Expect more details with beta6.

      September 8th, 2010 at 04:52

  2. Martin Kliehm

    Phantastic news, I so want to experiment with the audio API and I’m glad it made it into the main trunk. But you need to improve the quality of the link texts. “Here” is pointless when you scan the text for highlighted words because you need to read the text before to get the context, and it’s incomprehensible for blind people using a list of anchors to get an overview. So instead of “try the demo _here_” it’s better to say “_try the demo_”. There’s also a more comprehensive explanation at http://www.w3.org/QA/Tips/noClickHere

    September 7th, 2010 at 23:04

    1. jswisher

      Thanks for your feedback. I’ve updated the post to make the links more descriptive.

      September 8th, 2010 at 15:06

  3. Wladimir Palant

    > We now allow calling click() on a input type=”button”

    I think you meant input type=”file”. The example in the bug description uses input type=”button” but it is only there to call click() on another input element.

    September 8th, 2010 at 03:29

    1. Paul Rouget

      Oops, yes, it’s what I meant. Fixed. Thank you!

      September 8th, 2010 at 03:58

  4. voracity

    The ‘Allow calling click() on input type=”file”‘ bug dates back to 2000. The history of the bug went something like:

    1) (parity) feature requested
    2) 4 years inactivity
    3) security questions (quite rightly) raised but left unanswered
    4) patch supplied and receptively reworked but blocked due to security doubts for 6 years
    5) very fast iterations over the past month to get this landed

    (Note: the security doubts were fairly easy to resolve — not 1+1 easy, but easy enough.)

    I mention this, not because I wish to be critical, but because I want to highlight that steps 2-4 seem to be a relic of old processes, while step 5 seems to characterise the modern Mozilla development process much better.

    Keep up the good work!

    September 8th, 2010 at 05:18

    1. voracity

      On a related note, has progress been made on allowing content to request going full screen? (i.e. https://bugzilla.mozilla.org/show_bug.cgi?id=545812 )

      September 8th, 2010 at 05:29

      1. Christopher Blizzard

        It’s not going to happen for Firefox 4, but will likely be a feature of a later Firefox release.

        September 9th, 2010 at 09:02

  5. vinay

    mention this, not because I wish to be critical, but because I want to highlight that steps 2-4 seem to be a relic of old processes, while step 5 seems to characterise the modern Mozilla development process much better.

    Keep up the good work!

    October 11th, 2010 at 06:51

Comments are closed for this article.