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.

Open systems are better and lead to more productive coders. This is a wild assertion I’ll make with some cheek, mostly because I don’t think any exemplars from closed-system programming can really refute it, or will. Programmers who get into pure languages like Lisp and Smalltalk ramp up quickly and become more productive because they have full view of the system’s source code.

So too, the web.

Web-programming is often a cut and paste experience. I hear the term “cut-and-paste inheritance” used derogatorily too-often. While it’s true that in some cases, from a code-design perspective, just pasting blocks of code from one document to another can lead to a poorly-designed system, it is great for getting little pieces of code to work. It is the scientific method applied to programming. You see something that works in one place, you try copying it over and see what fails on your page. Continue.

One area where view-source breaks down is in the analysis of “what happens” with that source code. The Error Console in Firefox is a poor-excuse for a debugging mechanism and linked to the view-source window only by a hopefully connected error and a line number you can click on. Errors can come from any tab and are not necessarily associated with your code. There is no sense of iterative feedback. You have to hunt for it and usually fall into a pattern of clearing your console and reloading the page to see when the errors occur. This leads many developers to write their own logging function. Or when they’ve graduated to more advanced development, install Firebug which presents dynamic views of your source code in exciting (and sometimes surprising) ways.

Another mysterious failing of view-source is in a dynamically generated page. Something that uses document.write() or a bunch of appendChild() calls often doesn’t show correctly in view-source. A trick I learned recently to see these types of changes is to select some text and right click on it and “view-selection source”. Not exactly intuitive, but this will show you what your code generated.

I don’t think anyone can claim that view-source is a bad thing, though I have seen people try to get around it. Usually under the guise of “I have some important information or data that I need to protect”. I have seen people file bugs to add a mechanism to Firebug to prevent inspection of the underlying HTML on certain pages. I find these types of requests pretty funny, generally, and a little sad because people who think this way fundamentally don’t understand what the web is about and how it works and why it got to be the wonderful thing it is today.

It’s a fairly common practice to hide content behind a flash barrier to prevent people from getting their grubby paws on it. This creates a large swath of the web that you really have no ability to play with or learn from. Also, I think it’s fairly safe to say that learning to program in Flash is a more expensive proposition than learning to program for the web. You have to pay for tools, books and example code. If you want to make something that looks like this widget over here that has some wandering penguins on it, you have to figure it all out for yourself.

Alex mentions generative tools and libraries like GWT that create HTML and CSS styling as by-products of their execution and that these create a not-very useful rendition for view-source. This is true. Even PHP-generated HTML can be pretty disheartening to look at if you’re trying to figure out what’s going on in a web-page — its poor formatting and machine-generated constructs are not pretty to look at, but you can still sometimes glean some of the workings behind them. Having hacked around in Wordpress for a few years, understanding the way the PHP code generates a blog’s output is an interesting experiment to puzzle through. I wouldn’t have been able to do that without view-source.

Anyway, I think I’ve burbled about this enough. I love view-source. There, I’ve said it. It is one of the most valuable tools we have for understanding and learning about the web.

First, a little terminology. Feel free to skip this paragraph if you consider yourself a master of Javascript internals or compiler run-time optimization makes your skin crawl. Tracing is the mechanism Firefox’ Javascript engine (aka, “SpiderMonkey”) uses to improve code execution performance. It provides a major speedup for code running in Firefox 3.5 and up, often an order of magnitude for certain types of operations. It is the basis of the JIT or Just-in-Time compiler. Without tracing, the JS engine can’t optimize code as well, leading to significantly slower execution.

I need to be clear here: If you have Firebug installed you are probably not getting fast Javascript. Firebug doesn’t have to be active on your current page. If you have the grey icon on your status bar, you have probably disabled the JIT. This is true if you have ever enabled the Console and consequently the Script panels and left them on. This is likely true for most recent versions of Firebug. The quick fix is to disable the Script and Console panels via the mini menu on their respective tabs.

Boris Zbarsky has been doing a lot of poking around in the belly of the JS debugger lately. Working in conjunction with John Barton, they have concocted fixes for the soon-to-be-released Firebug 1.5 and Firefox 3.6. We’re working to get testable versions out as quickly as possible, but I can say that I’ve tested development builds using the pages mentioned in the bug and can verify that these fix the problem. As a side-benefit, I got to watch Boris dissect the problem through gdb in an Xterm (yes, an Xterm) and Emacs and it was pretty impressive and fun, to boot.

When installing Firebug one of the first things most people do is enable the Console. It’s such a useful debugging tool. I myself have been using Firebug for over a year without JITted code. I probably never noticed the slowdown simply because I’m so used to running my browser this way and have pretty fast machines. After disabling the Console and Script panels there are a few pages that just load much much quicker. It’s kind of shocking.

Since the patch has landed on Firefox 3.6, I’m expecting either a beta or release candidate of that to come out shortly. I’m also hoping for another Firebug beta (or release candidate) later this week. In the meantime, if you’re not using them, I recommend disabling the Console and Script panels and find out what you’ve been missing and turn them on only as-needed. This will likely be the work-around for Firefox 3.5 users unless we decide to push this back to that branch but I have my doubts that this is something we would do.

Now for version 3.6b3 and above, you’ll have to set a per-application version in about:config that looks like this:

See Mossop’s post on the topic for the deep story.

We’re in a bit of a funny place with Firebug and Firefox 3.6. The Firebug 1.5 line is currently running better on Firefox 3.7 (trunk, mozilla-central) than it is on the 1.9.2 branch (Firefox 3.6, aka Namoroka). Fallout from a couple of bugs is causing some strange scrolling problems in Firebug and likely, a few other add-ons. Worse, we’re unable to edit anything in Firebug’s HTML and CSS editors.

That should change shortly. We’re waiting for a small patch in bug 511951 to land and correct these issues and make everything right again. I ran a build with this patch last night and confirmed that everything looks good. Our tests ran fully with no errors.

If you’re the adventurous type, you may feel like grabbing our latest version, Firebug 1.5a24 from getfirebug.com/releases and giving it a whirl. There are some changes, some improvements and more than a few bug fixes. See the evolving release notes for details.