It’s been a bit of a crazy week. A crazy couple of weeks if the truth be told. The pace of checkins and change on the Firefox codebase has been staggering. Record-breaking by some accounts.

As Kevin Dangoor mentioned earlier this week, we are now an actual group of developers instead of just a couple of guys banging on code. We’ve inherited members of the Bespin team and in a very short while have made some really exciting progress on these tools. I can honestly say that I’m thrilled to be working with such a talented bunch of guys and am going to really miss our awesome interns. Mihai Sucan and Julian Viereck have been monsters of code these past few weeks and have been submitting patches at a furious pace. So much so that our reviewers are having a hard time keeping up.

Review load has been pretty heavy. One of the biggest pieces we’ve been waiting on and dragging around is the tree-panel patch which I’ve blogged about before. Weighing in at somewhere near 200KB of JS and CSS, it was not something I’d relish having to review myself. Gavin made it through though, and earlier today, gave me the green light to land it. It should finally be in Beta 5.

We’ve got even more awesome stuff coming in for the next beta including an all new Style Panel courtesy of Joe Walker with help from Mihai and CSS and HTML editors from Patrick Walton and myself. With those features and a few other niceties, I think we’ll be able to start calling the Inspector a useful tool and something that people will want to use.

The Web Console’s been pulling along too and it’s starting to really take shape. I’m already using it for simple tasks like modifying bits of the DOM through the JS command line or drilling into objects to see what they’re doing. In Beta 5 you’ll see an actual object inspector (shared between it and the Inspector) as well as a new Network Panel from Julian. Patrick’s been piling on the patches to make it look prettier and his efforts are starting to pay off. David Dahl’s been busy working on getting a lightweight Console API in place that web pages will be able to use and hopefully other consumers will want to make use of.

So yeah. I’m just going to take a moment to thank everybody for their help and reflect on what an awesome project this has been.

The Inspector still has a bunch of pieces to land and we’re hoping to get the major ones into Beta 5 this week. We’ve got some neat stuff coming in and have had some excellent help getting it together. I’ll write more about that in a later post, but to those of you who’ve written in the newsgroups, tested the inspector in the nightlies or betas, contributed features and patches, talked about UX or helped to organize the work, thank you!

It’s pretty basic right now and we’re going to be beefing it up and adding to it in the hopefully very near future. What it shows right now is a list of all CSS properties for the selected (highlighted) element in a web-page. It will also tell you which elements the rules were inherited from (in reverse-order) and from which stylesheet the rules came from. You may need to expand the panel slightly to see the full text.

These panels are not positionable yet, but with the landing of the titlebar patch in bug 552982, it’ll be a quick thing to add. I’m hoping that comes in Real Soon Now. The funny-looking title bar that doesn’t do anything in the current version is actually a toolbar I added as a placeholder for the real thing. In the meantime, I suggest moving your browser window to the left of your screen to allow some space at right for the panel to live in (as well as some space below your window for the tree panel to inhabit).

What’s next?

I still have a few downstream patches requiring review.

• Milestone 0.3, create DOM Object viewer for Inspector.
• Milestone 0.5, rewrite tree panel
• Milestone 0.6, create popup editor

I have a patch for the popup editor which needs to get added to that last bug which I demoed at the Summit Science Fair. I need a similar editor for CSS editing. Once those are squared away, I’ll be working on redesigning the highlighter panel and getting the styling finished up for the various pieces on all platforms.

Please file bugs in Firefox::Devtools.

Grab it here: Inspector Milestone 0.5 Preview.

Other work that’s moving along nicely:

• Neil Deakin’s ongoing improvements to XUL Panels.
• David Dahl’s work on the Heads Up Display
  
• Firefox 4 Theme work is beginning to land

… Just to name a few.

We also picked up some help from some members of the Bespin team this week. We’re still figuring out what people are going to work on, but it looks like Julian Vierick is going to do some Inspector<->Console cross connection stuff with the DOM Panel. And maybe, just maybe, Joe Walker is going to help me make the Inspector look pretty. I am hopeful.

Give the preview a try and let me know what you think. Feel free to file bugs in Firefox::Devtools.

Update: After the rebasing, I’ve cloned another user repo for ongoing work. It’s too much of a pain to reintegrate patches from a point in time and merge everything together in a way that won’t mung up a future extraction. And cloning is cheap. If anyone has a good idea of how to “applepick” in hg, I’d love to hear it.

New repo is here: http://hg.mozilla.org/users/rcampbell_mozilla.com/mozilla-inspector-3

To be sure, there are some bugs left. Clicking the twisty images still doesn’t expand and collapse the trees – you need to click on the tag to do that. It’s still behaving funny with iframes. I still need to revise the styling for the tree panel and other panels to make it look like I want. I need to add some keyboard controls…

All of this will need bugs filed and patches written. If you’d like to help, please feel free to file bugs on the Firefox::Devtools component. Make sure to use Inspector in the subject or whiteboard so we can track it. We also have a #devtools IRC channel on irc.mozilla.org if you’d like to pop in and say hi.

Other bits I have left to do include verifying my existing test cases and writing a few new ones. There’s a lot of debugging code I need to strip out and lastly, I’ll need to rebase my patches against current mozilla-central and roll it all up into a nice tidy patch for my reviewer victim… I mean friend. Before that though, I hope to churn out some try builds tomorrow or Wednesday for people to play with.

If you want to check out the source and build your own, it’s living in http://hg.mozilla.org/users/rcampbell_mozilla.com/mozilla-inspector-2/. Careful, it’s fluxy!

Currently, we include View Source in Firefox 3.6. I’ve blogged about how important view source is and how awesome it is that we have it, but inspection is a different kind of activity. Whereas view-source is linear, letting you view the underlying document from which your page was created, inspection is dynamic, letting you dip into a webpage to view a particular node and its associated properties. To find a node and its rules in view source, you might need to browse to several linked documents to locate the specific set of rules. Inspection locates everything for you. Of course, the inspector won’t show you the documents and their relation to each other on the server. For that, you’ll still need view-source. Further, inspection will show you live changes to the document as they occur. View-source is a moment in the life of the web page, and remains static.

Most web developers use a combination of tools outside of their browser to create attractive pages and interesting content: design and graphics tools like Illustrator and Photoshop and a broad array of content editors from Frontpage to Notepad++. For the inspector, we talked about some of the different interactions we wanted to give to developers and looked to these other programs for inspiration. The tool should feel dynamic and yet be easy to get out of the way if you want to go back to browsing the web. You should be able to quickly inspect a piece on a webpage and get as much information out of it as you wanted. Maybe you’d like to make a quick change or remove an element? Manipulate some DOM attributes, or move an element around in a page and have the Inspector make the positioning adjustments for you.

We’re not there yet. I’m still cobbling together pieces to provide some of the basics. But we’re hopeful that with these foundation blocks in place, we can start to build on them to provide unique interactions that have a more “designery” feel like the tools people already enjoy using to create content. We’re hoping the inspector will feel comfortable and intuitive to you.

Over the next little while, I’m rewriting the Tree panel, adding editing capabilities, redesigning the highlighter to look more like what’s in the mockup on the project page, adding rulers and guides to help with layout, and a few basic controls for making all of this easier to manage. The initial Style and DOM panels are waiting in the wings ready for review.

This is a different approach to inspection, for a different kind of user. We’re not looking to replace tools like Firebug and DOM Inspector – they are awesome, and we’re still totally committed to helping them be the best they can be. We think there’s a group however, that doesn’t need the depth of Firebug, but does want tools with a more “designery” feel. My hope is that Firefox and Firebug will complement each other in somewhat the same way that tools like Lightroom and Photoshop do.

To get your ideas and suggestions heard, reply here or on the dev.apps.firefox thread.

What are we looking at and how do you find it? In the Tools menu, there’s a new menu item labeled “Inspect”. Selecting this (or using the Cmd/Ctrl-shift-I hotkey [subject-to-change]) will bring up a panel at the bottom of the Firefox window with a tree representing the nodes in the HTML page you’re on. Hovering over elements in the page will select the appropriate node in the tree. You can finish dynamic inspection (i.e., hover over node to inspect) by clicking in the highlighter panel over a node, or hitting ESC or Return on your keyboard.

To close the Inspector panels, reselect Tools:Inspect from the menus or use the Cmd-Shift-I command shortcut again.

If the tree display looks a little familiar, it’s because you’re looking at an inDOMView-based tree widget. This is the same widget used in DOM Inspector, albeit a little differently-configured. This one’s setup to include all attributes under a node and their values.

Currently, the panel is undecorated. We’re awaiting a patch from Neil Deakin to provide title bars for panels. You might find that the highlighter (also implemented as a panel floating over the content area) sometimes obscures the tree panel. This is also a bug in progress. You can read more about some of the additional panel improvements Neil has underway on the Mozilla wiki.

And there are bugs. Some are addressed in downstream patches. Others are waiting to be fixed. Still others are, I’m sure, unknown. Testing this out everywhere you can will be helpful. If you find something, do a search in Bugzilla in the Firefox::Devtools component, and if you don’t see a match for it, feel free to file a bug. If you’re really keen, attach a fix to it. We love that kind of thing.

Next up are the Style and DOM panels which I am hoping can land within the week. I’ll be rebasing the patches in those bugs by end of day. You will also see a toolbar appear on top of the tree panel. I’ll blog about these features as they materialize in nightlies. I also plan on filing top-level bugs for the remaining features on the Inspector project page. If you’d like to help out, feel free to contact me and I can point you to what needs some effort. Whether it’s writing test-cases or feature code, there’s lots to go around.

All of this is moving towards a vision of a simple and fun-to-use web page inspector that will be shipping with the browser. There’s still a lot of work to do on it, but we’re making steady progress.

Electrolysis (e10s) feeds patches to Mozilla-Central (trunk or Minefield).

Lorentz branch split off of 3.6.

Lorentz pulled some of the Electrolysis patches from Mozilla-Central.

Lorentz merged back into 3.6 (and was closed).

What is Lorentz? It is (was) a branch to contain merges of out of process plugins for Windows and Linux. Mac will follow, though maybe not on 3.6 branch. It will be included in an upcoming release of 3.6.

A lot’s changed since those dark days, however. To say that we spend a lot of energy doing performance analysis is a bit of an understatement. We have entire teams dedicated to improving performance. Build options are analyzed and re-analyzed in an attempt to find cheap performance improvements. Specifying global code optimization settings can actually have an adverse effect on overall system performance because certain modules react better to, say, -O2 versus -O3, for example. All code that gets checked in has to make it through our performance tracking system or it gets backed out.

In the interest of Science, I wanted to actually see if there were any differences, so I pulled a fresh copy of mozilla-central and applied the referenced .mozconfig.

The first thing I noticed, was that –enable-profile-guided-optimization didn’t seem to be doing what I thought it would. Namely, I expected to see a browser window popup and run through some automation before starting a second compilation phase. It didn’t. Even so, the resultant build did feel a little faster at opening windows and tabs*.

So, I applied the latest stand-alone version of Talos to the build and executed the Ts (startup) and Twinopen (Window open) tests and compared this with the most-recent Mozilla nightly build of Minefield. Surprisingly, the windows didn’t appear to be opening much faster, but the startup time was on average 5% faster in the new “optimized” build vs. moz-central nightlies.

By this time, Ted had commented in the bug tracking all this and pointed me to the PGO page on MDC. It turns out, PGO builds require a separate make target “profiledbuild” instead of “build”. I reran the build, saw the automation was working this time and then reran the Talos tests. No change. Best guess around these parts is that GCC just isn’t very good at doing PGO. The same option gives us an across-the-board 10% speedup to all our tests on Windows.

It turned out that the option that was giving us the 5% startup time (and likely a slight boost to tab performance) was the 10.6 SDK target. Each revision of OS X includes optimizations and Snow Leopard is no different. If you want your own optimized build, just put that target (–with-macos-sdk=/Developer/SDKs/MacOSX10.6.sdk) in there if you’re on Snow Leopard and you’ll get a little extra snappy.

I haven’t booted into the 64 bit kernel to see if there’s any difference there, or even if the build options produce a 64 bit build. I don’t believe they do and the version shipped on the above optimized builds page don’t have the tell-tale “Open in 32 bit mode” checkbox in the app’s “Get Info” dialog.

* A word about perceived performance differences: It’s very hard to tell the difference between, say, 20ms and 30ms. That’s a 50% slow-down compared to 20ms but the actual slices of time are so small that the human brain has a hard time picking up on them. Nevertheless, people used to dealing with high-velocity timings (musicians, gamers, fighter pilots) can actually detect that kind of change. But there’s also a “wishful thinking” factor. It’s very easy to be told you’re going to see a speedup, and when given an identical application, think you’re seeing something faster. “It just feels snappier” you might say when given this placebo.

• Enhanced Inspector
• More accurate Net panel timings
• Break on HTML mutation
• MathML and SVG namespace support
• Break on XHR
• Improved HTML editing
• Persist buttons on Console and Net panel
• Separate Computed CSS and Style subpanels
• Many many bugfixes and stability improvements

This is a huge release and these are just some of the highlights you’ll see in this new version. Please feel free to read the release notes and John Barton’s blog post for more details.

As always, if you encounter any problems, don’t be shy about filing a bug! We’ll be following up with quick point-releases if and when you find issues.

Special shout-outs and thanks to Mike Ratcliffe for the Inspector improvements, Steven Roussey for HTML editor improvements, SVG and MathML namespace patches, Honza for being awesome and John Barton for his tireless contributions.

If you’re new to Firebug, you might want to check out my introduction to Firebug screencast.

(This post has been translated into Belarusian by Marcis G. Thanks!)