With XPIDL, XPCOM components can be very strict about what they allow.
Simply put, if you try to pass in an argument to a XPCOM component, and the
component requires a type that your argument doesn’t support, it won’t work.
In C++, your program won’t compile; in JavaScript, XPConnect throws
exceptions. This is a good thing.

Many of the basic data structures – nsIArray, nsIPropertyBag, etc. – take
a nsISupports argument. This covers most objects you construct
and work with. This is all well and good… unless you want to pass in a raw
type such as a number, a true or false value, a
string, etc. Then you’re stuck.

Fortunately, all is not lost. There is an interface named
nsIWritableVariant, which XPCOM provides for wrapping native
types in an nsISupports object. (There are type-specific
interfaces like nsISupportsPRBool as well, but
nsIWritableVariant is an one-size-fits-all solution.) Even more
interesting, its read-only companion, nsIVariant, is “magical”
to XPConnect: JavaScript receives its values as native types, not as
nsIVariant objects.

Thus, nsIVariant turns the strengths of XPIDL barriers so
that they are no longer fighting you, but working with you. This is what I am
calling judo with nsIVariant. Read on in the extended entry for more details.

Continue reading Back to Basics: Judo with nsIVariant →

A couple weeks ago, I started reading “Learning Python”, by
Mark Lutz. It’s an interesting feeling, going back to the basics of
programming – numbers, strings, arrays, etc. In reading this book, I kept
thinking there were some things missing from the basic XPCOM tool set.
Therefore, I decided to attempt implementing these missing pieces.

Now, I could be totally wrong about any or all of these being missing…
but it’s also a good exercise for me to push my boundaries and strengthen my
C++ skill set. The result is not only code that I can use for
proof-of-concept, but code that may be useful elsewhere.

This is the first article in a multipart series titled “Back to Basics”,
exploring these concepts. This first article is about native C++ arrays
through XPCOM – and making sure I don’t leak memory. Read on in the extended
entry for details.

Continue reading Back to Basics: XPCOM Arrays and Memory →

I love XUL trees. I even
smoke them
from time to time.
But what I don’t like is trying to build a hierarchy of objects in them – even
though that’s probably the best use for them.

Imagine that you want to show this tree of objects, with properties of each
object horizontally, and the objects themselves laid out vertically, indented
and illustrated to show which objects have which parent objects. DOM Inspector
does this with DOM nodes all the time. My chrome registry viewer code does
something similar for files (file systems are tree-like), and when you want to
see the properties of an object, JS object inspection is usually through a tree.
Even Venkman uses trees to show you functions in a file or webpage.

Still, for every different object tree I’ve come across, there’s a
different view that has to be built. Usually it’s custom-built for that tree.
So you’ve got two options: build your own view, from scratch, every time… or
build a XUL tree DOM and let Gecko’s own tree utilities show it to you.

Believe it or not, I’ve tried both approaches… and finally decided to
roll my own baseline solution. (If someone else has done this before, please let
me know. It’s best to have this in a common place.) More details in the extended section.

Continue reading XUL Trees and Objects: ClassTreeView →

For years, I’ve tried to answer a simple question: How do you show the same data in two places at once, in Mozilla? In particular, DOM nodes. The simple answer is to clone the data you have in one location, and place the clone in another. This is not enough when the data changes in one location; I want it to change in the other, too.

Possibilities include:

• A split view of the same document, particularly for editing
• My latest attempt at a scrollable content object model (XBL at work, again)
• Correcting markup in one section of code, and having it update a dependent section later automatically. Think slide shows, where two slides are nearly identical – and a semantic relationship exists between them. Also think steps of a theorem proof.

An ideal solution might involve a special layout frame for transposing the data, but that’s more work in an area I’m unfamiliar with. A solution I can do (more expensive memory-wise, but at least workable) involves setting DOM mutation listeners. Read the extended entry for more details, and a ZIPped source directory for my own synchronizer – if you don’t mind some technobabble.

Continue reading Beyond clones: synchronized DOM nodes →

Components.Exception on LXR

A long-standing custom in Mozilla code for XPCOM components in JavaScript is to throw Components.results.NS_ERROR_FAILURE or something like it

. However, Components.Exception is more useful, particularly since it lets us component authors define our own error messages to go with the error code. Plus, it’s been around for quite a while.

It’s actually pretty useful, I’ve found. I’m wondering if we should add this to a list of to-do’s for Mozilla 2.

Updated

I spent another six hours on this, and I’m fairly pleased with the results. The bulk of the code is now in a new SnapGrid.js library file

. The features:

• Keyboard- and mouse-driven commands
• Step-by-step defining of an object (in this case, a line)
• A semi-generic, objects-within-objects library design. (Doing it right is much harder than it looks, and I’m pretty sure I’m not doing it right!)
• Of course, a nice big grid, and a nice big dot showing you where the snap-to-grid will snap to.

It’s another proof-of-concept, but this time for something much smaller than Verbosio. Hopefully, if I’ve designed it right, I can rapidly expand it to cover other shapes and, more importantly, the SVG path element…

Last night, I was thinking I’d really like to have a JavaScript-based SVG editor. There are some really freaking sweet examples out there. But there’s something missing from all of these, which surprises me in retrospect: SVG snap-to-grid support.

Freehand drawing is nice… unless you want precision. Sadly, the human hand (mine, at least) isn’t that accurate with distilling individual pixels. If I can get close enough with the mouse on a zoomed-in view, though, and I can see a grid indicating pixel coordinates, maybe the application can round off my mouse position to the nearest real point, and give me a visual indicator

. Like this snap to grid example, which I put together in about two hours.

Right now, if you load the example, you can place a point by hitting a key on the keyboard. This is in keeping with the idea that controls should be accessible without the mouse. Unfortunately, I haven’t gotten into maneuvering points with key strokes. Nor have I factored in any kind of zoom & pan capabilities – linear algebra is not one of my strengths.

Over the next few days, I hope to turn this code into an actual class, similar to a Dojo-style library. I might even make it a XBL binding. Ultimately, by being able to precisely identify coordinates, I could plug coordinates directly into shapes such as SVG paths (Bezier curves made simple), rectangles, ellipses, etc. I could even build interfaces to create classes of polygons. (I want my <svg:triangle/>!)

You might wonder why I’d work on yet another SVG editor, when there are so many out there. There are two reasons. First I didn’t see any examples that would really be compatible with running inside a Mozilla framework, besides the ones above. They’re usually stand-alone apps. The examples above are exceptions to that rule, but (this is the second reason), the first two are not explicitly licensed under an open-source software license (no explicit license, and Creative Commons, respectively). Mark Finkle’s work is under the MIT License, but it’s HTML based. Nothing wrong with that. It just strikes me as unnecessary if the only platform you’re targeting is Mozilla. Mark’s targeting IE, too. My use case is simply different.

On the other hand, if I keep it as a JS-based constructor (instead of XBL), that would make it easier to port to other platforms, such as RichDraw.

Food for thought.

With many thanks to Dave Townsend and Robert Strong for reviews, Mozilla trunk builds now support extensions for “the toolkit” – meaning any XULRunner app which uses the toolkit. This will also be true for the next milestone, and (barring something really unusual) Mozilla 1.9 and the next major XULRunner release.

I can think of several extensions which would be good candidates:

• Bug 342592 – DOM Inspector (FIXED)
• JavaScript Debugger (Venkman)
• JSLib
• Bug 312970 – XForms
• Chatzilla

The bug for DOM Inspector has a pretty simple example of how you’d add support for the toolkit to an extension. It’s less than ten new lines, added to install.rdf.

There’s also a nice side benefit possible here: extensions for another application – say, Songbird – which don’t need to be for just that application could port easily over to Firefox with the toolkit target.

So what determines if an extension should be for “the toolkit”? First, you need module owner or author’s approval for that extension. 🙂 Second, it shouldn’t be specific to a given product or written for a given application – for instance, an extension for browser history doesn’t qualify. On the other hand, if it adds more tools (a new SQLite database, for example, or a spell-checking dictionary – thanks for the idea, KaiRo) or capabilities without requiring that the app be a browser, a mail client, a multimedia player, etc., then it should be fine.

I’d invite fellow developers to start experimenting with this, and generate feedback. Any bugs to add “the toolkit” as a supported application should be marked as depending on bug 299716. Also, any other missing support for toolkit extensions we need bugs on, depending on bug 299716. We need eyeballs!

P.S. Congratulations on document.elementFromPoint(x, y), Mr

. Karel. That’s very useful, too.

After eighteen months of “try, try again”, the first version of XPath Generator code has landed in Mozilla 1.9 “trunk” code. It is currently off by default.

I’m quite pleased with this. This is the first complete feature I’ve driven from initial API drafts to a final implementation in Mozilla CVS.

So how do you use it? First, you need a build with ac_add_options -enable-extensions=default,xpath-generator. Once you have it, your chrome code should be able to call:

var generator = new XPathGenerator();
generator.addNamespace("html", "http://www.w3.org/1999/xhtml"); // optional, but recommended
var xpath = generator.generateXPath(targetNode, contextNode);

nsIXPathGenerator details two currently supported flags for the generator’s searchFlags property

. IGNORE_ID_TYPE_ATTRS means that the XPath should not stop when it finds an ancestor with an ID attribute. USE_DESCENDANT_AXIS produces a single-step (in the case of attributes, double-step) XPath beginning with descendant::.

XPath Generator objects also provide their own namespace resolvers, which as I note above can take new namespace declarations via the generator’s addNamespace() method.

Sadly, this implementation excludes support for attributes in the XPath (foo[bar=”baz”]); based on review feedback it didn’t seem necessary for the initial implementation.

So why is this feature off by default? It’s new. Aside from myself, I don’t know anyone actively using my XPath Generator right now. Because it’s so new and untried, we (myself and the reviewers) decided we should not expose the generator to web pages just yet. For that reason, we left it off by default as well. Finally, because it wasn’t on by default, it didn’t land for the 1.9a7 milestone.

If you are a developer and you see yourself needing or wanting XPath Generator, you have two options. (1) Start playing with it now, and see what improvements you’d suggest (patches welcome). Your experiences with XPath Generator – including actually using it – will carry weight in any attempt to get it approved for Firefox 3. (Popular opinion & votes will not.)

(2) Package XPath Generator as an extension and submit it to AMO, and include it with your own extension as a multi-item package. If you’re going to do the latter, please contact me and let me know. Ideally, it would be submitted only once.

Either way, I really would like to find out how useful you find XPath Generator in your own work.

In the meantime, I need to work on making it and other extensions available to all Gecko-based apps…

Oh, by the way, there’s also a new do_parse_document() function available for XPCShell tests. If you have a particularly slow Mochikit test that doesn’t need a window, you might want to rewrite your test to work using this new function. (Come to think of it, there could be a significant speed-up in total test execution, if we converted many tests and if text/html for DOMParser landed.)

(Now why do my most significant events take place on weekends…)

Scenario: You’re working on a mozilla.org trunk bug, and you’ve got a xpcshell testcase. Great. Except that it’s failing. What you want to do is to set a breakpoint in your C++ code to figure out why the test fails, but to do that you need your debugger attached to xpcshell. Since the xpcshell test harnesses usually run straight through, and run without user interaction, you never have a chance to attach to the right xpcshell.

Until today.

After I got tired of fighting this scenario a couple dozen times, I decided to write a patch which could let you load a given xpcshell test, and manually run the test. Instead of trying to figure out the full list of JS files your test needs, now you can debug the one test.

From your objdir, you run “make SOLO_FILE=(filename) -C (target directory) check-interactive“. This launches xpcshell and loads your testcase. You can then attach a debugger and set your breakpoints

. Example: make SOLO_FILE=test_import.js -C js/src/xpconnect/tests check-interactive

js>_execute_test(); runs the test. (You still need to name your test function in each file “run_test()“.)

js>quit(); exits the xpcshell.

Gory details in bug 382682.