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!

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.

From this:

(Firefox adds %20 for each of the spaces when you save it as a bookmarklet)

The above snippet grabs the currently selected text in a web-page and opens it in a new window. Add it to a bookmarklet of your own on your toolbar and you have a convenient way to open new text in a separate tab. For bonus points, install the keyconfig extension to create a keyboard shortcut (you’ll need to force-install the extension and write a little function to get that to work). Thanks to Neil Lee for the keyconfig tip!

Enter FireUnit! An extension for Firebug that aims to be able to test Firebug itself, and later on, perhaps be a useful framework for developing unittests for the web. It’s still very early on, but there’s a core emerging.

Installing FireUnit is currently a bit of a manual affair. Download the source code from the github repository and extract the downloaded zip or tar file to your local filesystem.

Open your profile/extensions directory for the Firefox profile that you use with Firebug. Create a new empty text file there with the name “fireunit@mozilla.com” (no quotes, of course). In this text file, add the full path to the FireUnit directory you unpacked in the previous step. E.g., “/Volumes/Data/Projects/FIREBUG/fireunit” in my case.

Test panel of FireUnit after running commandline.html

When you open/restart Firefox with this profile and open Firebug, you should now see a new “Test” panel in the list of tabs. Go to the location bar and type in / paste chrome://fireunit/content/test/commandline.html. You should see some flickering as FireUnit runs through the tests in that commandline.html. When done, you should see a bunch of passes listed in the Test panel (hopefully no failures!).

While I’m rambling about testing, I should mention that there will soon be a new alpha version of Firebug 1.3 (a4) available for download at getfirebug.com/releases/firebug1.3. This would be an ideal version for you to try out FireUnit on! For the more adventurous in the crowd, Chromebug 0.3a8 is R261 on https://fireclipse.svn.sourceforge.net/svnroot/fireclipse/trunk/FireclipseExtensions/chromebug.

First, there are a couple of caveats about Chromebug. It’s still in an experimental state. Some parts work well, like the inspection of a chrome window’s DOM tree and CSS. Other parts are a little flakey or down-right broken. As of right now, the default build instructions will attach you to a 1.3 version of Firebug which has some improvements to handling large script files but is also somewhat broken. It should improve shortly.

So, with that out of the way, I’ll run through a quick Chromebug setup and install. The instructions are on the sourceforge page for Fireclipse, a plugin for Eclipse that adds some debugging capabilities for Firefox and/or JavaScript.

Step 1. From a suitable directory on your computer, check out the chromebug sourcecode from svn. There are external svn references to include two other add-ons, chromelist and firebug. These will get checked out as well.

Step 2. Create a new profile for Firefox using the Profile Manager. I called mine “Chromebug”. Make sure you start Firefox with this new profile to finish the creation process.

Step 2a. Make note of the location of this new profile. You’ll need the full path for the following step. On Windows, this would typically be in “C:\Documents and Settings\%USERNAME%\Application Data\Mozilla\Firefox\Profiles\xxxxxxxx.Chromebug\”. Replace %USERNAME% with your username, and xxxxxxxxxx with some randomly generated string. Just look for *.Chromebug in that directory. You will need this for the “install.dir” property in step 4 below.

Step 3. In a console (or terminal window), cd to the chromebug directory you checked out earlier. E.g., cd ~/Projects/fireclipse/extensions/chromebug

Step 4. Create a local.properties file using your favorite text editor in this directory. Add the following properties to it (each property should be on a single line, regardless of how this blog breaks it up):

Step 5. Create links to the chromebug extensions. This can be most-easily accomplished using the build.xml file provided in the fireclipse/extensions/chromebug directory and the Java build utility ant. If you don’t have ant installed, you can do this manually as per the instructions in the included readme file. It’s standard extension development linkage.

And now you should be ready to fire it up using (on windows):

Replace firefox.exe with firefox-bin on unixey OSes. You should see two windows open. One, a smaller window with the title Chromebug, the other, a standard browser window. Before you get too excited and jump in, you should quit the application and restart it (again, using the above command) to make sure the chrome files get registered properly. Now you should be ready to play!

Please keep in mind that Chromebug is experimental. There’s a lot of code in there and not all of it’s working. We are interested in getting more people using it and reporting problems though so check it out, and if you encounter any problems, feel free to come to #firebug in irc.mozilla.org and ask questions. You may have better luck using Firebug 1.2 instead of 1.3 currently, but I haven’t tested that myself. It should be a matter of changing the firebug.dir property in the local.properties file from step 5 above.

I’d like to thank John Barton for patiently walking me through the above and giving me a walkthrough of the code itself. It’s incredibly cool stuff and I’d love to see it become part of the standard arsenal of extension development tools as well as part of the toolkit for developing firefox front end features. In the coming weeks, I’ll post follow-ups on the state of chromebug and what you can do with it.

Happy debugging!

Enter WikifyTabs! It does just what we were looking for, creates a blank page and dumps the currently open tabs into it in MediaWiki markup. Pretty simple, but kind of useful. It also fits in with some of the ongoing discussion on Planet right now about how to improve the display and access of tabs. (Aside: I still love ctrl-tab, even though it might get changed before the final version of Firefox 3.1). Imagine a similar list of tabs with functional links in an about:tabs page. I may add that to the extension. Other possible additions include options to produce different types of code or markup, context menus in text areas to insert directly and copying wikified or bbcode links directly from the tab bar to the clipboard.

Oh, and I used Firebug 1.2.0 to help debug my extension. It was finished up by John Barton, Jan Odvarko and a cast of … several others this weekend. We released the final version yesterday and updates should be available through AMO. If you run into any problems, please file an issue on the google code page.

(I would be remiss in not sending special thanks to JOEDREW!, dria, gavin and yes, even kev for helpful grammar debugging of my early morning post)

Speaking of Firebug, it looks like I’ll have plenty of opportunity to play with it now as I’m going to be helping out with that project full-time. I’m really excited to be working on development tools again and already have a few ideas for features or extensions. (Internet-famous) John Resig posted a great article a couple of weeks ago and I’m looking forward to working with him, Jan Odvarko and the Firebug team to make it the awesomest, standards-based web-development tool in the universe. I’m hoping to write another post in a few days about some of those ideas. In the meantime, I have a couple of little patches to finish up before completing the move.

From an organizational perspective, this means I’ll be moving into the Evangelism Team with Mike Shaver and friends. I’ll still be helping field questions about the unittest infrastructure if they come up, but inquiries and bug reports should go to John O’Duinn and his team of Excellent Release Engineers.

Thanks to everyone for making this shift possible and to everyone who sent congratulatory notes. Everyone is Awesome!