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.