Followup to bug 241197 -- or -- feedback from an extension developer
asutherland at asutherland.org
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  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
> - 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...
More information about the tb-planning