Extending Bugzilla Links in Thunderbird

I took a couple hours… ok most of the day yesterday to fix a little issue that’s been bothering me for a while.

Bugzilla links inside email messages.  I get countless messages where people reference bug 426175 but then don’t link to the bug.  The other option is for the person to include the link in the email which is ugly and pushes the flow around https://bugzilla.mozilla.org/show_bug.cgi?id=426175 because there is a large link inside the text.

Despite emails not being HTML mail, for whatever reasons, I still want bugs to be linked in a reasonable manner when I’m looking at my mail.  I couldn’t find an existing solution, though there likely is one hiding somewhere.  So I started a new extension to solve my problem.

The Bugzilla Link Grabber Thing

I’m not good with names, another reason I probably shouldn’t have kids.  (Offspring of Bryan Clark Jr.)

Here is a typical message that contains a mix of bugzilla urls and shorthand bug mentions.  You can see the urls are long and a bit ugly, while the short hand link mentions (even though this example mentions the same bug) are not linked to the bug itself.

Before you view any mail the extension takes the long bugzilla urls and converts them into the shorthand form.  It also linkifies any shorthand bugs into working urls.

Right now the extension only understands mozilla bugzilla and gnome bugzilla because that’s all I have accounts for.  But others could be added and I was hoping to have a preferences dialog that allows you to add alternate bugzillas (see TODO).  But otherwise it works great.

For xpi downloads, source, TODO, and more details take a look at the Bugzilla Link Grabber wiki page.

Fixing things

If you’re interested in this working for your copy of bugzilla or see some bugs in the code, don’t ask, please dive right in and fix things. Don’t forget to grab the STEEL extension or this one won’t work.  Also it only works on thunderbird nightly builds right now; but maybe that’s something you can fix.

I put the extension source up at github, sorry if that’s not your RCS of choice.  Anybody who creates patches to fix one of the TODO items is welcome to one of my remaining invites to github.  I don’t really have anything else to give…

Blue STEEL!

Blue STEEL Zoolander

Out of the Thunderbird status meeting this week I learned that there’s already a test extension available which gives Thunderbird Extension Developers some of the new STEEL interfaces.

What is STEEL?

STEEL stands for, Scriptable Thunderbird Easy Extension Library, and that means a simple javascript library to access your data (email, addressbook, etc.) inside Thunderbird.  Like it’s Firefox counterpart FUEL, STEEL will create an easy extension development API for Thunderbird.

What can you do with STEEL? 

Right now STEEL is in it’s infancy with a 0.1 release as you can see in the implementation plan.  However there already exists lots of things you can do with the existing STEEL code.

Here are some examples:

You’ll need to grab the latest STEEL extension from bug 408370, luckily there are STEEL Extension Install Instructions which you can follow.

Where is STEEL going?

What happens with STEEL is up to extension developers.  If you’ve already developed an extension for Thunderbird please give STEEL a try and let the developers know what you think.  If you’ve been thinking of developing an extension for Thunderbird try STEEL out to see if it does what you need.

The coming API will depend a lot on the kind of feedback that can be gathered right now. Join the conversation on the #maildev IRC channel or send a message to the mozilla.dev.apps.thunderbird newsgroup.

Personally I’d still like to see a couple things happen.

Simplify extension development by relying heavily on a local cache.  As a person who wants to try out a lot of different ideas inside Thunderbird via extensions I’d like to avoid network latency issues and would rather have all the information cached and indexed locally such that all calls could be fast and synchronous.  The only signal I would want to worry about is when the cache has updated so I can refresh my calls.

Allow for objects to be retrieved separately and by-directionally queried.  For example I’d like to be able to ask for a list of attachments and then for each attachment find out what message it was sent in, who sent it, and even other attachments they sent.

  • for each ( attachment in Application.attachments )
    • from = attachment.message.from
      • for each ( attachment in from.attachments )

Improved Search APIs.  I got to talk with the excellent David Huynh of SEEK fame and asked if he could take a look at the STEEL APIs for improvements; I’m excited to see what he has to say.  Improving search is one of the major goals for Thunderbird 3 and all the great new ideas come out of extensions so development needs to be ready for that.

Malleable STEEL

A simple exercise I have been doing is to take an existing extension, even ones for outlook, and offer a Thunderbird extension developers perspective of the STEEL API .  Right now I have a breakdown of the Xobni Extension which I thought was very interesting extension that I’d like to see in Thunderbird in the future.  The breakdown examines different pieces of the extension with simple function calls that could enable it.

aboot

This is the blog personality of Bryan Clark. I'm a designer in a world of open source. This blog reflects mostly writing about Design, Open Source, Economics, Beer, Wine, and Dogs. There's more information about me on this site or you can contact me directly at clarkbw@gmail.com.

scategories