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

Jonathan Protzenko jonathan.protzenko at
Mon Mar 22 21:40:24 UTC 2010

Dear tb-planning,

Thanks to everyone for the nice answers and the followups to my previous
email. I'm glad I was able to start some discussion, and I'm even
happier to see that there are plans for an overhaul of the internal
APIs. Of the many things you mentioned, many of them will simplify my
life and I'm currently dreaming at night of removing big chunks of ugly
code from my extension :-) (especially the iframe auto-resize code which
is quite... head-banging).

Before addressing Andrew's specific remarks below, I'd like to evoke
other points while I'm at it.

1) We used to see really amazing extensions like this one:

It doesn't seem to be updated. Are there any plans to move this forward
/ maintain it? There are some other possibilities (see
for instance) and I'm sure many people would be excited to see such
visualizations as "recommended" addons on AMO. Of course, once the APIs
are improved and manipulating messages is as easy as toggling a <div>
with jQuery, it will be even easier to build such things. But what's the
general stance on this?

2) I stumbled upon bug 456814 a.k.a. "msgreadertracker", including
Bryan's amazing designs . What's
the current plan regarding this? Actually, visualizing attached images
inline as Bryan suggests in the mockups was one of the many things I had
in mind. Is this hard to do? Does this depend on offering better APIs
and better access to message parts?

3) Now moving on to Andrew's comments :).

On 03/19/2010 03:29 AM, Andrew Sutherland wrote:
> 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
> realities.
This is indeed very appealing. I don't have much time right now, but I
can imagine submitting some patches to implement marking a message as
read, or similar things. Would this be a useful effort or do you plan on
tackling this in the near future? I'm asking because the bug is a bit
old already, but if there is a hope of landing such patches quickly, I
think it might be worth the effort for me.
> 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.
That's one of the major pains involved with Gloda, and that accouts for
90% of the bug reports I receive concerning my extension. I'd be glad to
hear when it's fixed! Is there any specific bug involved?
> 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:
I CC'd myself, and this is definitely what I envisioned. As I said, I'd
be glad to contribute to that bug rather than baking my own quick-hacked
.jsm that really isn't useful to anyone.
>> ① I needed to display messages using the regular display code. (...)
> 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.
I'm going to post some directions on MDC because I think that really was
> 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.
Sure. But at least providing wrappers to display a message simply will
already be a big step forward. Of course we're depending on bug 80713
here... is there any possible way to lure roc into fixing this ? ;-)

>> 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.  
How do I "tell" Gloda that all the headers are in the same thread? I'm
just calling getMessageCollectionForHeaders with all the selected
messages from the dbView. Is that what you meant?
> 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,
> listOfDistinctConversationIdsICalculated);)
I guess I was not aware that msgQueries has a .conversation property. I
know that GlodaMessages have... anyway, I'll try to re-think that, and I
know for sure how to do it properly. Once again, the issue is that all I
have as a reference is
> For the author of a message, you should be pulling it off the "from"
> attribute on a fully indexed gloda message representation.
I was thinking this because of:

307 <>           let [text <>, meta <>] = mimeMsgToContentSnippetAndMeta <>(aMimeMsg <>,
308 <>                                                             aMsgHdr <>.folder <>,
309 <>                                                             SNIPPET_LENGTH <>);
310 <>           snippetNode <>.textContent <> = text <>;
311 <>           if (meta <>.author <>)
312 <>             authorNode <>.textContent <> = meta <>.author <>;

>> - 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.
Sure :).
>> 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:
Wonderful, I wasn't aware of that as well :(. I guess I didn't read the
release notes closely enough.

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

More information about the tb-planning mailing list