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.

(before proceeding, I should tell you that Johnath has a shell script you can invoke from a terminal window that you might find adequate. The setup is certainly less annoying, but then you’ll have to type something on the command line everytime you want it, and that’s hardly intuitive, nice and it does a funny thing with character-encodings in the filename (edit: this was zsh making the filename look funny, oops, sorry J))

What you’ll need:

• Mac OS X 10.5 (you might get away with 10.4)
• Some kind of web-enabled remote storage (I’m using “people.mozilla.org”, but if you’ve got MobileMe you could do this with an iDisk or some other WebDAV-enabled system)
• MacFUSE + SSHFS
• FastScripts Lite
• Grabup-window-template workflow.

The latter two may have alternatives. I’m using FastScripts lite (thanks for the tip, neilio!) to bind a hot-key to the Automator script, but you could do the same with Quicksilver and probable several other tools. SSHFS is alternatively available in MacPorts, but I like the Google Code supplied version for the handy installer.

The Setup:

First, setup your “web-drive” through MacFUSE. Be sure to install the latest SSHFS binary. Read the instructions. I have mine setup as aliases I can run from the Terminal. E.g.,

Next, you will need to edit the Automator action. Start Automator and select the Open Existing Workflow button.

Open the Grabup-window-template file (extracting it first from the zip file), and change the entries below. I am going to recommend here that you create a throw-away screenshot and put it in a Screenshots subdirectory under Pictures. Name the image “pic.png” or similar. You’re going to need to select something as a filename in Automator’s first action (Take Screenshot). Ridiculous, I know, but here we are.

Next, select your destination in the “Copy Finder Items” action. You’ll want to make sure your remote drive is mounted. If you’re using MacFUSE, drag the drive from your desktop into the sidebar of the Finder so it shows up in the open dialog, alternatively, you can just drag the drive from your desktop onto the open file dialog and you should be able to browse it from there. I have a public_html/screenshots directory, and have selected that.

In the last action you have the option of opening the screenshots directory in your browser. The Run Shell Script action just calls the “open” command which will open a URL of your choosing. If you can do this all by yourself, feel free to delete the action entirely. I give you permission!

When you’re happy, save the automator action as a Workflow in your home directory’s Library/Scripts folder and give it a snappy name. I call mine “Grabup-window”. If FastScripts (lite) is running, it will show up in that menu. Now you can open FastScripts’ Preferences window and give Grabup-window a hotkey. I chose Cmd-Shift-5.

Now, whenever I hit that hotkey, I’m promted to select a window and a screenshot is automatically uploaded to my directory. No more tears. I hope this is useful and not nearly as painful as it has been to describe here.

note, as there are only 86400 seconds in a day, eventually, you will get collisions. You can pick a different rename pattern to make your images last longer, or change the option to overwrite automatically. It’s up to you. YOU HAVE THE POWER!

Update: added an extra entry to the Grabup-window-template file so it now adds today’s date to the beginning of the filename. No more collisions.

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!

* assuming Nothing Bad™ happens

In other news, Axel Hecht submitted a nice patch for the TinderboxPoller in our local copy of Buildbot. I snuck that in too.

Thanks guys!

The background: John Resig did some great work building a new test suite for a recent cut of the MochiKit test suite to run under mochitest (bug #379506). Shaver popped into #developers the other day and said something along the lines of, “could you help John with this review? KTHXBYE” Naturally, I said, sure!

I downloaded the rather lengthy patch and applied it to a pair of trees, did a build and ran runtests.pl. The new tests ran through flawlessly and, seemed ready to go after a quick update to a makefile that was out-of-date. I landed the patch.

And set the tree on fire. (linux, specifically)

Now a word about case-sensitive (or case-”preserving”) file systems. Mac and Windows (HFS and NTFS respectively) are not really case-sensitive. They will let you put differently-cased characters into file and directory names, and they will show them to you, but they don’t really know the difference between Mochikit and MochiKit.

Not so with Linux’ various UNiXey filesystems.

After excising the error in the Makefile, the redness and swelling cleared and Linux builds started happening again. Unfortunately, and this is where I ask for help, the MochiKit test suite didn’t run on Linux. The only info we had to debug it with was a cryptic:

*** 3605 INFO Running /tests/dom/tests/mochitest/ajax/mochikit/test_Mochikit.html…
*** 3606 ERROR FAIL | Test timed out. |

The MochiKit suite is still in there, merely removed from the Makefile for the time-being until we can figure this out. Astute readers might look at the above filename, and think, “hey, there’s a lower-case ‘k’ in there.” No luck, that’s the filename. I tried increasing the timeout on the tests with the very busy Rob Sayre’s instructions with no luck. Attempts to run the suite on a local Fedora Core 6 VM provided no help, failing to run MochiKit the first run through, then passing it on a subsequent run.

Apologies to Robert O’Callahan (roc) and the sheriffs for leaving the Linux machines in that state of orangeness overnight.

PS, Lesson learned: Check Linux first.

I saw this note on Schrep’s blog this afternoon and remembered, that last week was actually kind of a milestone for me. With dbaron’s help. I made my way onto a 4-digit bug – the venerable #3247 – counters in css-generated content.

David Baron wrote the original tests (which you can see at http://dbaron.org/css2.1/tests/imported-20050702/ if you’re so-inclined). I wrote a little python to convert the tests into something that could be run with reftest a few months ago. I was looking for something to use with it and they seemed like a worthy candidate.

Fast-forward to last week, and TimR asked me about those tests I’d converted. So, I dug ‘em out, popped them on my people account and forwarded a note to David. After some cleanup (there were a couple of errors in there that my conversion conveniently included for us), they are now living happily at in http://lxr.mozilla.org/seamonkey/source/layout/reftests/counters/. You can see their results running on every checkin on the Firefox Tinderbox page.

PS, kudos to Kray2, Nickolay, Callek and others for the “Creating Reftest-based unit tests” page on MDC.

Technorati Tags: Code, Firefox, Quality, Testing

You can see the results reporting to the MozillaTest tree on tinderbox.mozilla.org. Currently, the two operational buildbots are “linref test” and “winxp test” (don’t worry, I have an exciting naming scheme all picked-out and ready for action – stay tuned!). Check out the logs for examples of what the make check, reftest and mochitest reports look like. If winxp is orange or burning, it’s because we still have a couple of issues to work out. Some of the reftests are failing on that platform and dbaron is writing a modification to the manifest language so we can mark individual tests as failures on specific platforms. The other, more troubling bug is a debugger prompt I can’t seem to get rid of. Neither setting XPCOM_DEBUG_BREAK to “warn” nor adding a registry entry for windbgdlg (thanks timeless!) seemed to work. I’m hoping the problem will just go away with the addition of more RAM, but that seems unlikely.

On my todo list, I have some work to do to get the different tests reporting rolled-up stats to the tinderbox. We’ll be able to see why a tree is orange instead of looking through the full logs. There are a couple of little profile writing things I can make better. At some point, soon, I’m going to work with Bob Clary on getting the JS tests automated and reporting under this system. Then there’s going to be some work getting Alice Nodelman’s performance testing framework running under it and reporting to the tinderboxes. I’m also trying to setup a leak-testing build to replace the Tinderbox that just stopped working and weaseled its way to the front of my to-do list. Ultimately, I’m hoping we can have these on a more visible tinderbox, but they need to be stabilized first. Oh, and I need to check these configuration changes in and flesh out the very skimpy docs I wrote while putting this together.

Whew, this blog post would’ve been much shorter if I’d just written it last week when I had that one little picture.

Hopefully, having regularly running and reporting tests will encourage developers to write more of them. Individually, unit tests are tiny and kind of uninteresting. When you’ve got thousands of them running constantly though, then you’ve got something.

PS, special thanks to everybody who helped out along the way to get this stuff running. To the IT crew (mrz, justdave, aravind, justin, …) for putting up with the constant bug-filing back-and-forth for VMs I needed or VMs I’d busted, the tireless efforts of the build team (Rob Helmer and J. Paul Reed) taking time away from their real jobs to setup the linux reference VM, Rob Sayre and Dave Baron for their excellent test frameworks, Jeff Walden for the js http server, Ben Hearsum for his buildbot work and Dave L. for getting the ball rolling many months ago. All the developers who wrote tests… I’m being played off the stage… thanks Mom!

Technorati Tags: Build, Computing, Firefox, Software