XUL, XBL, JS and DOM

R.I.P., Venkman

13 Comments

Almost four years ago, I tried to rally an effort to keep Venkman, ye olde JavaScript debugger, alive. It has been on life support since then. The only people currently working on the code are Gijs Kruitbosch and myself, to my knowledge. For all intents and purposes, I believe the two of us are the current “owners” of Venkman, by default.

Soon, the new “JSD2” JavaScript Debugger interface code will land on mozilla-central. (By “soon”, I mean probably by the end of the year.) When Firebug moves to JSD2, JSD1 (which Venkman relies on) will be deprecated and eventually removed. This would be the final nail in the coffin for Venkman, and it’ll be time to bury it.

Now, I need a Venkman-like tool regardless, and the UI as it was presented to the end-user was fairly well defined. The problems I had were really about how to make improvements on an architecture that’s over ten years old and has been abandonware for years. When
I need something and no one else is building it, I’m likely to build it. So I’d like to start a new project that looks like Venkman, but works with jsd2 and has a clean, truly XUL-based UI implementation.

The biggest problem we face, by far, is a lack of available developer time. I have a full-time job and I’m about to start college (more on that in a separate blog post). Not to mention a little pet project that I’m obsessed about. To pull this off, we’re going to need some help, particularly from competent JavaScript authors. Previous experience in Mozilla UI hacking not required – I’ll be very happy to teach XUL & XBL to anyone who would offer significant help.

I’m looking for volunteers to help me kick-start a new Mozilla Debugger Developer Community. Who out there is interested?

(P.S. The company I work for is looking to hire developers who are familiar with FF extensions. For anyone who’s not experienced enough, a project like this is a great way to get into the field… )

Technobabble

Make: It isn’t just for files

This weekend, I took a special break and headed over to the Maker Faire at the San Mateo County Event Center. In some ways, it was both entertaining and shocking (in a good way).

Highlights for me:

  • Meeting David Brin and getting his autograph on “Foundation’s Triumph”
  • Mike Rowe and Adam Savage taking questions (that they’ve probably answered a couple hundred times already)
  • Another musical artist, with the “Slaperoo” (warning: site plays sound right away on load)
  • The incredible amount and quality of stuff being built by hobbyists these days
  • A little story about who exactly made the Apollo space suits (it’s not who you might think!). (The site is down right now.)
  • Eepybird. Nuff said, except that they’ve switched to Coke Zero.
  • The large variety of very cool tee-shirts. I’ll be ordering another one very soon, based on a card I picked up earlier today.

About the only thing missing is an appearance by the Blue Man Group, in my opinion. They would’ve found some neat instruments to add to their collection. Oh, yeah, they’re coming to San Francisco, starting Tuesday. 🙂 I’d love to have some fellow Mozillians join me for that one. Anyone interested, we’ll do a get-together and buy some group tickets.

Technobabble

db48x, aka Daniel Brooks, joins APN

1 Comment

Just a quick note from my Batcave: I’ve got a new coworker, a fellow Mozillian. His name is Daniel Brooks, and he’s just moved to the SF Bay Area. He doesn’t have a Planet Mozilla blog, so I decided to announce it for him. 🙂

I’ll have to convince him to talk about some of what he’s done for the Mozilla community. It’s a pretty long list.

XUL, XBL, JS and DOM

Paired methods (start*, stop*) are a bad idea

3 Comments

By paired methods, I mean a pattern like this:

manager.startWatching(node);
doSomething();
manager.stopWatching(node);

In pure JS land, this is unnecessary. If your API requires both the start and stop methods execute, around user code, your API is fragile. You might require customers to call both startWatching() and stopWatching(), but you can’t guarantee they’ll do it. It’s far better to have a single watcher method which takes a callback function:

manager.watchObject(node, function() {
doSomething();
});

The watchObject() can guarantee both the start and the stop methods execute, even in the face of an exception from the callback, with a try… finally statement:

watchObject: function(obj, callback) {
innerManager.startWatching(obj);
try {
callback();
}
finally {
innerManager.stopWatching(obj);
}
}

This blog post isn’t a rant against any Mozilla code in use, specifically. This is something I realized when working on my own pet project.

Though to be fair, a lot of XPCOM code requires this pattern – SAX, TransactionManager’s batched transactions… it’s kind of annoying. The only current solution for this would be to introduce a callback interface, with a single method and “function” defined in the interface attributes:

[scriptable, function, uuid(...)]
interface nsICallback : nsISupports {
void callback();
};

Technically, you could reuse nsIRunnable for that, but that violates the intent of the interface. Somehow, I don’t think we’re going to see that pattern introduced into the Mozilla code base anytime soon, even as a new XPIDL argument type. (“lambda”, bsmedberg?)

UPDATE: John J. Barton raised an excellent point in comments: that if the start method and the stop method are from two separate user interface events, such as a start button and a stop button, then it’s appropriate to have two separate methods. I wrote this article in the context of a single event triggering both.

Editorials

Do you have a tech hobby that needs some love? Let me know!

3 Comments

I’m thinking about scheduling a week-long retreat in July for a small group of techies – say, six to ten people.

In past years, I’ve found that a week at OSCON was some of the most fun I’ve had – particularly being around lots of high-powered brain talent. It wasn’t so much that their fields paralleled mine – far from it – but the inspiration of seeing what others can accomplish has usually propelled me to some of my best moments as a tech myself.

So that’s the why. Get a whole bunch of bright people together for something other than their day jobs, and interesting things begin to happen. An informal brain trust, basically.

I have my own tech hobby, but I work on it alone. I’m not asking for help on it, but I am asking if there are other people like me in the same situation. Here’s what I’m suggesting, in concrete terms:

  • People involved (this means you!) must have a hobby involving technology.
  • That hobby must not be their day job!
  • People involved should be able to commit one week’s vacation time.
  • They must be willing to spend that week around ten to twelve other tech hobbyists, in a relatively small space – say, a large conference room.
  • They must be willing to spend that week somewhere away from home… say, Napa wine country
  • They must be willing to work extensively on their hobby during this week.
  • They must be willing to talk about their own projects – and to listen to others talking about their projects.
  • They must be willing to take some time as regular vacationers… say, a trip around the vineyards in Napa Valley. 🙂
  • They must be willing to have fun!

If there’s enough people interested, I can try to set up a “Week For Hobbies” tech retreat somewhere. If I get a lot of people, I’d probably go so far as to invite a couple students (who may not have hobbies yet, but an interest). Talk to me in the comments!

(Also, if you have blogs that are syndicated to other tech Planets than Planet Mozilla, feel free to post links to this blog where others will see it. I specifically do not want this to be a Mozilla-friends-and-family-only event!)

Technobabble

Gonzo programming (or “Fear and loathing in JavaScript”)

A few months ago, I took my ideas about DOM bindings and aggregation by proxy (I really should’ve called that “mix-in by proxy”), and started writing something… a little wild. A little out there. Of course, it’s not finished yet – very few great things in software ever are – so I still don’t have anything to show for it. (I will, though… I’m planning on posting a FF add-on demonstrating my work here, in miniature.)

In any case, with what FF4 betas gave me earlier, I kept thinking of where this was all going, and I realized the best way to say it was to “borrow” the words of Hunter S. Thompson:

“I had two bags of hash… sixty four bits of desktop machine… five sheets of high-powered design notes… a saltshaker half full of membrane… and a whole galaxy of multipurpose strings, numbers, booleans, functions… Also, a quart of tests, a quart of make, a case of select, a pint of raw pointers, and two dozen cookies. Fig newtons. Not that I needed it all for the hack, but once you get hold of a serious tool collection, the tendency is to push it as far as you can.“

And yes, I do need somebody to love… (warning: NSFW @ 1:50)

Continue reading Gonzo programming (or “Fear and loathing in JavaScript”) →

Editorials

We are still here!

It’s kind of amazing to think about all the people who’ve been with the Mozilla project for a very long time. For me, I also take note that I’m now a member of that group – maybe not the respected (and very competent!) elder that Mike Shaver, Boris Zbarsky or even Brendan Eich are, but still someone who’s been around the block a bit.

Specifically, for ten years now. On March 4, 2001, I filed my first Bugzilla bug. I don’t remember whether I was working on my book at the time, or if I was just tinkering around with JavaScript, but I do remember that zeal I had – because that zeal has never gone away. The feeling that says, “This is just wrong, we should fix this.” I still get that feeling quite often, though usually more about my code than Mozilla’s. (I love our automated testing frameworks, by the way… they make it much easier to have confidence in code I write!)

Of course, I filed a lot of bogus bugs back then, by which process I learned the hard way about reading specifications, and that specifications are often “wrong” (incomplete, useless, or impractical). I also learned the hard way that I’m even more often wrong. It’s why I started saying three months later, “The first step in confirming there is a bug in someone else’s work is confirming there are none in your own.” (June 30, 2001, if anyone’s curious.)

If I had to summarize the most important thing I’ve learned over the last ten years, it’s that. Sure, there’s a long list of technologies, but it’s that human factor which is biggest. In simple language, the quote means “make sure you’re right before accusing someone else.” In Biblical language,


Why do you notice the splinter in your brother’s eye, but do not perceive the wooden beam in your own eye? How can you say to your brother, ‘Let me remove that splinter from your eye,’ while the wooden beam is in your eye? You hypocrite, remove the wooden beam from your eye first; then you will see clearly to remove the splinter from your brother’s eye.

— Matthew, 7:3-5

Also, the fact Mozilla’s been around for that long is pretty good stuff too. Indeed, we need not fear the machines. I remember that which matters most: We are still here!

XUL, XBL, JS and DOM

Aggregation by proxy, part 1

(I was tempted to call this Integration by Parts, but I think the other calculus fans reading Planet Mozilla would raise a pitchfork or two.)

In my last blog entry, I talked briefly about an idea I had:

Aggregation by proxy, though, means you could daisy-chain several JS objects in front of the original DOM node, in terms of method and property priorities. If you need to replace a binding, you swap out one object in the daisy-chain. No __defineSetter__ mess, though pulling it off will require a bit of custom JavaScript code. I’d love to see someone else write it up for me – I see it as a trivial extension of the forwarding proxy examples.

Okay, it’s not that trivial. But I do believe it’s doable. If you exclude the DOM node and just daisy-chain a bunch of JavaScript objects, you get something like this. (Note this will only work in recent FF4 beta builds.)

Tom Van Cutsem saw my sample this way in an e-mail he sent back:

If that’s the case, I think your code here actually demonstrates two nice use cases of proxies:

  1. it shows aggregation of object properties.
  2. it shows how you can create a “side-effect-free” proxy for an object (or a graph of objects), which provides the illusion of side-effects (adding/deleting properties) to the proxy client without affecting the wrapped object.

I can imagine proxies that support only 1) or 2) to be useful in their own right. It may even make sense to separate out the functionality into two proxies and then chain them together so that we have:
client -> side-effect-free-proxy -> aggregate-proxy -> target

The version I’m posting here has Tom’s annotations in the source code.

There’s room for improvement. This code will work only with pure JavaScript objects, and can violate rules for setters. I’m thinking this design only takes me part of the way there. I imagine aggregation by proxy as meaning “I can combine implementations of two different IDL interfaces into a single callable object”. That means fun with QueryInterface, for starters. I also need to work on a SingletonHandler (hint: I’ve already prototyped that too), so that document.getElementById(“test”) returns me the same object every time.

I’d love to work on this with fellow Mozilla contributors, to build a complete aggregation by proxy script for the DOM. Anyone interested?

XUL, XBL, JS and DOM

A different way to add bindings to DOM nodes – with proof of concept!

2 Comments

Several years ago, before HTML 5 reached its current adolescence, it was in
diapers. There was a sub-specification called Web Forms 2.0, and it included
a
repetition model for blocks of HTML markup. The idea has long since
been dropped from HTML 5 (it’s probably in a landfill with someone’s diaper),
but it’s remained an inspiration (or maybe an obsession!) for me ever since.

Making it work is quite challenging. I think a repetition model could be
very useful for any web page editor – or for Verbosio, my experimental XML
editor. There’s a few drawbacks, though:

  • I can’t use XBL to pull it off. XBL wants me to insert content as
    children of the bound node, and I think that could just mess
    things up badly for CSS. Inserting the anonymous content as previous siblings makes more sense, and is cleaner, both for DOM and CSS manipulation.
  • I can’t use XTF for it. Well, I could, but the code gets very
    ugly. Unmaintainably ugly.
  • I really do need to hide these inserted elements from the DOM, and yet
    show them in layout. This is one of the issues that prevents a JS-based XBL
    2.0 implementation, or a JS-based XBL 1.0 implementation.

Given all that, I finally hit on a solution: copy the DOM. Give one
DOM tree to the primary JavaScripts, and another DOM tree to the web browser.
Unfortunately, I couldn’t copy it just once. I had to copy it several times,
maintaining private copies of the full DOM tree, one for each new “layer” of
bindings.

If all this is boring and you want me to show you something, here’s a
screenshot:

Yes, that’s a chrome Mochitest, with a DOM Inspector window. DOM-I (and the
browser window) sees the “anonymous content” DOM, but all the tests I ran
against the “scriptable” DOM.

Let me play with this!

Okay.

hg clone http://hg.mozdev.org/verbosio --rev 06a72a32d6ec unstable
cd unstable
python client.py --target=floor13 --mozilla-rev=--latest-beta checkout
python client.py --target=floor13 build
. run_bindings.sh

Source code for this experiment lives at

http://hg.mozdev.org/verbosio/file/06a72a32d6ec/experimental/floor13
.

How does it work? Can this be used for XBL 2? What about my own
properties?

Extended entry, please. For those who don’t wish to read on, well,
Happy New Year!

Continue reading A different way to add bindings to DOM nodes – with proof of concept! →

Technobabble

What if we held an Add-On Con at OSCON?

Recently a few of my coworkers visited the Add-On Conference in Mountain View, CA. (I elected to stay behind, and with our schedule it worked out nicely for everyone.) As most people reading Planet Mozilla are aware, it’s an annual event in December, talking about extensions for web browsers.

The Open Source Convention just put out another call for speakers for their July 2011 gathering in Portland, OR. OSCON actually hosts several smaller annual tech conferences as well at the same time. There’s a Python track, a PHP track, a Perl track (they must be planning to write Duke Nukem in Perl 6), etc. There’s even been, from years past, a small Mozilla presence there.

What if we made AOC a twice-annual event, once in Mountain View in December, and once at OSCON in July? I know it’s hard to prep for a conference, that it takes a lot of work to plan a speaking session. I’m just throwing the idea out to see who bites – particularly among those who spoke at AOC this year. On the plus side, if you’ve ever seen Damian Conway speak on Perl… well, it’s a treat.

At least then, a few of us could show up clean-shaven. :-)}}

Alex Vincent’s ramblings about Mozilla technology, authoring, and whatever he feels like.