Burning Chrome

Venkman planning for Gecko 1.9, part 3

Thanks to Gijs and Mnyromyr (and not to me; I didn't write a single line of code), Venkman's met three of the six bullet points I listed in my initial Venkman planning post. It is now at least minimally useful for Gecko 1.9 code.

I would strongly encourage Firefox developers (and for that matter, most of us who hack on trunk) to launch the JavaScript Debugger at startup (command-line argument is -venkman), and turn on "Stop for Exceptions". You'll find a few pain points pretty quickly. My personal favorite looks something like this:

try {
  var foo = myObj.property.QueryInterface(Components.interfaces.nsIFoo);
} catch (e) {};

This code is wrong, in my opinion, on three levels:

1. The empty catch block, which always annoys me. A comment saying "do nothing" would be better than that.
2. No checking of what e is. In this example, only one line is inside the try block, but you can't tell if the QI failed, or if myObj is undefined. It could be the QI failure is expected, but if myObj being missing is a Bad Thing, that exception needs to propagate.
3. A simple instanceof check removes the need to try and catch. If you can avoid generating an exception, then by all means do so. Exceptions like this are just useless (and probably expensive from a JSENG/XPConnect point of view). Exceptions should be thrown for exceptional circumstances.

var foo = (myObj.property instanceof Components.interfaces.nsIFoo) ? myObj.property : null;

I'm not intending to point fingers, but autocomplete in the URL bar is an extremely visible case of this being a problem for Venkman...

Time is running out for any of these changes we want to get into Firefox 3. If we're fast enough, though, we can clean up a lot of these useless "noise" errors which discourage people from using Venkman - and thus make exceptions it catches more relevant to whatever problem the user is debugging.

Thanks!

Venkman planning for Gecko 1.9, part 1

Over the last couple years, the Mozilla code base has evolved significantly on the trunk. Unfortunately, development on the JavaScript Debugger has not kept pace - the code has "bitrotted" significantly, and introduced significant bugs.

This is a serious problem. It's equally serious that no one is hacking on it. I've found it to be a very useful tool for working on chrome code, and XULRunner apps would benefit from having a debugger handy.

So here's what I want to do. I want to schedule a weekend meeting for 2 pm PDT Saturday at #venkman on moznet. The goal, as I see it, is to plan fixing Venkman so it is usable on the XULRunner 1.9 platform. (Getting it working on Firefox 3 would be a nice thing, too.) I want to see who's willing to contribute hours (weeks, more likely) of coding and/or reviewing to this goal. In particular, I'm worried about trying to find out whatever API changes are needed in Venkman itself (not what API Venkman has to call) and getting them in before 1.9 branches.

Watch this space for more details; I'll write up a draft plan for the meeting, so we have some things to think about.

UPDATE: So, here goes:

First thoughts - Venkman isn't quite as bad off as I initially thought. I tried to install a 1.8-based XPI on the 1.9 XULRunner build, and that didn't work very well at all. When I finally figured out how to build a Venkman XPI:

export CONFIGDIR=(...)/mozilla/config/
cd mozilla/extensions/venkman/xpi/
sh makexpi.sh

Everything seemed to be okay. Starting Venkman via window.open("chrome://venkman/content/", "_blank", "chrome") works. But it doesn't take long to notice a few oddities.

• I don't have a main toolbar, where the "Play", "Stop", "Step" buttons used to be. (Though I do get them starting with -venkman in the command line.)
• Switching from Breakpoints to Call stack panel (lower left corner for both) doesn't work. None of the two-tab tabboxes let me switch to the second tab.
• The error reporting still gets the line number wrong by one. (This is probably a JavaScript Engine bug.)
• It's still a little crash-happy. I've crashed twice in only a few minutes.
• Venkman (as it always has) has a max of five source code tabs open at any given time. On Linux, if the file where you hit an error isn't one of them, you don't even see the source where it fails.
• Building Venkman in the tree doesn't produce a working debugger for XR apps - you need to drop a XPI into the app's Addons Manager.

Ultimately, I think these are all fixable. The real problem, as I mentioned earlier, is a lack of current contributors. Venkman, like Inspector, has been neglected for quite a while. There are 136 open bugs against Venkman right now. (Inspector's been doing much better lately.) Looking at extensions/venkman/resources/content/ right now, there are a lot of "2006", "2005", "2004" files... meaning that exactly one file has been touched here in over eight months! 136 bugs + eight months bitrot means an effectively unowned module - or a super-stable, frozen one. :-) Given the fact this is on trunk, and the above very-obvious bugs, I'd say it isn't the latter.

So here's what I propose: for 1.9.0, we need two or three chrome app experts to spend a few days fixing the above issues, and reviewing patches. Next, we need to go through the bug list and triage it, both for priority and time constraints. If there are any IDL changes needed, those should go first in the bug list because we'll have a harder time getting such changes in 1.9.1. (There aren't likely to be very many.) We should start planning for 1.9.1 - whatever it is - right away. For 1.9.0, I think we're effectively in maintenance mode - there's too little time for big changes.

If we somehow find the time, (i.e. we decide that all the high-priority, low-risk issues have been fixed, and we don't want to chance further 1.9.0 changes), we should probably write a miniature XULRunner app with a known set of bugs and start running Venkman against it. This becomes a "reference" application for Venkman testing.

Reviews for new patches should emphasize both tests and JavaDoc'd functions. I'd love to see some xpcshell tests of the jsd code which Venkman depends on.

We need to start putting out "nightlies" of Venkman, and making them available for trunk usage. The simplest way to do this might be a bit of tinderbox adjustments. Fortunately, building a Venkman XPI takes only a few seconds.

So who's willing to spend time on this? The good news is that Venkman's code is mostly XUL + JS, so you don't need C++ hacking skills to fix many of the bugs against Venkman.

Jules Verne time

(As in, "From the Earth To The Moon".)

So the Mozpad group has started, even though we don't have all our goals figured out yet. I think overall the group has gotten a pretty good response, much like SeaMonkey did when they first started out. But we're not out of the woods yet.

With the creation of moon.mozpad.org, I'm going to need a bit of help creating a RSS feed for them. I'll be creating a new category on my blog, "XULRunner thoughts", but unfortunately, I don't know enough about MovableType to create a feed template for a category. So if anyone out there can lend a hand (or better yet, some markup template with instructions on where to put it), I'd appreciate it. Other MZ-hosted bloggers might like it too.

One of the proposed goals for Mozpad is to figure out some basic requirements for a successful XUL IDE project. (No, we're not committing to building the IDE yet. That is a Really Hard Problem.) So when we do get a Mozpad newsgroup, I'll be starting a newsgroup thread to ask what the community thinks they need. (Please don't post replies to this blog entry; I just want to start people thinking about it.) Even so, we're going to need a leader to gather the feedback and process it into a coherent requirements specification. No one's stepped forward to champion that goal yet, and understandably.

I think, realistically, our goals for Mozpad are -- and should be -- shorter-term ones - somewhere around six months. Longer-term goals we do not want to set for ourselves, as we're just starting out. We need to crawl before we learn how to walk, as the old saying goes. Everything on the goals list is achievable with a little effort, and would net the community-at-large some tangible, healthy benefits. So if you can spend a couple hours a week on one of these subjects and it interests you, we could use your help as a champion, as a leader.

Finally, I'll continue to put all my posts through planet.mozilla.org, even though the XULRunner-specific posts will also be on Mozpad. It's just another step on the way to Florida, with a really BFG, pointed at the moon. Cover your ears, folks, it's going to be a doozie.