MesQuilla » Planet MozillaMessaging

EarlyLight (unofficial multiversion Lightning addon) for Thunderbird 14 -16

rkent — Wed, 15 Aug 2012 18:06:53 +0000

My EarlyLight addon, which is an unofficial build of the Lightning calendar extension, supporting multiple Thunderbird versions, is now available for Thunderbird 14 – 16. This is based on the current Lightning 1.8a2 source (which is now in the aurora directories). Download here:

OSX

Linux

Windows

I’ll probably stop supporting this once Thunderbird switches to its slower release cycle.

EarlyLight, an unofficial Lightning (aurora) build supporting multiple Thunderbird versions

rkent — Fri, 22 Jun 2012 20:14:09 +0000

I got tired of waiting for Lightning to fix their aurora build problems so I decided to practice my newly-acquired Mozilla build foo to build my own. In the process, I extended the usual Lightning build so that I have Lightning that can work with current TB release, beta, and aurora versions, that is Thunderbird 13, 14, and 15.

The “source” for this is just a makefile which you can see here. (I added my fix in Mozilla bug 766685 so that I could build this with my VS 2008 on Windows). This will only work in my local build environment, but it gives you an idea of what this is.

Anyway I call this thing EarlyLight. You can download this with the following links:

Windows: http://mesquilla.net/releases/earlylight_WINNT(TB13-TB15)_1.7a2.0earlylight.xpi

OSX: http://mesquilla.net/releases/earlylight_Darwin(TB13-TB15)_1.7a2.0earlylight.xpi

Linux: http://mesquilla.net/releases/earlylight_Linux(TB13-TB15)_1.7a2.0earlylight.xpi

I’m not sure how useful this will be to others, but the ability to run multiple versions of Thunderbird with the same version of Lightning is really useful for me. If others find it useful I might maintain this in the future.

One caution. It uses the same extension ID as Lightning, and so it really claims to be Lightning in Thunderbird. It should also update to Lightning 1.7 from the official site once that is released. Duplicating the ID like this will be disallowed at some point in the future, but for now it makes this a little easier to use.

Please tell me if this is useful to you.

Windows:

ExQuilla (Microsoft Exchange Server for Thunderbird) beta version released

rkent — Wed, 01 Feb 2012 00:05:19 +0000

I am pleased to announce that ExQuilla, a Thunderbird addon that provides access to messages and contacts in Microsoft Exchange Server, is now available. This is a beta-quality release. ExQuilla is currently only available for Windows, in English, and supports Thunderbird version 9, 10, and 11. Linux and Mac versions are planned for the future.

The most current version of ExQuilla is available from the MesQuilla site here. A slightly older version (due to review delays) is available from Mozilla’s addon site here.

This version supports access to messages and personal contacts from a Microsoft Exchange Server 2007 or 2010 using Exchange Web Services (EWS). Calendar support is not currently enabled, but is under development.

For an overview of ExQuilla, visit the ExQuilla support site.

Kent James

Avoiding namespace leaks in event handlers

rkent — Thu, 08 Sep 2011 16:58:43 +0000

A common pattern that we see in review of Mozilla addons is code that looks like the following:

var myExtension = {
  saveMe: null,
  onLoad: function () {
    this.saveMe = "I am saved";
  }
}
window.addEventListener("load", myExtension.onLoad);

Unfortunately the value of “this.saveMe” that is used in onLoad is the value from the global window, not the value from the myExtension object. Really the event listener is looking for an object of type nsIDOMEventListener, with a method handleEvent. When it does not find that, it applies some magic and just uses the entered function. Unfortunately, in the process the “this” does not get defined from the parent object, and you are stuck with “this” being the global object.

Here are three alternatives that don’t leak:

1) give it what it wants, namely a handleEvent method:

var myExtension = {
  saveMe: null,
  handleEvent: function (evt) {
    if (evt.type == "load")
      this.saveMe = "I am saved";
  }
}
window.addEventListener("load", myExtension);

2) wrap the function call with a function:

var myExtension = {
  saveMe: null,
  onLoad: function () {
    this.saveMe = "I am saved";
  }
}
window.addEventListener("load", function() { myExtension.onLoad(); });

3) use the bind function to manually specify what “this” will be used:

var myExtension = {
  saveMe: null,
  onLoad: function () {
    this.saveMe = "I am saved";
  }
}
window.addEventListener("load", myExtension.onLoad.bind(myExtension));

These kinds of issue can be difficult to spot just by looking at code. Addon authors are strongly encouraged to use the “Extension Test” addon to catch leaks of names to global namespaces.

Address Book accounts

rkent — Tue, 08 Mar 2011 20:16:39 +0000

New account types in Javascript for Thunderbird (Part 4)

Now that I am essentially feature complete in adding Address Book features to my Exchange Web Services implementation ExQuilla, I’d like to discuss how SkinkGlue was used to allow this to mostly be done in JavaScript.

As review, SkinkGlue is my attempt to add an interface layer to Thunderbird to allow new account types to be added using javascript. SkinkGlue provides the necessary C++ interfaces to allow standard Thunderbird objects to be created without writing C++ code. SkinkGlue is licensed inder the standard Mozilla licenses, so it could be used by other extensions, or implemented as a Thunderbird standard feature. The current source is available here.

Adding Exchange Server contacts to the address book

While ExQuilla itself is mostly written in C++, I thought I would try to do the interface to the address book mostly in javascript.

At first I thought that would be straightforward, as the address book interfaces are much simpler than the mail interfaces, and there was supposed to be an existing extension that already did this. But I could not make this work reliably by trying to create a full javascript implementation of the nsIAbDirectory interface.

The main culprit is that the address book implementation seems to require that directory objects also derive from nsRDFResource. The underlying interface nsIRdfResource has the non-scriptable method GetValueConst, which is used by core Mozilla code in accessing RDF items. Perhaps I could have figured out how to work around this, but given the work I had already done in SkinkGlue, it seemed easier to just add a SkinkGlue type that allowed me to create an nsIAbDirectory object. Another advantage of this is that I could take advantage of the existing full generic C++ implementations, and then only override methods that I needed to change.

So in the end, I created a SkinkGlue object to be used for address book directories that can be extended using javascript. The C++ implementation of this derives from both nsRDFResource as well as nsAbDirProperty, and provides the minimum needed interfaces. This is actually quite parallel to the mailnews SkinkGlue objects, as the address book object nsAbDirProperty is similar in role to the mail object nsMsgDBFolder. Both provide a generic C++ implementation of key interfaces, and are used in standard mailnews C++ objects as a parent class. By adding this to SkinkGlue, I am simply allowing javascript users to follow the same methods that C++ users employ.

For address book cards, this was not necessary. There is an existing object “@mozilla.org/addressbook/cardproperty;1″ which works just fine.

The result is that the standard Exchange Server “Contacts” folder and subfolders appear in the Thunderbird address book:

Note this is a Mork-free implementation, unlike the mailnews SkinkGlue objects.

Since the address book interface does not support a tree of directories, I had to implement the subfolder “Test subfolder” as a top-level address book with an extended name.

I hope to demonstrate this publically soon by adding “address book” support to my TweeQuilla Twitter extension, where an address directory would be interpreted as a list of followers.

Changes needed to Address Book to make this easier

The address book interfaces are much cleaner on average than the mail interfaces, but unfortunately not completely there yet. What would make this easier to do?

1. Remove address book dependencies on RDF

The use of RDF is ultimately what forces me to create a C++ object to backup my javascript implementation.

2. Add async access capability to key interfaces

Most new address book accounts that might be supported would be remote sources. While the existing LDAP implementation manages to work around that, it is not at all clear from the interfaces how this is done. Really async access needs to be thought through and applied consistently. In my implementation, I essentially end up loading all of the contacts into memory, which will not scale well to large implementations.

Twitter for Thunderbird

rkent — Wed, 05 Jan 2011 00:23:45 +0000

New account types in Javascript for Thunderbird (Part 3)

I’ve now released an initial version of my extension TweeQuilla, Twitter for Thunderbird. While the extension provides useful functionality, the main purpose of this exercise was to demonstrate how a Thunderbird account can be created using just javascript. Well almost … there are some binary files needed (called Skinkglue) which are account-independent, and presumably could be made available in the Thunderbird core code to eliminate the need for extension writers to maintain their own C++ compile environment. Unfortunately that binary extension limits this current release to only working under Windows in TB 3.1.x

There are a number of screenshots on my instruction page for TweeQuilla, but just as an example you get standard Twitter folders in your folder pane:

Messages are displayed in thread pane, and show website bodies where appropriate just like an RSS feed:

My main interest here is really to prove that this can be done, and hopefully to inspire some others to add additional account types.

Overriding C++ xpcom objects using Javascript

rkent — Wed, 29 Dec 2010 00:48:38 +0000

New account types in Javascript for Thunderbird (Part 2)

One of the more difficult challenges in adding new Javascript-based accounts to Thunderbird is the problem of overriding functions of C++ objects in Javascript. C++ objects typically rely on the object inheritance structure of C++, and do not reliably use QueryInterface to force use of xpcom and xpconnect functionality. Even if they did, Javascript does not pass a reference to the underlying Javascript xpconnect object to the C++ object when it finds a C++ object in the prototype chain of an xpcom call. Instead, it passes the C++ object from the prototype chain, so any attempts that you make to override the C++ object with a Javascript object get lost. What all of this means is that you really cannot rely on either Javascript or C++ inheritance to work as you expect.

In Skinkglue (the C++ portion of my project to allow JavaScript-based accounts in Thunderbird), I get around this by adding a layer of C++ code between the underlying Skink object (such as nsMsgIncomingServer) and the js-based component that will implement functions (such as a particular nsIMsgIncomingServer method) that will allow account-type-specific functionality. I want to describe that layer here and how it is used.

The C++ part of the override layer

Skinkglue has a standard implementation of many of the Skink objects, which simplifies the process of adding new accounts. So, for example, the Skinkglue implementation of nsIMsgIncomingServer is in a C++ object called msqSgIncomingServer. This object derives from the base Skink C++ object nsMsgIncomingServer like this:

class msqSgIncomingServer : public nsMsgIncomingServer,
                            public msqISgIncomingServer

The additional interface msqISgIncomingServer adds a few small additional methods that are needed to setup the generic version of an incomingserver, but are hard coded in the original Skink design.

C++ users of this object then derive directly from msqSgIncomingServer without difficulty. But for javascript callers, we add an additional “overridable” layer:

class msqSgIncomingServerOverridable : public msqSgIncomingServer,
                                       public msqIOverride

This msqIOverride interface contains specific information that is used to override base class functionality in Javascript. That interface is:

interface msqIOverride : nsISupports
{
 /// @parameter aMethodName  string name of a C++ function that
 ///                         will be overridden by javascript
 void override(in ACString aMethodName);

 /// the javascript-based xpcom object that overrides methods
 attribute nsISupports jsParent;

 /// the base class used to implement default functionality
 readonly attribute nsISupports base;
};

Essentially the way this works is that the Overridable class is the most specific object type in C++, and therefore all C++ objects see it and its inherited base classes. But the Overridable class knows when it should really use a Javascript override, because you tell it specifically which classes to override. So we make C++ happy, but still allow Javascript to be used.

The Overridable C++ layer is rather interesting, but probably not of much interest to most users who want to create Javascipt accounts. So I won’t discuss it further here.

The Javascript glue part of the override layer

Typically the way that Skink works is that specific types of objects that are needed for different account types are loaded using a standard Contract Id for the object, which is defined using a single protocol type. In Skink, that type might be “imap” or “pop3″, but in the demo TweeQuilla extension I use “twitter”. So when Skink needs to create an incoming server for a “twitter” protocol, it tries to create an object using the Contract Id “@mozilla.org/messenger/server;1?type=twitter” There are many of these types of components that are needed by Skink. I also used the same concept to add a couple more additional types that are used to create Skinkglue-derived versions of objects. All of these needed objects are layed out in the file twitterSkinkGlue.js As an example, for the twitter incoming server, I have the component registration:

type = "twitter";

function IncomingServer() {
 Cu.import("resource://tweequilla/twitterIncomingServer.jsm");
 TwitterIncomingServer.call(this);
}

IncomingServer.prototype = {
 classDescription: "Twitter Incoming Server",
 classID:          Components.ID("{A6CA1F3D-73F3-4764-A6DC-61D495618533}"),
 contractID:       "@mozilla.org/messenger/server;1?type=" + type,
 QueryInterface:   XPCOMUtils.generateQI([Ci.nsIMsgIncomingServer,
                                          Ci.msqISgIncomingServer]),
}

The implementation of the object is in a separate module, because I wanted to keep the component registrations separate from the detailed implementations of each object type. That implementation needs to follow a particular pattern in order to provide all of the needed hooks between the Javascript and C++ layers. Here are the main features, using a simplified example that is partially derived from twitterIncomingServer.jsm:

function TwitterIncomingServer()
{
 let server = Cc["@mesquilla.com/sgincomingserver;1"]
                .createInstance(Ci.nsIMsgIncomingServer);
 server instanceof Ci.msqISgIncomingServer;
 server instanceof Ci.msqIOverride;
 this.__proto__.__proto__ = server;

 // define the overrides
 this.jsServer = new TwitterIncomingServerOverride(server);
 server.jsParent = this.jsServer;

 // initializations
 server.override("msqSgIncomingServerOverridable::PerformBiff");
}

So when a new TwitterIncomingServer component is instantiated, the Javascript module create a base Skinkglue C++ xpcom object, and sets that object as the __proto__.__proto__ of the Javascript component.

A separate Javascript class TwitterIncomingServerOverride is used to describe the overridden functions, and any local functions that may be needed. An instance of this is created in the main object constructor, and a reference to that object given to the underlying C++ class so that it may use the Javascript class to override requested methods. Any C++ methods that will be overridden with Javascript must be declared with override() calls. In this example, I am overriding the nsIMsgIncomingServer method PerformBiff with a Javascript version.

The Javascript Implementation part of the override layer

The actual overriding functions are implemented in the Override Javascript object:

function TwitterIncomingServerOverride(aIncomingServer) {
 // initialization of member variables
 this.wrappedJSObject = this;
 this.baseServer = aIncomingServer;
}

TwitterIncomingServerOverride.prototype =
{
 QueryInterface:   XPCOMUtils.generateQI([Ci.nsIMsgIncomingServer]),

 // **** nsIMsgIncomingServer overrides
 performBiff: function _performBiff(aMsgWindow)
 {
  // do something to implement Biff
  // ...

  // call the base function if needed
  base = this.baseServer.base.QueryInterface(Ci.nsIMsgIncomingServer);
  base.performBiff(aMsgWindow);
 },

 // **** local methods
 sendStatusUpdate: function _sendStatusUpdate(text)
 {
 this.serverHelper().statuses.update(this.normalCallback,
                    this.errorCallback, null, 'json', text);
 },
}

When the Override function is defined, it is given a reference to the base object, that it should save for use when calling base functionality. Also, it is good practice to add this.wrappedJSObject = this; With this, you can get access to local javascript functions in the server, when you are given an xpcom link to the the server object, like this:

  server.QueryInterface(msqIOverride)
        .jsParent
        .wrappedJSObject
        .sendStatusUpdate(text);

So far, all of this seems to be working for me. While the glue may seem obscure, really it is all boilerplate and not all that hard to use.

Of course, we still have other “interesting” issues to deal with, such as message URLs and libmime. Stay tuned.

Appendix: Solvable but Annoying Problems

In several cases, the underlying Skink C++ will pass a null pointer to a C++ object that is expecting to give a result to xpconnect. The C++ can be designed to handle this, but it always causes Javascript implementations of xpconnect to fail. An example is this code:

nsMsgDBFolder::GetChildNamed(const nsAString& aName, nsIMsgFolder **aChild)
{
 NS_ENSURE_ARG_POINTER(aChild);
 GetSubFolders(nsnull);

For each of these that I find, I have to put a special override in the C++ Overridable layer to prevent crashes and assertions from xpconnect. That’s a real pain – and would be unnecessary if the core code followed appropriate behavior. I hope that when Skinkglue gets implemented in core, we can fix some of these unnecessary annoyances that greatly complicate Skinkglue.

New account types in JavaScript for Thunderbird (Part 1)

rkent — Tue, 28 Dec 2010 06:29:19 +0000

For the month of December, I took a reprieve from ExQuilla, my Exchange Web Services extension, and decided to tackle the issue of trying to create new account types in JavaScript in a Thunderbird extension. This blog post is an introduction to that project. More detailed posts on specific issues should follow shortly.

Introduction to SkinkGlue

I’ve learned a lot about how to create account types in an extension while working with ExQuilla. While ExQuilla is written principally in C++, many of its concepts could be adapted to javascript. I decided to write TweeQuilla, a demonstration extension in javascript that will implement Twitter as an account type in Thunderbird to test the concepts.

Unfortunately it is not as simple as just writing stuff in javascript, as Joshua Cranmer discovered in his never-finished series of blog posts attempting to do just that. There are complex interactions between javascript objects, C++ objects, and xpconnect that make it difficult or impossible with the existing core code to create a new account in javascript. I have not really solved that problem completely. Instead, I have created a C++ layer that I call Skinkglue. (Skink, as my loyal fans know, is my personal term for the mass of code that implements the basic mailnews functionality in Thunderbird and related products such as SeaMonkey.)

Now Skinkglue is written in C++, and needs to be available before the javascript-only TweeQuilla will work. But Skinkglue does not contain any twitter-specific functionality. In fact, the same Skinkglue code is also used by my ExQuilla addon to implement a new account type using C++.

My intentions are that Skinkglue will get implemented in core as a publically available interface. For that reason, I am making that code available using the standard MPL tri-license. Hopefully that would solve the issues of trying to use a C++ layer in an extension, as it would just be a part of the core that would be available in the standard distribution, so extension writers would not need to compile the C++.

Introduction to TweeQuilla

I chose Twitter as a demonstration because it is likely to be useful, because it is quite simple, and because there has been a lot of work already on the Mozilla platform in developing code for basic Twitter functionality. In particular, I am indebted to the SocialMail addon for the most recent set of updates to that work, though that addon built largely on earlier contributions.

I am not releasing TweeQuilla for public consumption yet on AMO because it is not at all ready (though I am starting to use it myself in my standard email profile.) But the main point is really to demonstrate that this can be done at all, and the extension as it stands makes that point.

Here are a few images of TweeQuilla:

A new twitter account is added using Account Actions in the Account Manager:

When you add a new twitter account, you must fill out an OAuth screen (this one is largely borrowed from SocialMail):

When the account is created, you see different types of twitter searches as mailnews folders. Currently I only have two implemented, one a list of the items that you have sent, and the other your full timeline:

For tweets that just consist of text, the “message body” and the subject are both just the text of the tweet. For tweets with embedded html links, I am currently loading the html link as the “message body”.

Getting the source

Both Skinkglue and TweeQuilla are available for the curious on my Mozilla mercurial site. The TweeQuilla version that exists there includes a compiled version of Skinkglue that will work if you are running Thunderbird on version 3.1.x under windows. Others are out of luck for now. The code at the moment is not easy to understand. I hope to remedy that by some comment cleanup, as well as documenting issues in further posts on this site.

Exquilla alpha 0.2 released

rkent — Sat, 20 Nov 2010 00:43:36 +0000

Today I release alpha version 0.2 of ExQuilla Exchange Web Service. This may be downloaded at the AMO site for the ExQuilla.

This release adds support for most primary email features, but not the EWS address book or calendar. However, this is still Alpha quality code, which means that many of the features have minor glitches.

Major Additions since last release

Cross-account message copies and moves
Message Filters
Junk Processing (though moves of junk messages are not working)
Virtual Folders
Save message as a file
Show message source
Message print
Improvements in handling of Unicode character sets

Further information is available at the ExQuilla page on this site.

ExQuilla alpha 0.1 released (Mailnews Exchange Support)

rkent — Fri, 22 Oct 2010 23:28:58 +0000

Today I released to Mozilla’s addon site a preview release of my Exchange Web Services extension, which I am calling ExQuilla (see the addons page here to download).

This is alpha quality software, which means it is usable if you are brave. (I have been using it for a month with my rkent@mesquilla.com email account).

There are many, many non-implemented features. Rather than repeat all of that here, I’ll just refer you to the extension description page that I have put up. The most severe restrictions are that this is email only, and there is no attempt to support localization or internationalization (so your Russian or Thai spam will look really strange.) Also, this build only supports Windows users running Thunderbird 3.1 Use at your own risk!

There is one major bug that I am aware of. For reasons that I have been unable to determine, sometimes the extension quits working, and sends a variety of messages to the error console. You need to restart to solve this. Hopefully I’ll figure out soon what is causing this.

The initial download of messages can be quite slow, which seems to be a limitation of Exchange Server (at least for the provider that I am using). But after the initial sync of messages in a particular folder, future use is generally quite fast, so be patient.

I would be interested to hear people’s experience in trying to get this to work with their own Exchange implementations. It really is too early though to give detailed feedback or bug reports, but I would be interested in anything that prevents it from being used at all for your needs.

I’ll be away most of next week (going to a prisoner re-entry conference and visiting a reentry facility affiliated with my church) so it may be November until I can get back to you if you have issues.