Followup to bug 241197 -- or -- feedback from an extension developer

Andrew Sutherland asutherland at
Fri Mar 19 02:29:23 UTC 2010

  First, thank you very much for composing this message; this is exactly 
what I was hoping for!  I'm going to mainly try and reply in terms of 
what the plans are from my perspective to address these problems.  These 
are going to tend to be gloda-centric plans that assume that you are 
generally starting from a gloda message abstraction in the first place.  
Direct interaction with nsIMsgDBHdr instances is not something I am 
trying to facilitate.  This is unfortunately at odds with most current 
realities but is a cost/benefit necessity to ever escape the current 

The good news is that there are ways to go from nsIMsgDBHdr instances to 
gloda instances, as you are aware.  The bad news is that there is 
currently no guarantee that there will be a gloda message for the 
message you want and the indexer does nothing to help you out.  The good 
news is that we're very close to being able to resolve that.

On 03/17/2010 02:42 PM, Jonathan Protzenko wrote:
> One big disappointment to me was the fact that STEEL (and, by the way, 
> FUEL) seems to be completely abandoned. I was hoping for a real 
> "standard library" for Thunderbird extensions, providing wrappers for 
> extremely common actions such as getting the contents of a mail, 
> marking a message as read... However, no such thing exists. The only 
> useful resource is MDC [3] which is extremely sparse.

The going forward plan has been to fuse the STEEL message manipulation 
goals into the gloda representations.  This has been somewhat 
complicated by need to decouple the action mechanism enough that it can 
be used on messages that are not backed by nsIMsgDBHdr instances.

The gloda bug for that is here:

The STEEL bug which has some discussion on strategy but is not required 
reading is here:

There are some test-only helpers that might provide some insight on how 
to perform various manipulations, but being test-only they may not 
generate the proper event cascades required in reality:

> (1) I needed to display messages using the regular display code. That 
> is, using the HTML if the message has HTML, but stripped of all JS, 
> with images blocked according to the global security policy. I first 
> thought that Gloda would offer a wrapper for that. But all I could 
> find was GlodaMessage::coerceBodyToPlaintext. That was pretty useful, 
> but I found it odd that, given that all the MIME structure was built, 
> no such equivalent was available for the HTML contents. I wrote a 
> custom function that recursively walks down the GlodaMessage's .parts 
> and returns whatever has contentType "text/html" and looks like a 
> "message body". However, JS is not stripped, images are not blocked... 
> I finally resorted to copying nsMessenger.cpp's behavior using 
> loadURI, nsIMarkupDocumentViewer and nice gory details such as 
> hintCharacterSetSource on the contentViewer.

This is going to be a big area for future work.  You are doing the right 
thing by using the existing code path when involving HTML messages (as 
HTML) and probably all other extension authors should follow your lead here.

Our dream is to be able to display messages with extensions being able 
to contribute annotations and additional mark-up in an easy fashion.  
Because there are so many security concerns and potential interaction 
problems between multiple extensions trying to do the same thing, I 
think it's going to take a very concerted effort to improve this.

> To be even more specific, Gloda conversations respect "strict 
> threading". This means that when my extension is used in conjunction 
> with mail.strict_threading set to false, I need to repeat the two-part 
> process for each message in the "false thread" because Gloda won't 
> relate these messages together in a GlodaConversation. The Gloda logic 
> is perfectly fine, it's nice to have strong semantics, but once again 
> I'd need a getConversation*s*ForHeader*s*.

This use-case is pretty atypical.  But you could save yourself a lot of 
work by just using getMessageCollectionForHeaders telling it all the 
headers that the db view is telling you are in the same thread at once.  
Then do a single pass to figure out all the distinct conversations 
involved and ask those conversations for their messages in a single 
query (ex: msgQuery.conversation.apply(msgQuery, 

Patches / extensions to change gloda's conversation logic to be more 
clever are obviously also possibilities, although likely to be more of 
an undertaking.

> - mimeMsgToContentSnippetAndMeta's meta part never seems to return the 
> author properly. Ideally, that would be a GlodaIdentity that 
> corresponds to the name stored in the Address Book.

This isn't really intended to provide any information about the author.  
Because the content whittlers are also used as part of the message 
indexing process, there may be some ad hoc communication from 
contentWhittle intended for consumption by their owning indexer, but 
that's it.  For example, the bugzilla content whittler does this because 
not all of the information about the initiator of a bugzilla action is 
available from the headers but instead has to be parsed out.

For the author of a message, you should be pulling it off the "from" 
attribute on a fully indexed gloda message representation.

> - the ability to make a difference between a forwarded message and a 
> "real" attachment (currently, both have .isRealAttachment set to true).

I would categorize this as a bug; I doubt there's any case where we 
would want to categorize it as such.  Please feel free to log a bug.

> There are definitely more and more parts of the UI that use HTML 
> (search results, thread summaries). What a shame that functions such 
> as _mm_addClass, _mm_removeClass are defined locally and not made 
> available in a .jsm somewhere for extension developers! I partly used 
> jQuery at the beginning, but as I really was not satisfied (slows 
> things down, does not always play nice with XUL, spits tons of 
> errors), I resorted to more old-style DOM code. I'm unsure as to what 
> is the best solution here.

Thunderbird 3.1 supports the new element.classList magic and the ship 
has sailed on Thunderbird 3.0 for adding that so that extensions can 
always assume it is present, so classList is the way to go:

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the tb-planning mailing list