DevTools: Halfway to Firefox 7

kdangoor

15

We’re now right in the middle of the 6 week development cycle for Firefox 7, so I thought I’d do a quick rundown of the features we’re tracking for that Firefox, with two special bonus features at the end. Remember that we’re following a release train model here. The timing for Firefox 7 is fixed, but the features listed below are not. If we get everything ready in time, you’ll see the features listed below appear in Firefox Aurora builds sometime around July 5th and in a Firefox release around September 20th.

Highlighter lets you visually select a DOM element, see some basic information about the element and access further tools for working with the element. It’s a gateway to visual/design oriented tools. Rob Campbell and Mihai Sucan have been working on the main patch in bug 642471. Paul Rouget has been working on improvements to the initial element highlighting and adding the overlaid information in followup bugs.

Status: Main patch is ready-to-land
Next 3 weeks: polish the feature with the followups

Style Inspector takes the element selected by the Highlighter and gives you detailed information about the styling of the element. This feature was initially created for Firefox 4 last fall and recently revived by Mike Ratcliffe. bug 582596 covers the main work of landing the feature. Additional important bugs cover things like integration with the Highlighter.

Status: Reviewed by the devtools team, waiting on browser peer.
Next 3 weeks: land it and get the Highlighter integration in

Style Editor makes it possible to make changes to the CSS on your page and see those changes instantly take effect. Cedric Vivier has quite a few great ideas for this tool, and we’re hoping to get the first step out in Firefox 7. Cedric’s editor is available as an add-on right now. He will be attaching a patch version of this to bug 583041 within the next couple of days.

Status: Patch coming up for review by devtools team.
Next 3 weeks: Get the patch up, reviewed and landed. This will likely be followed by a UI polish round.

HTML Tree editing provides a simple interface for making some changes to the current DOM. Specifically, you’ll be able to manipulate attributes and text nodes. Kyle Simpson has picked up work on the HTML tree that was already in mozilla-central, experimented with the user interface and is now getting a patch together for the tree. You can track the progress in bug 659710.

Status: Patch coming soon for review by devtools team.
Next 3 weeks: Get the patch up, reviewed and landed.

We’re adding a Code Editor to Firefox to improve the editing experience for the Scratchpad and Style Editor features. Mihai Sucan is integrating the Eclipse Orion editor, which has very good accessibility and internationalization aspects. This work is tracked in bug 660784. A separate bug tracks the Scratchpad integration for the editor.

Status: Initial patch reviewed, more work required for testing the integration. Also getting accessibility feedback to see if the editor hits the “good enough” level.
Next 3 weeks: Finalize the patch and land it.

The console object is being extended to have just about everything that’s in the de facto standard. Panagiotis Astithas is leading the charge on this, and there are several bugs involved in this work.

Status: Much has landed already
Next 3 weeks: land console.dir, console.group/groupEnd

And now, the two special bonus features. These aren’t going to make their impact in Firefox 7, but the progress during the 7 cycle has been great!

The Command Line is part of a rethink on how people get things done with developer tools. It’s going to take us a couple of releases to fully bake the Command Line+Scratchpad idea, and we’ll be talking more about this soon. Joe Walker worked heavily on the Bespin command line and has been working on this seriously spruced up new version of the idea. Our new intern, Nick Fitzgerald, will help out with this feature.  It’s actually possible to use this sort of command line interface in your own webapps as well.

Status: Landing support for command registration soon
Next 3 weeks: working to land the command line UI, but turned off by default until we’ve fully fleshed it out

Finally, the Script Debugger project is huge and has many moving parts. Dave Camp, Jim Blandy and Jason Orendorff are hard at work giving the SpiderMonkey JavaScript engine an entirely new debugging interface that is remotely accessible. Panagiotis Astithas will be helping them out soon as well. The groundwork being laid for this feature is going to help make our other tools remotely accessible, too.

Status: SpiderMonkey can stop at debugger statements and provide stack traces over the remote protocol
Next 3 weeks: Continue on the strong progress made so far… this is not a Firefox 7 feature, but will be here before you know it!

Getting Involved

We’re building a lot of new tools, and I think they’re fun and exciting projects that will help a great many web developers. There are many opportunities to get involved, and we’d love your help in building some of the best tools for the open web.

Update: Since our release train model is still quite new, I added some additional information to the first paragraph to describe when these features are likely to be available.

– Kevin Dangoor, on behalf of the Developer Tools team

15 responses

  1. Simon wrote on :

    You guys are seriously confusing things with this rush of versions. FF4 has only been out a few months, and you’re claiming you’re halfway through development of 7? What about 5 and 6?

    1. devtools wrote on :

      @simon: Thanks for the comment. It’s easy to forget how new the Firefox rapid release process is, since we’ve been living in it for nearly 3 months.

      I added some text at the beginning which clarifies a bit.

      Since this is important, I’ll just quickly lay it out here as well: we’ve moved to a development model that allows us to get new features out to users within 18 weeks of those features being developed. Firefox users can get new things every 6 weeks under this process.

      Clearly, each release will have less new stuff in it than the huge Firefox 4 release, but we believe that getting functionality out to users quicker through smaller releases will make Firefox a better product and the web a better place. (Case in point: Firefox had the video tag ready in summer 2010, but it wasn’t released until Firefox 4 in March 2011!)

      So, Firefox 5 is being released next week. Firefox 6 will be out in August.

  2. Robert Kaiser wrote on ::

    Ugh, so we are back to integrating a load of third-party code instead of improving our own editor code again?
    Has anyone actually talked to Ehsan et al. on how we could make things better for everyone with our own tools instead of adding a pile of (at least in the groups/lists have been said to be) suboptimal code like Orion?

    1. devtools wrote on :

      @Robert: Ehsan has provided great feedback there and there has been a decent amount of discussion on dev-platform about it.

      The short story is that the editor built into the browser must be part of the solution (and is!) because it handles things like i18n and a10y in ways that are difficult or impossible to do purely in web content right now. The built-in editor is not designed to be a code editor. We could build our own, but we would basically be rebuilding Orion, which already uses contentEditable.

  3. Webdeveloper wrote on :

    Could you explain the thinking behind putting in the development effort to roll your own development tools when sufficient debugging tools already exist for the platform (like Firebug). Or are those tools not viewed as sufficient in some way?
    Thanks

    1. devtools wrote on :

      Indeed I can….

      http://blog.mozilla.org/devtools/2011/05/25/the-relationship-between-firebug-and-mozilla-developer-tools/

  4. Will wrote on :

    The version number change is not an issue for me. Instead It’s a bit refreshing. I’m using nightly since 3 was alpha and have most of (at least) the version changes since then archived, (somewhere, anyways)… :}

  5. Dan wrote on :

    Why does all of this need to be in the default Firefox build for half a billion users when only a very small percentage of those will use any of it? Didn’t Inspector get removed for a reason? Extra code isn’t free. It can increase download size, update size, startup time, memory usage, security surface, development time, QA time etc.

    1. devtools wrote on :

      @Dan: Great question.

      I’ll start by saying that Inspector was removed because it wasn’t ready in time for the Firefox 4 “feature complete” date, which was way back in September. The new rapid release cycle is a huge improvement. There’s still a possibility that the Highlighter will not be ready for Firefox 7, but it would only need to wait 6 weeks longer before it’s released.

      You’re correct that only a small percentage of total Firefox users will use the devtools. We’re also fortunate to have in Firefox an add-on system that is flexible enough to support developer tools as an add-on. We may change our packaging some day and head that route. For now, though, we’re focused on building great tools.

      Mozilla has a good deal of infrastructure built up to ensure the quality of our product. Our automated testing system ensures that code that lands doesn’t break other parts of the product. It also ensures that startup time and page load time are not negatively impacted by changes that come in. We want to apply that infrastructure to our devtools. Changes we make and changes others make should not negatively impact the product and automated tests help catch that.

      Further, we want our tools to go through security review and QA just like other Firefox features. They should follow the same high quality standards.

      Eventually, we may have the infrastructure set up to handle some add-ons with the same rigor, but we’re not there yet. Believe me, though, that we have considered shipping devtools as an add-on. That was even the plan in the roadmap I posted in January. But, we had sound engineering reasons to stick with built-in features for now.

  6. Ajoy Bhatia wrote on :

    The rapid release cycle is good but Firefox 5 out today (June 21st) and Firefox 6 coming in August? I hope that increasing the major version number every two months does not become a trend. Hopefully, the upcoming Firefox 6 release really deserves the major version increment.

    1. devtools wrote on :

      @Ajoy Generally speaking, we’re not going to focus on version numbers any more. If you look at the release announcement for Firefox 5, you’ll see that it does not mention “5″ at all. It only talks about the “latest Firefox”. That’s a bit harder to do when you’re referring to a future release, as I am here.

      I could have just referred to the “September Firefox”. Maybe that would have been better?

      1. Jinu Joy wrote on :

        @devtools as long as it does not break my add-ons, a release is welcome every month. However yesterday when I updated to Firefox 5.0 quite a few plugins (eg: echofon, foxtab) I was using stopped working all together.

        1. devtools wrote on :

          @Jinu add-ons is not my area, but I do know that we pay close attention to add-on compatibility with each release. I believe we’re at the same level with Firefox 5 as we are with a typical (long cycle) release at the time of release

          We do care and there are definitely people thinking about how to make add-on compatibility work as well as possible…

          Kevin

  7. shashank wrote on ::

    Question: Firefox 7′s features includes auto-removal of JS. Does it going to affect a old website??

    As a tester/developer what are the things we have to keep in mind, when working on Firefox 7??

    1. kdangoor wrote on :

      Hi Shashank,

      I don’t know what you mean by “auto-removal of JS”… I’ve never heard of a feature like that.

      Generally speaking, we approach every Firefox release with a “don’t break the web” attitude. We’re very conservative about changes we make to our handling of web pages.