Mozilla

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

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.

10 comments

Comments are now closed.

  1. Ryan wrote on September 7th, 2010 at 18:24:

    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?

    1. Anthony Ricaud wrote on September 8th, 2010 at 04:52:

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

  2. Martin Kliehm wrote on September 7th, 2010 at 23:04:

    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

    1. jswisher wrote on September 8th, 2010 at 15:06:

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

  3. Wladimir Palant wrote on September 8th, 2010 at 03:29:

    > 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.

    1. Paul Rouget wrote on September 8th, 2010 at 03:58:

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

  4. voracity wrote on September 8th, 2010 at 05:18:

    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!

    1. voracity wrote on September 8th, 2010 at 05:29:

      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 )

      1. Christopher Blizzard wrote on September 9th, 2010 at 09:02:

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

  5. vinay wrote on October 11th, 2010 at 06:51:

    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!

Comments are closed for this article.