I must have been asleep at the wheel, again. Last Friday, the XBL 2.0 specification became a Last Call Working Draft.

I’m personally pleased to see the design behind the new <implementation/> element. It would mesh very nicely with my precondition/postcondition article of a few days ago. It would also be nice to have support for <xbl:script/>

. I will probably spend an hour or so reading over the specification in closer detail this week, in particular trying to understand this public/private object stuff.

Two years ago, I wrote an article describing a design-by-contract library for JavaScript. This morning, I realized I wasn’t using it anywhere in my new projects. This really bothers me – a tool that not even the inventor will use?

I did a little thinking, and realized one of the big problems was in object construction, where I literally couldn’t use it. The old DBC-JS file had the approach of requiring users to call a separate function to execute the contract: var root_3 = applyContract(getSquareRoot, this, 3); instead of this.getSquareRoot(3).

Ease of use beats functionality hands-down. Firefox taught us that for user interfaces, and this demonstrates the same for actual code. So obviously I had a design flaw in my design code.

Enter one of the little used features of JavaScript: you can define functions inside functions. The inner functions are treated as local variables. Moreover, any local variables in the outer functions are available to the inner functions.

To spare feedreaders from unwanted technobabble, I’ll continue the rest of this on a secondary page.

Continue reading Design-By-Contract in JavaScript, part 2 →

There’s been a thought rattling around in my brain for a while, but when my hand started hurting a bit today, I thought a bit more.

Many of the Firefox extensions I use don’t have keyboard shortcuts

. Or, for that matter, menuitems inserted by overlay into the main toolbar.

I’m not intending to point fingers (I’m guilty of not considering a11y with tinderstatus), but there are some popular extensions out there that could really use some accessibility love. Including several that I use on a daily (and in one case, hourly or even more frequently 😉 ) basis.

On the other hand, there is the danger of two or more extensions picking the same key combination to do something. I am acutely aware of that problem; I face the same sort of issue at a higher level of magnitude with Verbosio. We might need some kind of functionality through Firefox’s Extension Manager to override assigned alternate UI’s to their core functions. (What to do for extensions missing UI I haven’t figured out yet.)

Thoughts? I’d be willing to design & patch for this, but I want some community feedback (and if I do patch, a general assurance that it will get fast reviews). Is this worth doing? If so, how would you want it to work?

UPDATE: This code has not been seriously audited for security holes, and may introduce vulnerabilities. Also, when I wrote it I did not take into account work on Gecko 1.9. Please be aware this code has not gone through rigourous testing.

Several months ago, I came around with a question: how should I send information from a content page to chrome. I wasn’t able to do it by DOM events as bz suggested, so when I did a little thinking, I came up with a solution for ManyOne Networks, Inc., my employer, that I wasn’t able to talk about at the time.

That time has passed. Regretfully, ManyOne has decided not to release the product I was working on, but they’ve no qualms about releasing the source code behind it

. Including my special message-passing code.

dust-source.tar.bz2 > components/mnIChromeMessenger.idl and components/mnChromeMessenger.js .

How a webpage uses it:

1. You create a JS-based object containing all the data you want passed upstairs.
2. You include a window property, which is the top window you can reach.
3. You wrap this object in another JS object (which I refer to as wrapper), as its wrappedJSObject:

   /**
   * Wrap a JavaScript object for passing to components code.
   */
   function ObjectWrapper(object) {
   this.wrappedJSObject = object;
   }

4. Call chromeMessenger.send(wrapper).

This does some minor sanity-checking on the wrapped object (basically, making sure all but a couple properties are numbers, strings, boolean or undefined), and then dispatches a message to Mozilla’s observer service, with a topic of “content-message”.

Now, it’s entirely up to the chrome and XPCOM code to write observers to listen for this particular topic of message. One idea we had was to use this for opening new tabs by script. You’ll find in the tarball’s chrome/portlets/content/navigatorOverlay.js at line 448 a procedure by which we did this. There are some weaknesses in the scheme (notably, this code can’t be used to directly return a window object of the new browser to the caller, and there’s no concept of tabbrowser’s maximum tab count – thus inviting tabbrowser spam), but overall, it would do what we needed it to do.

Personally, I’d like to see mozilla.org review and adopt this code somewhere – say, in extensions/chrome-messenger, or perhaps in the toolkit if the Aviary or Firefox teams want it. I wrote this code for commercial use, and we tested it pretty thoroughly on our company’s product. It works beautifully.

I’m thinking seriously about submitting a bug to get this code checked in, but I’d like your feedback on where in the source it should live, and who wants this capability. If there’s not enough interest, then I won’t file a bug and we’ll just leave it on the sidelines, maybe as a XPI on addons.m.o.

P.S. This is my 300th blog entry. Nice coincidence that it should be a useful one.

So I got thorougly roasted on my original idea

. Which is actually good, compared to the deafening silence I’ve seen when I post other ideas. 🙂 Believe me, I prefer discussion on my ideas. In this case, it’s helped me abort a bad approach – which is why I post my ideas.

In short, regexps are impractical in the context I had in mind. I refused to give up on this until Daniel Brooks (aka db48x) showed me “the regular expression that parses email addresses”.

So scratch regexp’s.

What I (very roughly) need for XML documents, as I understood db48x’s explanation, is:

1. Support when parsing the source of the XML document for start and end points in the source text corresponding to the XML tags & attributes of the document.
2. An algorithm for converting those boundary points into their equivalent contentDocument-in-the-text-editor boundaries (which would be much easier if I store the boundaries as line number + column number)
3. A way to specify the classes for each set of boundary points
4. A way to specify the CSS stylesheet for each class.

I was very concerned about performance, but apparently that’s a non-issue.

The first and third items on the list involves probably some XML parser hacking. Of course, I’ve never hacked our expat before. 🙂 The second item is straight mathematics. The fourth I could probably just apply to the editor’s contentDocument, or perhaps hack nsPlaintextEditor to support nsIEditorStylesheets.

For other types of source code (such as C++, JS, etc.), I’d need the same types of constraints as for XML, but not the same constraints. Some way to create a common set of XPIDL interfaces would really be cool, but I’m not at that stage yet. I’m still in the brainstorming-and-learning phase. (Maybe working backwards, from end-of-document to start, may mean not recalculating for offsets and new DOM nodes as iteration continues.)

Here’s the transcript of our conversation: #developers @ irc.mozilla.org on syntax highlighting

As always, your feedback in helping me clarify and organize these thoughts is welcome – as long as you’re informative. (I can take rudeness, but not without references to back it up.)

Let’s face it: when you’re editing plaintext in Mozilla, you don’t get any nice text highlighting. It’s just not supported. Having edited raw text (XML documents, JavaScripts, CSS files, you get the idea) many times, I’ve often wanted some support for syntax highlighting, in a simple but very flexible way.

There are really two parts to the problem: (1) Figuring out the method by which text is highlighted (or otherwise “styled”), and (2) Figuring out how to determine the groups of text which are highlighted.

Call me crazy, but the second part I feel can only be answered by regular expressions, like ECMAScript’s.

One idea I had involves reusing the CSS stylesheet mechanism, and a new Mozilla-specific CSS selector (which no one’s proposed yet):

-moz-regexp("/foo/") {
color: #ff0000;
}

The above stylesheet would be applied to a <xul:editor type=’text/plain’/>’s content document, and through some internal magic, would apply the CSS rules to the appropriate text.

Another, somewhat more convoluted, would involve implementing a new XPath function regexp-match("/foo/"), and XSLT stylesheets to transform the source text into a HTML document, similar to what XML pretty printing in Mozilla does. Then use a <xul:editor type=’text/html’/> to display the document for editing. When practical, the editor would grab the post-processed + edited text and re-run it (or at least the changed portion) through the XSLT stylesheet to re-highlight the changes.

A time delay to allow the user to finish typing before repainting the screen would be entirely acceptable. When you factor in DOM mutation events, it’s practically a necessity.

I’m wondering how in the world to do this

. If someone could write up a proposal on doing this, it’d make for a really great feature for Gecko 1.9. Any Summer of Code ’06 takers? Anyone else willing to do this?

Does anyone understand what I’m talking about here on the technical side? 🙂

UPDATE (at 3 am) : Okay, I just had a nice 45 minute discussion with Daniel Brooks (aka db48x). Combine that with comments 2-4 on this blog entry, and I’ve got some rethinking to do. New blog entry coming with Daniel’s conversation post-cogitation. In the meantime, your comments are still welcome. (For those of you wanting to preview the conversation, find some #developers moznet logs, roughly from 2:00 am to 3:00 am Pacific time, 06 May 2005.) For now, I’m going to sleep.

I’ve often wanted to set one attribute on a XUL element and have that forcibly disable all the descendants of the XUL element at once. Given:

<xul:vbox sectiondisabled="true">
<xul:textbox value="foo"/>
</xul:vbox>

the textbox should be disabled, in my opinion. (Or something like this.) So today I finally wrote up a script that could do this for me:

I also learned about nsIDOMXULControlElement. My work in XUL Widgets could only benefit from implementing this.

There’s a couple advantages to this. I can “nest” disabled sections now, so if a inner section is no longer disabled, the outer section still takes precedence

. Also, if I replace my usage of disabled with sectiondisabled (on the same node), then I don’t have to worry about accidentally and incorrectly setting a disabled property.

I still have to figure out how to handle <xul:command/> elements and command dispatchers, but by and large this is a big improvement.

Feedback welcome.

My new best friend, smaug ;-), posted a serious cleanup of DOM events code recently (see bug 234455 for details), thus allowing me to considerably simplify a patch for a bug that’s blocked me on Verbosio for months (bug 201236). That one looks like it’s going to be finished up fairly soon, too, so I was a happy camper.

Until this evening. Since Verbosio potentially can edit XUL applications, I figured I’d try a new approach: start with your most basic XUL editor possible

. Specifically, a textbox and a script to take that textbox’s contents, and replace the source code of the document with the textbox’s value. The idea was to see if I could start to slowly build a more complex editor using the basic editor itself as I went.

That didn’t work, for one simple reason: I couldn’t get the source code of the script inside the XUL document. So I did a little digging, and discovered there were no child nodes for the script element…

*insert ex-sailor’s swearing here*

Bug 330426. I’m back where I started — worse, actually, since this is in a part of the code where I have no references to compare to. Other than the DOM specs, and they’re the only justification I have for filing a bug.

One of the reasons I even thought about writing a native XPath Generator for Mozilla-based applications is a need to take a XPath for a DOM tree and translate it into a path for a DOM Inspector-like node tree. Unfortunately, as my mind has just now started wandering back towards my Verbosio application (for which I would use this XUL tree), I realized I had completely forgotten to include any functionality in the IDL or in the implementation for creating a XPath that would be friendly to this.

Specifically, I wanted a XPath that looks like: /node()[5]/node()[7]/node()[11]. I didn’t think about that when writing the extension, though. Fortunately, I had a lot of foresight in allowing for extensibility. So, pending reviews to land the xpathgen code (which I don’t expect right away), I’ll submit a new bug to to “GET_CHILD_INDEXES_ONLY”.

I might argue that I own the spec and I can do what I want there, but I don’t buy that. I’m doing this for the community, so even when I suggest a new idea for the spec, I make sure to run it by someone else for approval.

UPDATE: Or maybe not

. Collecting adjacent text & cdata nodes under XPath makes it not so useful.

I’ve just completed a first-draft, unstable, patch implementing a XPath generator in native mozilla.org code. (It is highly unstable, so unless you’re a developer willing to help fix bugs in it, don’t use it.) It’s been a marathon for me, writing a component from scratch with (until now) only peripheral experience in C++. I’m sure there are many in #developers who can attest to the large number of first-timer mistakes I’ve begged for help on.

As for the title of this blog entry, I’m pretty sure it’s accurate. First, you start off with a lot of pain. Read the “Full Article” link for a list.

Continue reading Writing C++ is like working out →