Gecko 1.9.1, TraceMonkey and Venkman?

I admit, I’m pretty blown away by the TraceMonkey announcement. I’m envious. I’m still trying to get my company onto Mozilla Firefox 3 code…

That said, one of the biggest questions with JIT compilation of JavaScript that I’ve had for months is, “How are we going to debug JavaScript now?”.

It probably doesn’t help that Venkman didn’t make it into hg.mozilla.org. I think that was intentional, and I don’t dispute it. Still, with Gijs Kruitbosch on vacation, there’s not a lot of people to maintain Venkman (we’ve been down this road before).

Perhaps the right answer with TraceMonkey is to let Venkman die.

Note that I don’t suggest this lightly. Venkman nearly died once with 1.9, and has been on life support for years anyway. With Mozilla 2 breaking backwards compatibility in interfaces – and Venkman left in the dust, not even having automated tests for it (any tests at all?) – by the time we get around to bringing it up to 1.9.1, we may find it simply cannot work with TraceMonkey.

So I’d like to start a general discussion on what sort of JavaScript debugging tools we can craft for Mozilla 2.0. I really, really do care about this – without a good JS debugger, I may be dead in the water for a lot of what I do. (If I’m forced to use and learn DTrace for debugging JavaScript, I’d really like to apply it to a XUL app that can do the work for me.)

Comments are open. Please serious commentary only, not “I want this feature!”. I’m trying to find (and join, and participate in!) a group of people who can spend the time on researching & implementing a solution.

Regular expressions: Editing in a grid

This is for you, glazou, and your Diavolo editor. (Though I wrote it for Verbosio as well – I need it too.)

As I started my vacation, I was thinking, “I’d like to edit regular expressions in Mozilla. But I don’t want to edit one at a time. I want to edit a bunch, and see what they all do to a bunch of text.”

So in four late-night hours, I put together a simple XBL binding to help me do just that:

Each keystroke updates the table. When a regular expression is not well-formed, it disappears (and the results fields under it). When text and regular expression don’t match, the cell they share goes blank. The rest of the UI is, I hope, fairly self-explanatory for anyone familiar with JS regexps.

Yes, I know it’s not localized, and it’s not pretty. It’s functional, though, and for proof-of-concept code, that’s all I care about.

You may also notice this is on the new hg.mozdev.org repository. I’m in the process of converting over from CVS to Mercurial, and doing some other clean-up as well.

Cool tip of the day: Where in the DOM is your mouse?

What, elementFromPoint isn’t good enough for you? Well, in my case, no. For Verbosio, it would help a great deal to convert a mouse point to a DOM range point (think scripted selections, drag & drop like Pencil does, etc.). DOM ranges form, among other things, the basis for Mozilla’s selection algorithms.

Fortunately, there’s a way to figure it out. Just ask the mouse event for the range coordinates. Literally.

window.addEventListener("mousemove", {
handleEvent: function(aEvt) {
this.rangeParent = aEvt.rangeParent;
this.rangeOffset = aEvt.rangeOffset;
}
}, true);

This comes to us courtesy of the nsIDOMNSUIEvent interface.

The funny thing is, I knew about this back in 2002, when I was writing my book for Sams Publishing. I forgot about it sometime over the past six years (and I admit now that the book’s been only partially useful since then, missing certain bits of info I would’ve liked to know then).

Now, imagine using this to give a visual indicator where a given element you’re dragging will be dropped in a HTML or XML document…