Firefox Feature Development in 2012

This year we started talking about ways to improve the methods in which develop Firefox features. This is a snapshot of where we’re at, and what’s coming next.

We began with some conversations about current problems regarding coordination, speed, contribution, regressions, ease of development: my initial dev.planning post, Joe Walker’s post ‘How to Eat an Elephant’, my blog post, dev.planning add-on bundling post.

There was general recognition that the Firefox development model is not agile nor flexible enough to meet the needs of our 2012 goals. We need to be able to ship features that are developed mostly outside of what’s considered the “core” Firefox team. We need to better support the use of external code repositories and bug tracking systems. We need to support features written using the Add-on SDK, both inside and bundled with Firefox.

Here’s where we’re at:

  • A group of people formed to start discussing how to make these things happen: the Jetpack Features group. We meet every other Friday (meeting details and notes).
  • We have a project branch (Cedar) where we can experiment and do performance testing.
  • We corralled the Firefox and Toolkit module owners and the leads of the SDK project in a room to orchestrate the mechanics of landing the SDK inside Firefox itself (notes).
  • L10n: The Jetpack team are hard at work on closing this gap with both localized strings in script and localization of HTML content inside add-ons.
  • Performance: Jeff Griffiths blogged recently about the performance impact of the core SDK runtime on startup time. More performance tests are coming.
  • Feature bundling: The BrowserID feature will likely ship in Firefox as a bundled add-on. There are still open questions though: Is it uninstallable? Does it even show up in the Add-ons Manager? Can it upgrade outside of the Firefox dev cycle? More work to do here.
  • Automation: We have the Jetpack unit tests being run with every Mozilla-central check-in (though hidden by default currently). We have the SDK unit tests running on every SDK check-in for both Nightly and Aurora (tree). We still need the Mozilla-central unit tests run on every SDK check-in (that’ll come with integrating the SDK into Firefox), and performance tests run for Mozilla-central and SDK check-ins.

What’s coming up in 2012:

  • Completing the picture of addon-as-feature integration into the Moz-ecosystem: l10n, performance and unit test automation.
  • Ship BrowserID as a bundled add-on.
  • Ship the SDK inside Firefox (the relevant parts, anyway).
  • Ship Web Apps as a bundled add-on, if it makes sense to do so.

3 Comments on “Firefox Feature Development in 2012”

  1. zorb says:

    Cool stuff!

    There’s one feature I have to talk about however. One VERY MAJOR issues with Firefox that people always bring up, is how the UI is not always responsive.

    Now in casual use it’s usually fine, but it’s true that it’s never as responsive, as, say, Chrome. Plus it does happen that Firefox UI freezes and must be killed through a task manager, because a subprocess or a part of Firefox froze. Specially “happens often” with plugin-container+flash for me. (it might also be a plugin container bug, as i’d think this shouldnt be able to freeze FF, but the point is still valid)

    This is something that is fixed on Fennec. I even like it more than multiprocessing. It’s also the way BeOS was designed, just for the record.

    I think there is some work being done by the Snappy project to bring the UI in it’s own thread, but I can’t find it.

    Even removing XUL for a special test branch might be worth it, because it’s really such a major point that make people switch over.

    • geeknik says:

      The UI is always very responsive for me, at least in the Nightly builds, and until memory usage hits the 1GB – 1.5GB mark. Then the UI becomes sluggish and the browser as a whole slows to a terrible crawl..

  2. Ksec says:

    If Firefox Manages to be as fast as the current version of Chrome by the end of 2012 i will be VERY impressed.

    Although being a long time Firefox users i dont see this happening.

    @ Zorb – I think what you want is e10s. Bring UI into ‘s own thread has been postponed until further notice. Which means you properly wont see it until 2013.


Leave a comment