Planet Mozilla Messaging

March 15, 2010

Robert Kaiser

Weekly Status Report, W10/2010

Here's a summary of SeaMonkey/Mozilla-related work I've done in week 10/2010 (March 8 - 14, 2010):

Next to the places work, I have been working to improve the display of the metrics data we get from Mozilla on the SeaMonkey development site, splitting the displays by year and even adding a canvas-driven graph to the overviews (I'm still planning to work on improving that somewhat and making it available on the other sections as well). I hope some people are interested in such statistics. ;-)

Also, Karsten was friendly enough to explain the SeaMonkey situation around Microsoft's "EU browser ballot" on the SeaMonkey blog, thanks for that!

March 15, 2010 08:19 PM

James Burke

RequireJS, kicking some AST

RequireJS has an optimization tool that can combine and minify your scripts. It uses Google's Closure Compiler to do the minification. Recently, but after the RequireJS 0.8.0 release, I ported over the CSS optimizations from the Dojo build system, so the optimization tool now inlines @import calls and remove comments from CSS files.

The script combining still has some rough edges though, and it was mainly due to me trying to use suboptimal regexp calls to find require() and require.def() calls in the files, so the dependencies for a script could be traced.

So I finally took the dive into Abstract Syntax Trees (ASTs) to do the work. What is an AST? An analogy that works for me: an AST is to JavaScript source as the DOM API is to HTML source. The AST has methods for walking through the nodes in the JS code structure, and you can get properties on a node.

Figuring out how to generate an AST from scratch can be a bit of work, but since I was already using Closure Compiler, I just used an AST it can generate.

Since the optimization tool for RequireJS is written in JavaScript, which makes calls into Java-land to do file access and minification calls, I wanted the same approach for working with the AST -- do my work in JavaScript, but call the Java methods for the AST walking and source transform.

My task was fairly simple -- I just wanted to find require() or require.def() calls that used strings for module names and dependencies, pull those calls out of the file, then just execute those calls to work out the dependencies.

The end result was this file:
http://github.com/jrburke/requirejs/blob/master/build/jslib/parse.js

The basic idea of the script:
//Set up shortcut to long Java package name,
//and create a Compiler instance.
var jscomp = Packages.com.google.javascript.jscomp,
  compiler = new jscomp.Compiler(),

  //The parse method returns an AST.
  //astRoot is a kind of Node for the AST.
  //Comments are not present as nodes in the AST.
  astRoot = compiler.parse(jsSourceFile),
  node = astRoot.getChildAtIndex(0);

//Use Node methods to get child nodes, and their types.
if (node.getChildAtIndex(1).getFirstChild().getType() === CALL) {
  //Convert this call node and its children to JS source.
  //This generated source does not have comments and
  //may not be space-formatted exactly the same as the input
  //source
  var codeBuilder = new jscomp.Compiler.CodeBuilder();
  compiler.toSource(codeBuilder, 1, node);

  //Return the JavaScript source.
  //Need to use String() to convert the Java String
  //to a JavaScript String.
  return String(codeBuilder.toString());
}
Thanks to the Closure Compiler team for doing the hard work and open sourcing the code. It looks like Closure Compiler deals with two AST formats -- one is perhaps an older one generated by Rhino, while the other one is a more custom one? It seems like I was getting back the Rhino-based Nodes for the methods I called.

I was tempted to try to go direct to just use Rhino for the AST, but decompiling the AST into source looked harder to do, and from what I recall, Rhino has a newer AST API in the trunk code. I believe the one in Closure Compiler is the older one? All that added up to me being wary of that path.

Most of the time spent was trying to figure out the Java invocations to get the code parsed, understand the tree structure, deal with Java-to-JavaScript translation issues and then figure out the Java invocations to convert a subtree back into source.

I am glad I finally stepped into working with a real AST. While some of the AST calls are a bit awkward (at least for me as a JavaScript person), it is a lot better than trying to use regexps for it. I still need to do more testing, but I feel more confident in the robustness of the solution now.

If you see how I can do it better, point me in the right direction!

March 15, 2010 03:59 AM

March 14, 2010

Robert Kaiser

What Places Have You Bookmarked?

Some people might remember that I had worked on the places history support we shipped in SeaMonkey 2.0 (as a side note, congrats to the Camino folks for making the jump as well).

Now I've done work on the next step, converting bookmarks to places:

Image No. 22245

I have the first part of the patch up in the place bookmarks bug report, which doesn't implement anything really visible yet, though.

There's a lot of work in this work I have done here, there are a few flaws left, and even when it lands, this is a start, not a final state of our reworked bookmarks support.
There are a lot of things we can and should improve in followup bugs, I have some ideas on that and I know other people in the community have as well - esp. in those few areas where the old bookmarks system has features the new system can't offer. And we will be working on those and accepting patches, of course.

We will do this change though, as there are a number of things the places bookmarks system can offer that the old system can't.

Here's a some of the improvements I currently know about:The following "feature losses" or changes to the old code are noteworthy:Note that it's intentional that we are doing this early in SeaMonkey 2.1 development so we can improve the code further based on feedback from testers. Also, we're not completely mirroring Firefox, as we're keeping history and bookmarks as separate windows, and our bookmarks organizer looks much more like our standard SeaMonkey windows. We keep the bookmarks button in the personal toolbar (which of course can be removed with the customize toolbar feature).

The work in progress I have on my desktop is so far doing quite well, almost everything is working fine, with the exception of HTML import/export (needs the relevant service to move to toolkit) and the keyword feature in the location bar (places supports it, I just haven't yet found out how to hook it up).

We will have places bookmarks in SeaMonkey 2.1, with a good number of additional features, and it's progressing well. We are trying to keep the inconveniences low for people losing something they used, please let's help together to pull this off and make it a good experience for everyone.

A lot of work is still to be done, let's work together, help each other and make it an experience that is as good as it possibly can be!

March 14, 2010 10:12 PM

March 12, 2010

SeaMonkey

See No Monkey Dance

Why SeaMonkey isn't part of Microsoft's European "Browser Choice Ballot Screen"

March 12, 2010 08:59 PM

Calendar

Sunbird 1.0b1 release candidate 1 is now available

After quite some build-system related difficulties, we have finally succeeded building Sunbird 1.0b1rc1. Please download and test it within the next 2 weeks, if no critical errors show up this will afterwards become the final version 1.0b1.

Candidate builds for Sunbrid 1.0 beta1 in 37 languages are available as of now for:

A corresponding build of the Google Calendar Provider is available at addons.mozilla.org

Please tell us what you think of these candidate builds and file bugs in Bugzilla as you go.

March 12, 2010 01:13 PM

March 11, 2010

Andrew Sutherland

partial: posting pymake data/results to a couch

What it does:

I think there’s a fair bit of potential in this (pushing “make -p” style data/make output into couch), at least in situations where there’s no escaping make, you don’t already have usable/appropriate tooling, and python/CouchDB/JSON is one of your religions.

I’m hoping to avoid touching the mozilla build system in any meaningful fashion from here on out, so I am unlikely to work on this much more, but it could be useful to others, hence this post.  The repo is here, check out the “understand” (p)branch.  (The changes are not suitable for upstreaming as things stand.)

March 11, 2010 06:26 PM

Rumbling Edge - Thunderbird

NUS CS3108 (AY 09/10 Semester 2) Mid-way Presentations on <video>

CS3108 (AY 09/10 Semester 2) is now midway through, the students (in no particular order), Daniel (Libras2909 on IRC), Simon (Simon or Nomis) and Chris (AnttyC) have presented on their projects, each wonderful in their own right.

And now presenting:

Daniel (Libras2909) – Thunderbird, application code (Blog):

Daniel’s ogg theora (101MB) or unprocessed mov (890MB) versions are available for download.

Simon (Simon or Nomis) – Thunderbird, Mozmill (Blog):

Simon’s ogg theora (97MB) or unprocessed mov (858MB) versions are available for download.

Chris (AnttyC) – Thunderbird, visualization (Blog):

Chris’ ogg theora (91MB) or unprocessed mov (805MB) versions are available for download.

Please do contact them directly if you are interested to know more about what they have been doing or will be doing in the future. Also, be sure to catch their updates at Mozilla Education Planet!

(Recorded on a MBP’s webcam, onto iMovie, and immediately saved as .mov, then later converted to ogg theora)

March 11, 2010 03:08 PM

Thunderbird 3.1 Beta 1 Released

Changelog for previous release (Thunderbird 3.1 Alpha 1) | Changelogs for other Thunderbird releases

Released on 10 Mar 10, and this changelog was last updated on 11 Mar 10.

Thunderbird 3.1 Beta 1 (also known as Lanikai Beta 1) has been released. Release notes are available. This post lists the improvements in Thunderbird 3.1 Beta 1 over Thunderbird 3.1 Alpha 1. This list encompasses almost every single known fix that went into this release, but excludes platform-wide fixes. Do check out the known issues as well.

Changes in Thunderbird 3.1 Beta 1: (96)

Thunderbird-specific: (42)

MailNews Core: (54)

Windows builds Official Windows installer

Linux builds Official Linux (i686)

Mac builds Official Mac (Universal binary)

March 11, 2010 12:41 AM

March 10, 2010

SeaMonkey

The SeaMonkey Project Turns 5!

On March 10, 2005, Mozilla Foundation announced the transition plan that paved the way for the community to take over development, release and project management of Mozilla's application suite. This agreement formed the base of today' SeaMonkey project, which came to be after a number of IRC meetings where we decided we'd first work on releasing the then-available suite code as a first community version while starting work on transforming the suite to an application built upon the new Mozilla platform also in use by Firefox and Thunderbird.
On July 2, we announced the new name of the suite and community project to be "SeaMonkey", September 15 marked our first Alpha release, on December 2, we announced our new logo, and on January 30, 2006, we were able to release SeaMonkey 1.0 to the public.
While we released a slightly improved 1.1 based on the old one a year later, work continued on the version based on the new platform, culminating in a completely reworked SeaMonkey 2.0 that more or less was the first release our new team developed from ground up, going public on October 27, 2009.
5 years after the transition plan announcement, we are about to end support for the SeaMonkey 1.x series and leave the aged "xpfe" platform finally behind us, while we're working on a new 2.1 release that brings more features and closes the gap to Firefox and Thunderbird even further.
So, while we're celebrating the 5th anniversary, the SeaMonkey project is as active as ever, if not even more, providing the most modern Internet suite available today with SeaMonkey 2.0 and working on improving it even more.
Still, we need your help to make our software and project even better in the next 5 years!

March 10, 2010 06:41 PM

March 09, 2010

Andrew Sutherland

emacs compilation-mode support for reviewboard

Let’s say you’ve suckered someone into performing their review in my review board install (more info).  It looks pretty, no?  As the Amish say: ‘Tis a fine web page, but sure ’tis no emacs buffer, English.

Get your reviewboard-viewer.el here (repo here).  It basically just wgets the review with paths in a format the GNU regex will recognize and tells the temporary file to be a compilation-mode buffer with a little help in setting up the file search path.  There are instructions in the file, but the key non-intuitive things that are going to trip you up:

Other notes to people who are interested/care:

March 09, 2010 12:33 PM

March 08, 2010

Robert Kaiser

Weekly Status Report, W09/2010

Here's a summary of SeaMonkey/Mozilla-related work I've done in week 09/2010 (March 1 - 7, 2010):

The SeaMonkey project is about to turn 5 years old! On March 10, 2005, the Mozilla Foundation posted a transition plan to surrender development, project and release management for the long-lived application suite to the community and therefore paved the road for our project to emerge. On July 2, we announced that our newly formed project would go under the "SeaMonkey" name, on September 15, we released our first Alpha under that brand, on December 2, we announced our new logo, and January 30, 2006, marked the SeaMonkey 1.0 release. While we started development of a toolkit-based really new version shortly after that, we did a 1.1 with only smaller improvements on top of 1.0 a year later. The brand new development version took a quite long time to be ready and stable, but was delivered to the public on October 27, 2009, as the SeaMonkey 2.0 release. Now, we're working on more to come while we're finally stopping support on the old xpfe-based suite code we inherited 5 years ago and which has served as a good base for getting this project set up, thriving on its own and work with more modern code in the end.
I'll do a dedicated blog post about this topic in the next days - probably on the SeaMonkey blog. Let's celebrate the first 5 years of this project and work on many more to come!

March 08, 2010 07:51 PM

Rumbling Edge - Thunderbird

2010-03-07 Calendar 1.0 builds

Current Sunbird (0.9) | Last planned Sunbird (1.0 Beta 1) | Previous releases | Mercurial source bundles (mozilla-central & comm-central)

Common (excluding Website bugs): (3)

Outstanding bugs (marked blocking-calendar1.0+): (27)

One can get the latest Lightning .xpis here.

Sunbird builds:

Windows builds Official Windows, Official Windows installer

Linux builds Official Linux (i686)

Mac builds Official Mac (Universal binary)

March 08, 2010 02:13 AM

2010-03-07 Thunderbird comm-1.9.2 builds

Previous TB release – 3.0.3 | Current TB pre-release – 3.1 Alpha 1 | Previous releases | Mercurial source bundles (mozilla-central & comm-central)

Thunderbird-specific: (14)

MailNews Core: (9)

Outstanding bugs (marked blocking-thunderbird3.1+ marked as “beta2+”): (31)

Windows builds Official Windows, Official Windows installer (discussion)

Linux builds Official Linux (i686)

Mac builds Official Mac (Universal binary)

March 08, 2010 02:05 AM

March 05, 2010

Calendar

How to solve incompatibility problems when upgrading to Thunderbird 3.0.3

Some of our users currently seem to experience problems with Lightning becoming incompatible when they update their Thunderbird installation to the 3.0.3 release.

The reason for this seems to lie in the fact that those users use a Lightning nightly build and update it on a daily basis with the Lightning Nightly Updater add-on or manually update to the latest available nightly build. But because we moved our Lightning nightly builds to only support the current Thunderbird 3.1 development builds, as reported earlier, this leads to the incompatibility.

The solution is simple though:
Just uninstall your current nightly build and install the Lightning 1.0 beta1 release. This release is identical to the latest available Lightning nightly builds for Thunderbird 3, but fully compatible with the Thunderbird 3 release. And to be on the safe side: Please backup your profile folder, before doing this!

March 05, 2010 08:58 AM

March 04, 2010

Siddharth Agarwal

Today I learned…

…that Mozilla trunk fastload caches modules, so if you have an opt build and you modify a module you need to nuke *.mfl from the local profile directory.

March 04, 2010 08:41 PM

Raindrop Design

March updates

It’s been awhile since our last update, but things have been progressing at a steady pace since the last time.

We have recently built our search and navigation system which we mocked up previously. You can check out a quick demo of it in early action here.

There have also been some great conversation going on about how we want to manage contacts in Raindrop, and how to create rich contact profiles. It seems like the ability to merge and associate different emails as the same person in Gmail and Yahoo mail have been largely ignored, and Raindrop wants to find the best way to remedy this problem of multiple personalities. Check out the Flickr Group to see what people have been saying about this topic.

Other than this we’ve been hard at work trying to get our hosted version going so we can really get the ball rolling with beta Alpha testers (!!!). Also, we’re in the process of coming out with some Raindrop apparel which should be fun. Here’s a little preview of the design, and for those of you contributing you might have a new shirt coming your way soon.

screen-shot-2010-03-03-at-25306-pm

-Andy

March 04, 2010 06:19 PM

Calendar

Lightning users on Thunderbird are in the majority for the first time

Three weeks ago, I shared some usage statistics for Lightning with you.

One of the things that I looked at then was the adoption of Thunderbird among Lightning users. Back then Thunderbird 3 users were still lagging behind, but now I can report that on the last weekend, the ratio of Lightning users on Thunderbird 3 was higher than the ratio of Thunderbird 2 users for the first time. Here's the graph showing the steady increase of Thunderbird 3 usage since November 25th in 2009, when the first release candidate for Thunderbird 3 was released.

As already noted in the earlier article, the ratio of Thunderbird 3 users is much higher on the weekends compared to the Thunderbird 2 users. But even during the workweek we're catching up pretty fast, even faster than on the weekends.

Interested observers will notice that the graph in this post and the earlier graph differ slightly. The reason is that in the current chart I've also incorporated the numbers of pre-release versions, like 3.0 beta3 or 2.0.0.24pre.

And if someone is asking himself why I only list Thunderbird 3 and Thunderbird 2 ratios here, the answer is that all other versions, e.g. users of Thunderbird 3.1 nightly builds, Thunderbird 1.5 users, SeaMonkey users and people that installed Lightning into Firefox all taken together account for not more than 0.5% of our total active daily users.

I hope that you will find this as interesting as I do.

March 04, 2010 02:03 PM

Thunderbird Localization

Attention localizers: Please move your Thunderbird localization to the l10n-mozilla-1.9.2 repository

From looking at the Thunderbird 3.1 dashboard it looks like a lot of localizations (13) that were part of the Thunderbird 3.0 release still need to move their existing localization over from their 1.9.1 l10n repository to their 1.9.2 l10n repository.

Right now the amount of changes between Thunderbird 3.0 and the current Thunderbird 3.1 builds are pretty small. Just moving an existing TB3 localization over to the 1.9.2 repo means that the dashboard will report 19 missing strings and 5 obsolete strings.

So with very little effort localizers can get their locale green again.

March 04, 2010 10:45 AM

March 03, 2010

Kent James

Mailnews Exchange Support: basic mail infrastructure

This post is intended mostly as a status update on my effort to add Microsoft Exchange Server support to the Mozilla mailnews products, including Thunderbird and SeaMonkey.

In my last report, I was testing and updating the old Mozilla SOAP framework for use in communicating with Exchange Web Services (EWS). Using the framework in a Thunderbird 3.0 environment, I could talk to the BING search SOAP interface. It took a couple of more weeks to resolve issues associated with communicating with EWS. There were a number of features missing from the old Mozilla SOAP, most importantly:

I’ve successfully sent a “Get Folder” call to an Exchange Server. The code to define the specific Exchange call looks like this:

let getFolder = new EwsGetFolder;
getFolder.invoke(responseListener);

function EwsGetFolder()
{
 // defaults
 this.FolderBaseShape = "Default";
 this.FolderIds = "inbox";
}

EwsGetFolder.prototype = new SoapBase(kMessages2007sp1Schema);

EwsGetFolder.prototype.invoke =
  function EwsGetFolder_invoke(aSOAPResponseListener)
{
 let FolderShapeList =
   objectPropertyList({BaseShape: this.FolderBaseShape});
 let FolderIdsList = objectPropertyList(
     {DistinguishedFolderId: objectPropertyList(
       {$attributes: objectPropertyList({Id: this.FolderIds}) })});
 let soapCall = Cc["@mozilla.org/xmlextras/soap/call;1"]
                  .createInstance(Ci.nsISOAPCall);
 let parameters = [];
 let FolderShapeType =
   this._schema.collection.getType(
     'FolderResponseShapeType',
     'http://schemas.microsoft.com/exchange/services/2006/types');
 let FolderIdsType =
   this._schema.collection.getType(
     'NonEmptyArrayOfBaseFolderIdsType',
     'http://schemas.microsoft.com/exchange/services/2006/types');
 parameters.push(
   new soapParameter(
     "FolderShape",
     FolderShapeList,
     FolderShapeType,
     "http://schemas.microsoft.com/exchange/services/2006/messages"));
 parameters.push(
   new soapParameter(
     'FolderIds',
     FolderIdsList,
     FolderIdsType,
     "http://schemas.microsoft.com/exchange/services/2006/messages"));
 soapCall.encode(
   Ci.nsISOAPMessage.VERSION_1_1,
   'GetFolder',
   this._schema.targetNamespace,
   0, null, // header blocks
   parameters.length, parameters);
 soapCall.transportURI = kAccount.url;
 soapCall.asyncInvoke(aSOAPResponseListener,
                      kAccount.user, kAccount.password);
}

So I can now successfully do SOAP communication to an Exchange Server (2007 SP1), using the standard Exchange schemas to encode the messages. There is still much needed to clean this up, but I’ve got enough working for now.

So now I turn my attention to the setup of a new account type in Thunderbird. This is the same issue that jcranmer is working on, but he is specifically trying to do everything in javascript, while I am content (for now) to work partly in C++. So I have to build the darn thing.

Ah, the Mozilla build system. Gotta love it. You have to know the difference between :, ::, :=, =~, (), {}, in a zillion different languages (perl, python, autoconf, automake, bash, make at least). When it works, it works like magic. But sometimes you wave your magic wand, say your magic incantation, and nothing happens. That’s what makes it so hard. You spend hours seeing if you can get the spell to work, but sometimes you just have to give up and do it the old fashioned way, knowing that there is probably some trivial change you could have done to make the magic work. But I guess I have no right to complain. Everyone said to NOT do it this way, but did I listen? I’ve been in build hell for a week.

But it turned out to be just build purgatory! Now that I am out, what wonders heaven holds! I can use a real debugger on my code, and not Venkman and dump()! The vast majority of the existing mailnews code is in C++, so I can see what local folders, IMAP, and newsgroups do, and very easily adapt it to my needs. I can subclass the existing implementations!

So as of today, I have a series of subclassed C++ files that contain what will be the future EWS-based objects – though I have not attempted yet to glue them to EWS, just simulations. I have new C++ files for the folder, message service, incoming server, and summary database – along with some basic unit tests. (This is very similar to the approach that the RSS implementation takes).

So what can I do? I can just display an account, its subfolders, and a message header (all simulated not real). It looks like this:

As you can see, I have not faced the issue yet of registering my protocols, so when I click on the message I get a complaint. I’ll be doing that next, along with trying to get the real information from EWS instead of this simulation.

OK, I know, you are not impressed – one simulated message, and that does not even work?  “Everything is hard to do in Thunderbird” is my defense, so cut me some slack, all right?

rkent

March 03, 2010 10:31 PM

Andrew Sutherland

Tinderbox results in bugzilla, jetpack times 2, CouchDB, review board

mstange’s Tinderboxpushlog is awesome.  You know it, I know it, the many people whose sanity has been saved by it know it.  It is a fantastic improvement on checking the tinderbox; it lets you know the current state of the tree, the recent history of the tree, and how these things are correlated with recent commits.  What it is not good at (nor intended for) is to be a historical record.  Tinderboxpushlog ’scrapes’ the tinderbox on-demand using tinderbox time windows and does not have the ability to key off anything but the time.

So if one refactored the scraper into a CommonJS module suitable for use with the newly rebooted jetpack, hooked it up to a cron job, and crammed its outputinto a CouchDB database, what would you get?

Exactly, something you can hook up to johnath and ehsan’s magic bugzilla jetpack (last mentioned on the blog here).  You can install it from here.  (johnath/ehsan, please feel free to pull the changes into the upstream repo; I’m still wary of randomly pushing things into other people’s user repos…).  I know the presentation is ugly, not the least because the text labels are inconsistent with tinderboxpushlog; feel free to push into my user repo with improvements.  Oh, and for this to work you need to put an honest-to-goodness URL in your bugzilla comment or attachment description; there is no all-powerful regex if you type things out by hand.

You can find the thing that pushes thing into the couch using refactored tinderboxpushlog logic here.  Some cuddlefish runner tweaks (not all of which are likely advisable) can be found in my user jetpack-sdk repo.  (The new jetpack reboot is wicked awesome, by the way.)

Right now the cron job is running against the MozillaTry, Firefox, and Thunderbird3.1 trees on the tinderbox every 5 minutes.  While it should be pretty easy for me to keep the cron job and couch server online, I make no guarantees about the schema used in the couch, just that I will keep the jetpack in sync with it.  And if the service starts exceeding the resources of my (personal) linode, I may have to tweak polling rates or what not (‘what not’ meaning ‘up to and including turning it off’).

There is other work happening in this area and I am excited about that.  For example, I think brasstacks has an encompassing vision that should help provide historical data about which tests failed, etc.  With any luck, my efforts here will be mooted by buildbot and magic awesome dust.

The mention of reviewboard in the title is just that if you are using my review board stuff and put a link to your try server commit in the attachment description, we will use that to pull the official hg changeset as the basis for the diff.  The main benefit of this is that if your patch depends on other patches in your queue that are not yet in the trunk, the diff will still work out.  Specifically, if your queue had A, B, and C applied (where C is the tip) and you link to C, then we will provide a diff of C relative to B.  Please be aware that hg.mozilla.org is rather slow about providing the hg changeset diffs on demand so this will be at least an order of magnitude slower than the fetch of an already-available patch from bugzilla.  Repo with changes is here.

March 03, 2010 08:10 PM

Rumbling Edge - Thunderbird

Thunderbird 3.0.3 Released

Changelog for previous release (Thunderbird 3.0.2) | Changelogs for other Thunderbird releases

Released on 01 Mar 10, and this changelog was last updated on 03 Mar 10.

Thunderbird 3.0.3 has been released. Release notes are available. This post lists the improvements in Thunderbird 3.0.3 over Thunderbird 3.0.2. This list encompasses almost every single known fix that went into this release, but excludes platform-wide fixes. Do check out the known issues as well.

Impact key for security issues listed on the Mozilla Foundation Security Advisories webpage:

Security issues in 3.0.3: (0)

Other changes in Thunderbird 3.0.3: (1)

Windows builds Official Windows installer

Linux builds Official Linux (i686)

Mac builds Official Mac (Universal binary)

March 03, 2010 07:53 AM

Thunderbird 3.0.2 Released

Changelog for previous release (Thunderbird 3.0.1) | Changelogs for other Thunderbird releases

Released on 25 Feb 10, and this changelog was last updated on 03 Mar 10.

Thunderbird 3.0.2 has been released. Release notes are available. This post lists the improvements in Thunderbird 3.0.2 over Thunderbird 3.0.1. This list encompasses almost every single known fix that went into this release, but excludes platform-wide fixes. Do check out the known issues as well.

Impact key for security issues listed on the Mozilla Foundation Security Advisories webpage:

Security issues in 3.0.2: (2)

Other changes in Thunderbird 3.0.2: (56)

Windows builds Official Windows installer

Linux builds Official Linux (i686)

Mac builds Official Mac (Universal binary)

March 03, 2010 07:45 AM

March 02, 2010

Mark Banner

Thunderbird Bugzilla Helper Jetpack

The problem: When replying/commenting in bugzilla we all frequently use similar phrases or urls in comments. For comments we just type them in each time, for urls we have to go off and find them, or have a copy file set up.

A solution: Create a jetpack that creates an “Add Comment” pick list to choose pre-defined text from. Select an item in the pick list, and bingo, the text appears in the comment.

If you want to try it out, make sure you’ve got jetpack installed in Firefox, then visit:

http://hg.mozilla.org/users/bugzilla_standard8.plus.com/jetpack/raw-file/default/thunderbird-bugzilla-helper.html

Next time you go to a bug page, there will be a little drop down just above the additional comments start.

There’s a couple of issues with it, like the Add Comment box doesn’t get inserted quite where I’d like it to, and the text is always inserted at the end of the comment, but it is already helping me save time.

If people want to make suggestions for frequent text/urls they use for Thunderbird I’m happy to incorporate them.

I haven’t considered text/urls for other apps because I don’t primarily work in those spaces, but if someone comes up with a reasonable proposal that doesn’t clutter the list and is easy to use then we can look at incorporating them as well.

March 02, 2010 04:27 PM

March 01, 2010

Robert Kaiser

Weekly Status Report, W08/2010

Here's a summary of SeaMonkey/Mozilla-related work I've done in week 08/2010 (February 22 - 28, 2010):

Could make some good progress this week, and build system porting is also progressing a lot, which is really good to see. I hope other SeaMonkey 2.1 work is also progressing so that we can make this a really good release. Meanwhile, a second alpha from the Mozilla 1.9.3 platform is being made, so we hopefully have something to base on once we have some new code to test in an alpha of our own.

March 01, 2010 04:36 PM

February 25, 2010

Robert Kaiser

How To Drive Away Contributors

As mentioned earlier, I recently stopped contributing to the progress dialog code that I wrote myself. Based on things I experienced and learned there and in other cases, I decided to write a guide for losing contributors. Completely losing someone like me is unfortunately hard, I did step back from this part of code but that's all.

It's much easier to completely get rid of non-core contributors or people working on only one part of the project, and those are what this 10-point guide is about.
  1. When the contributor works on a major feature (like, says a download manager frontend rewrite on a new backend), make sure you require all dependent feature parts (like progress windows) to be implemented before any of the work of that contribution can land. People hate to have their code sitting in Bugzilla patches for a long time and needing to do a lot of additional work, especially on parts of code they usually do not use themselves. You need to take advantage of that.
  2. If the contributor blogs or otherwise write messages about his work, make sure you have people around who take every attempt of humor (e.g. "Progress Dialogs? Eww!") as dissing the feature, criticize every single change to previous behavior as destroying that feature, the project and possibly the whole world. Take down any motivation he has to do further work in that area - that's imperative.
  3. Have users bitch heavily about the work, esp. about the shortcomings the contributor himself knows about and make sure no alternatives, short of killing the contributions and going back to old code, are provided.
  4. Very importantly, do care that no single appreciative word - let alone a "thank you" - is ever being mentioned about that specific contribution. Also don't make constructive comments about how to further improve things by staying true to the made contribution. Both could encourage the contributor to stay with the project and do further work on this code, which is exactly what you want to avoid.
  5. If he is starting work on further improvements even after all that, make sure people post in the bug about all kinds of problems they have with the general approach, have people post patches to at least partially revert the work the contributor did in the first place and ones that go against his overall design, and refrain from having any constructive proposals on how to do actual improvements in line with the overall design.
  6. If he makes multiple suggestions on how to improve things, chose the one he states to like least and successively criticize what he stated to not like as a problem in reviews.
  7. If a constructive suggestion for improvements comes up nevertheless and is a graphical mockup, it should contain some icons that are not available in a license compatible to the MPL/GPL/LGPL tri-license used in code. The Public Domain Tango icons (which could be used) should be as far as possible from the wanted look, and the well-matching ones from the mockup should be from e.g. Crystal (LGPL-only) or Oxygen (CC-by-sa/LGPL/CC-by-nc-nd) icon sets to make sure they can't just be integrated the way they are in the proposal. Don't make it easy for the contributor to follow a suggestion.
  8. If he decides to re-draw the icons himself to follow licenses and some icons already available in your application, and even contributes the SVG his drawing software did spit out (even if the code itself doesn't work with the SVG), then it's imperative to nitpick the source markup of those images, ignoring that only their rendering to bitmap images appears in the application. Ideally, have someone from your team rewrite them with said-to-be-better markup and different colors so any of his artistic creation is disregarded, his contribution mostly neglected and you make sure he can't take pride in any of his creation.
  9. When the patches come together - if you can't get rid of him before that - and get their first rounds of review, make sure someone comes in with a comment about how much he likes the previous design that had been agreed to be flawed and need improvements up to that point.
  10. In reviews, be as nit-picky as possible, don't let code in that isn't almost perfect, require coding standards that are different to everyone else around, esp. from usual Mozilla platform code, and never say thanks for the done work.

In short, make it as inconvenient as possible for the contributor to work in this environment, the Mozilla code base surely isn't scary enough by itself. The contributor should never have fun, and if he would at some point, make sure it subsides fast. Make sure he wants to cry over every single comment made about the area he is trying to work on.

Note that many of those factors may happen by themselves and you as core developer in the project may not be able to influence all or many of those factors. Also note that this is not supposed to be a rant about what happened to me in the progress window project, if it would be, I would write it differently, and some of the points above would be exaggerated. This is supposed to be a guide on how to get rid of outside contributors - or an ironic view of things to try to avoid if you don't want to lose them - whatever version you like or applies to you better. ;-)

February 25, 2010 03:20 PM

February 23, 2010

Thunderbird Localization

String freeze for Thunderbird 3.1 beta1 is today

I just wanted to remind everyone that today, Tuesday February 23 at 23:59 PST, the string freeze for Thunderbird 3.1 beta1 will go into effect.

We are planning to accept sign-ins up until Monday March 1 pacific time. Please use the new sign-in functionality in the l10n dashboard to become part of this release.

February 23, 2010 05:29 PM

February 22, 2010

Mark Banner

Nightly updates for l10n builds restored to Lanikai branch

Since we separated the Thunderbird 3.2 builds and moved the 3.1 builds onto the mozilla-1.9.2 branch, we’ve not had nightly updates being served for the localised builds (en-US has been working fine). We’ve now fixed the issues and nightly updates are  working again for the localised builds on Lanikai (Thunderbird 3.1).

Lanikai nightly builds for en-US can be found in the latest-comm-1.9.2 directory on ftp, the localised builds can be found in the latest-comm-1.9.2-l10n directory.

February 22, 2010 11:35 AM

Automated Tests for Thunderbird using MozMill - now on production tinderbox

A while ago I announced that we had automated UI tests for Thunderbird running on MozMill on our staging tinderboxes. Since then, we’ve been slowly writing more tests and fixing tests that were causing permanent or intermittent oranges.

At the end of last week we got to a position where we felt we could roll the MozMill tests out to our Windows production boxes. They have been running over the weekend and we’ve only seen two intermittent failures on Windows on the 3.0 branch (one of which I’m told is probably fixed already).

The MozMill tests can be found running on our Thunderbird, Thunderbird 3.1 and Thunderbird 3.0 trees on the “WINNT 5.2 comm-* check” boxes.

We are hoping that enabling Mac and Linux will follow soon. Mac seems to have one very frequent intermittent failure that we haven’t looked at yet. Linux has some bigger issues that we’re trying to hunt down. The status of these boxes is still available on ThunderbirdTest.

Obviously the tree rules for comm-central about not-regressing automated tests now apply to MozMill as well.

More information about Thunderbird’s use of MozMill in automated tests can be found here. We’ll be expanding the documentation over the next few weeks.

Personally, I’m really happy that we’ve got this far. These are our first automated UI driven tests (except for mailbloat which isn’t really driving the UI currently), and bring a new level of testing to Thunderbird. I’m sure they will help to prevent regressions and help thinking about different code paths when writing patches.

February 22, 2010 10:20 AM

February 20, 2010

Ludovic Hirlimann

Testers for Thunderbird 3.1b1 wanted

We are going to release Lanikai 3.1b1. I'm looking for volunteers to work on a complete test using litmus. These are the areas that need to be tested :


  1. Install, shutdown, uninstall

  2. Folder Views

  3. Migration

  4. Updating Thunderbird

  5. Import

  6. Window configuration

  7. Toolbars and menus

  8. Account settings & Preferences (Options)

  9. IMAP accounts

  10. POP accounts (exclude Global Inbox)

  11. Gmail Accounts

  12. .Mac accounts

  13. Global inbox

  14. Mail composition

  15. Spell checker

  16. RSS account & subscriptions

  17. Newsgroups

  18. Message Aging

  19. Navigating and displaying messages

  20. Downloading and saving

  21. Image blocking

  22. Return receipts

  23. Proxies

  24. Offline, disk space

  25. Moving, copying, deleting messages

  26. Views and labeling messages

  27. Message filters

  28. Message search

  29. Address search

  30. Virtual folders

  31. Message Grouping

  32. Quicksearch

  33. Address books

  34. Junk mail

  35. Extensions

  36. Theme management

  37. Help

  38. Printing

  39. Master Passwords & password management

  40. Phishing, spoof detection

  41. Secure connections

  42. Digital signing, encrypting messages

  43. Software Update

  44. Find as you type (FAYT)/Quickfind

  45. Windows Search and Spotlight integration

Like I did in the past, can you send me a private email to ludovic@mozillamessaging.com, telling me on which os you would use to participate and three areas you would like to test ( I suggest that you make your choice in that way , 1st area something you care about and are eager to test, 2 area something you can easily test, 3rd something you never used before ) so I can organize things. The last two times this worked pretty well - except for some people ending up testing things they didn't care about. So i'm trying to make this better by letting you choose before hand. I still need to aim for 100% coverage so you still might end up testing areas you didn't ask for.

February 20, 2010 03:05 PM

February 19, 2010

James Burke

RequireJS 0.8.0 Released

RequireJS, the next generation in script loading, now has an official release and a new web site: http://requirejs.org.

The 0.8.0 release is a formal release of the code, and it includes built versions of jQuery 1.4.2 with RequireJS already integrated.

I also updated my jQuery fork to include the latest changes -- jQuery's page load callbacks will not fire unless all scripts loaded with RequireJS have also finished loading.

I plan to do integrations with other browser toolkits, MooTools and Prototype being next on my list. I also hope the jQuery community will want to pull the changes I have in my jQuery fork into their master at some point.

If you are a team member for one of these toolkits, please let me know what I can do in RequireJS to provide the best code loading and module format for browser-based toolkits. It would be great if we can reach consensus on code loading. I am happy to make changes in RequireJS if it moves us all closer to that.

While the release version is 0.8, this code has been battle-tested in Raindrop, a sizable JavaScript-centric messaging web app. Raindrop uses a version of Dojo 1.4 that has been converted to the RequireJS module format, and all Raindrop modules are written as RequireJS modules.

Some other notes about the release:
Give it a spin! There is a moderated list if you have questions or need support.

February 19, 2010 07:52 AM

February 17, 2010

SeaMonkey

SeaMonkey 2.0.3 Security Update

As part of Mozilla's ongoing stability and security update process, SeaMonkey 2.0.3 is now available for Windows, Mac, and Linux as a free download from www.seamonkey-project.org.

We strongly recommend that all SeaMonkey and old suite users upgrade to this latest release. If you already have SeaMonkey 2.0, you will receive an automated update notification within 24 to 48 hours. This update can also be applied manually by selecting "Check for Updates..." from the Help menu.

For a list of changes and more information, please review the SeaMonkey 2.0.3 Release Notes.

Note: All SeaMonkey 1.x and old Mozilla or Netscape suite users are encouraged to upgrade to SeaMonkey 2.0.x by downloading it from www.seamonkey-project.org.

February 17, 2010 09:35 PM

February 16, 2010

Calendar

Short Update on Sunbird 1.0b1

I should have mentioned this in my previous blog post, but I do have a status update for Sunbird 1.0b1:

I have fixed 2 small packager errors yesterday, which now cause the automated builds to actually run. The first builds that succeeded are available on the ftp server, but we need to do another run that contains the second packager fix. If all goes well, gozer will have time to take care of this today, but the Thunderbird 3.0.2 builds have priority.

If all goes well, the upcoming build will become Sunbird 1.0b1 rc1. We will give another two weeks of QA time, if no critical errors show up then this build will become the final

February 16, 2010 11:28 AM

Whats going to happen in the next 6-8 weeks

As you may have noticed, not much has happened since the release of Lightning 1.0 beta 1. One reason for this is that I've had 8 Exams in the last three weeks, all of which needed quite an amount of preparation. I haven't gotten grades for all of them yet, but those I received so far were pretty good.

Now that all of this is through, I have a lot more time for Calendar. I will be enjoying semester vacation until April, which means I can catch up on all the calendar work I have missed.

I'd like to give you a short overview of what my next steps are, so you know what to expect.

This should keep me busy for a while, I'll post again when I have new goals to share. Let me know what you think!

Philipp

February 16, 2010 09:52 AM

Ludovic Hirlimann

Presenting the Thunderbird QA team, Interview #5 Nathan

Me :Hello Nathan, you've been doing a lot of triage work over the last few weeks, could you introduce yourself to our readers (age, location ... things you think a releveant) ?

Nathan :Well, I'm a 21-year-old software developer, living in sunny California - I don't specialize in C++ code, unfortunately, though. As a number of Mozillians seem to be, I'm a committed Christian.

Me :How long have you been a Thunderbird user ? What was the first version of Thunderbird that you used ?

Nathan :I've been using Thunderbird ever since I switched over from Outlook 2007 in mid 2007 - I must have gotten a pretty brand-new version of 2.0, but I didn't notice that at the time

Me :From that answer am I concluding correctly that you are a windows user ?

Nathan :Indeed so - I've been reasonably happy with Windows for half my life, though I've dabbled in Linux a good bit also. I even find Vista to be tolerable.. whether out of misplaced stubbornness, or some other reason, I don't know.

Me :As said earlier you've been giving a much appreciated help over the last few weeks, can you tell us why ?

Nathan :Well, I really started to dig into Bugzilla, finding and commenting on bugs I'd noticed, during the 3.0 release cycle, starting about b2. Then in December last year, I realized I had some extra time, so I volunteered for Litmus testing. One thing led to another, and just a couple weeks ago, I started watching my first QA contacts (only half a dozen, right now), and here I am!

Nathan :That, at any rate, is the sequence. My motive, on the other hand, is mostly that I know I can track down problems in and around Thunderbird fairly effectively, and there's definitely a need for help, so I'm trying to fill that as much as I can.

Me :Indeed , was the learning curve time consuming ? Was it difficult to get into it ?

Nathan :There's a fair amount of policy and guideline material to read first, but I actually like the formalization of it - it makes common sense and experience a lot faster to get a hold of. Filing bugs is definitely an art form, as it requires so much communication in such a small space.
That said, I don't think it took me more than a few weeks of a few hours a week to get into triaging, if even that - maybe because I'm already a developer? And it's not difficult, really, it just takes some persistence.

Me :Do you enjoy doing it ?

Nathan :Most of the time, yes, it's quite satisfying. I suppose that's because I'm taking a load off other people (developers, other QA), and also because I'm helping the reporters in most cases. On the other hand, I see some genuinely unclear and frustrated reports, and that's troubling, partly because I can't do much to fix those - maybe no one can, in fact. But it all balances out, and I'm still on the plus side of the ledger.

Me :How much time do you spend helping the QA effort , say weekly ?

Nathan :A good question. Right now, I'm probably spending maybe 5-15 hours a week on it - I'd give you more specific data, but my time-logging program seems to have gone kaput, so that's just my best guess. If I had to, I could easily reduce it just by watching fewer components - maybe down to 2 hours a week, or even less. But that'd be no fun!

Me :Any advice you would like to give to someone pondering about giving a hand ?

Nathan :Dive in. Like Wikipedia says, be bold! Any mistake can be fixed. But do read the instructions first, and spend some time looking at existing bug reports before making major changes - it'll save a lot of embarrassment later.
Oh yes, and one more thing:
Get another email account for bugmail!

Me :Lol !
Are there areas where you have more interest in than other ? if so which one(s) ?

Nathan :Right now, I'm mostly focused on the visible front end and the IMAP support - perhaps because I have nearly two dozen IMAP accounts, and am definitely a power user. (Scratching the ol' itch, you know?) Some of TB's internals and soon-to-be internals (Gloda, Jetpack, STEEL, etc) strike me as really cool, but they don't touch me as directly; maybe soon, though!

Me :Power user heh ! Do you use extensions ? If so can you lists the one you use ?

Nathan :Sure thing! But there's quite a lot..

Nathan :Add-on Compatibility Reporter, Nightly Tester Tools, Lightning Nightly Updater

Nathan :Bugmail, CompactHeader, CustomizeHeaderToolbar, Display Mail User Agent

Nathan :Mail Redirect, Signature Switch, jsLib, TagZilla, The Real Reply

Nathan :Diccionario español Argentina, Addressbooks Synchronizer, Duplicate Contact Manager, FiltaQuilla, JunQuilla, Lightning, TaQuilla, ThunderNote, ToneQuilla

Nathan :I keep trying ThunderBrowse, but for some reason, I can never quite get used to it.. I guess I'll probably never be a Suite/SM type of person. Seems a good extension, though.

Nathan :Those are just the enabled ones.

Me :What version of Thunderbird do you actually run ?

Nathan :3.0.1 mostly; I have a copy of 2.0.0.23 (re-installed just the other day, in fact) for troubleshooting, and maybe a nightly or so scattered around for the odd regression test. I'll probably start using 3.1b1 soon after it comes out, though I'll still maintain a 3.0.x install for testing.

Me :Anything you would like to add ?

Nathan :Hmm.. well, I would like to mention, on behalf of every QA person in existence, that it really helps if you follow the instructions on the Bugzilla entry form.. really really.

Nathan :I'd also like to thank the whole MoMo team for hanging in on the long road to 3.0! It's a great release.

Me :Thanks for helping and taking the time to do this. Next Time I'm in Mountain View we'll go for a drink !

February 16, 2010 07:49 AM

February 15, 2010

Thunderbird Localization

Updated release schedule for Thunderbird 3.1 (Lanikai)

There are some news regarding the Thunderbird 3.1 release schedule, which I wanted to share with everyone:
  1. The Thunderbird developers have decided to add another milestone (the Thunderbird 3.1 beta2 release) to the Thunderbird 3.1 schedule. This additional milestone will approximately add one month to the overall release schedule. That means that the release date of Thunderbird 3.1 is now estimated for June 1, 2010.
  2. The string freeze date has been shifted accordingly. The overall string freeze for Thunderbird 3.1 will now coincide with the Thunderbird beta2 string freeze, which is currently scheduled for March 23, 2010.

February 15, 2010 09:31 AM

February 14, 2010

Andrew Sutherland

Thunderbird Message Filter Bar Prototype Extension, check it.

What was just the quick-search box in Thunderbird 2 is now also the home to global search in Thunderbird 3.  This hasn’t turned out splendidly, although we didn’t expect that it would.  Some people think quick-search is gone because they do not realize you can change the modes of the search box.  Other people are hardcore and know how to switch between the modes, they just don’t like all the clicking.

So we’re thinking about splitting the quick-search out into its own separate box.  In addition, we’re trying to expose a lot of the power of the “mail views” system.  You may know “mail views” as that boxy thing that lived with the quick-search box above the thread pane in Thunderbird 1.5 but then became something you had to customize onto the toolbar at some point.  It looks like this:

Thunderbird has a very nice search subsystem under the hood that powers quick-search, “advanced search”, virtual folders, etc.  Mail views was and is the mechanism that allowed you to define arbitrary searches and use them as filters on any folder.  Unfortunately it’s not a smooth operator and its defaults have some issues.  There’s no “starred” filter unless you define your own, there’s no “any tag” filter unless you define your own, and “People I Know” only checks one of the two address books you are likely to have in your profile.  Even with those defined, you’re looking at 3 clicks to get to most things.

So the message filter bar is also trying to bring one-click access to these things you might care about.  In the top screenshot, that’s what you’re looking at.  Starred messages, messages from people in any of your local address books, messages with tags, and messages with attachments are all at your fingertips.  The new quick-search location over on the right works right with them.  And if you love mail views and all the clicking-finger muscle strength it helps build, it works with mail views too!

One bit of polish that I’m hoping people like and performs sufficiently well is the tags case.  When you haven’t clicked on the tags icon, the bar in the screenshot does not show that bit with the tags.  When you click on it, it 1) filters the visible messages to messages with tags, and 2) figures out what tags are on those messages and populates that bar with those tags.  You can then click on any of the tags to stop including messages with that tag (and none of the other tags still selected).

In any event, if you are interested, the prototype is being developed as an extension that you can find here on AMO (sandboxed) if you like pre-built XPIs and here in hg if you like source code.  It is very prototype-y at the current moment.  Keybindings aren’t there, localization/accessibility is not there, being able to make the filter bar go away isn’t there, etc.  We will iterate on things and productize assuming the concept works out.  Just be aware that I don’t believe sandboxed plugins auto-update, so you if you’re really interested you might need to keep an eye on the AMO page or the repo.

February 14, 2010 06:40 PM

February 13, 2010

Andrew Sutherland

Review Board and Bugzilla reviews, take 3

I’ve updated my review board setup once more (part 2, part 1).  The low barrier to entry is now even lower.  “How low?”, you might ask.  “On the ground!”, I might say.  “What other low low price features with big big value are on offer? With more facts and less spiel?”, you might then also ask…

Limitations and other notes:

February 13, 2010 06:20 PM

Kent James

Combining Thunderbird with SpamAssassin

For anyone who gets lots of spam mail, I typically recommend that their anti-spam management plan must consist of a multi-stage process. A common open source solution to that (and the one that I use personally) is a server-based SpamAssassin (SA) front end, followed by a client-based bayes filter, in this case the Thunderbird (TB) default filter. Both filters are tuned to never give false positives, with Uncertain emails show in an Uncertain folder that I regularly watch.

In the Thunderbird 3.0 / SeaMonkey 2.0 series, I snuck in a little hidden preference to allow modifications to the way that the TB bayes filter does it tokenization. The main point of this was to allow better transfer of information between SA and TB. I’d like to describe here how to use that feature.

SA’s decision process involves two key steps. First, they evaluate the message with zillions of rules, and tag the message with each rule that the message hits. Second, they have a method of combining all of those tags into a final junk score for the message, which is used to decide whether to tag the overall message as spam.

SA’s rules include many tests that are not done by TB (score one point for SA). Yet when they take all of their rules and combine them together, in most cases they are using broad measures of goodness and spaminess that apply to some concept of a universal email. In contrast, TB’s bayes algorithm will precisely tune the junk analysis to the particular set of emails that a user gets. So if you are in the Viagra business, you can tune your local TB filter to accept those. (score one point for TB).

Wouldn’t it be great if you could combine together the superior rule set of SA, with the superior decision making customization of TB? That is the point of the hidden preference.

SA communicates its message tags to TB in the form of a custom header, X-SPAM-STATUS. A sample value of that from a spam message that I got is:

X-Spam-Status: No, score=4.9 required=5.0 tests=HTML_IMAGE_ONLY_16,
HTML_IMAGE_RATIO_02,HTML_MESSAGE,HTML_SHORT_LINK_IMG_2,
MIME_HTML_ONLY, SPF_PASS shortcircuit=no autolearn=disabled version=3.2.5

This message was not marked as spam by SA, as it just barely missed the score=5.0 cutoff point, so arrives in TB as a suspicious but nevertheless good message. Yet there is lots of information about the tests that SA did in that header. TB should be able to take advantage of that information.

In the default TB configuration, the entire content of the X-Spam-Status header is treated as a single token. So TB will only respond to exact matches to that header. Yet those tests can appear in a variety of combinations, so that is not really taking advantage of the information effectively.

The answer provided in TB3 / SM2 is to provide a hidden preference that allows you to tell TB to break that particular header up into lots of separate tokens, and analyze each of those separately. That is documented in the code here. In the preference, you specify a particular header, and give a list of delimiters for that tokenization. So to process the x-spam-status header as individual tokens including both space and comma as delimiters, you add the preference:

mailnews.bayesian_spam_filter.tokenizeheader.x-spam-status

and assign it the string value ” ,\t\n\r\f”

(That can be hard to set with all of those special characters in it). That includes space, comma, tab, line feed, carriage return, and form feed as delimiters.

You really can’t do this to an existing training corpus without getting strange results. So you must reset the training data and retrain after you do that.

As a sample, the tokens used by TB to process an email with my example x-spam-status is:

This image uses the “Junk Analysis Detail” report from my JunQuilla extension.

Things to notice:

  1. The tokens that TB is using to analyze this email are mostly these x-spam-status tokens, as this is a mostly-image spam message with little text for TB to analyze. So the use of the SA tokens greatly enhances the power of TB’s internal filter.
  2. The final score for this, 84, ended up with the message marked as junk for me. I run a cutoff of 75, while the default cutoff is 90.
  3. Many of the x-spam-status tokens are actually working against us here. For example, x-spam-status:required=5.0 has a score of 23, which moves the message toward the “good” status. Yet that token appears on every single email I receive, so should be neutral. What is going on here?

    This is the issue that I reported in a previous post “bad effects on junk training corpus from change” That is, recently I have been automatically training more messages as Good than Junk. “x-spam-status:required=5.0″ must not exist in my older emails for some reason, so this bias is appearing because 1) the token changed at some point in time, and 2) there is a mismatch in the number of junk and good emails being trained recently. I really need to figure out a solution to this. What I will probably do is to add features to FiltaQuilla to allow me to precisely match the training of junk and good to remove this bias.

I still need to do some tests of this to directly compare the performance of the spam filters with and without the tokenization to be sure this is really a good idea. That is quite tricky to do unfortunately.

In spite of these issues, I would recommend to new installations that you use this alternate tokenization when you are using a Spam Assassin front-end to Thunderbird or SeaMonkey.

February 13, 2010 01:22 AM

February 10, 2010

David Ascher

Thunderbird in 2010

2010 will be a big year for Thunderbird. Last year, we launched Thunderbird 3, which is a huge milestone for us. In this post, I’d like to give people a heads-up as to what the coming year will look like. I’ll focus on three topics: our plans for innovation through add-ons, Thunderbird 3.1, and our first steps towards making Thunderbird self-sustaining.

Innovation through Add-ons

We believe that Thunderbird is a much better development platform than ever. This means that building innovative experiences on top of Thunderbird is easier than ever. We’ll be building on that platform ourselves and helping others innovate as well. In particular, we’re going to be using add-ons in a few ways:

Having core engineers develop add-ons is also one of the best ways to ensure that the add-on platform is as good as possible.

Thunderbird 3.1

In parallel with some exciting innovations in add-ons, we’ll be pursuing more gradual change strategies within Thunderbird 3 itself.

Thunderbird 3.0 is getting security & bugfix releases (3.0.1 is out, 3.0.2 is coming soon).

Thunderbird 3.1 is also underway. We’ve already released the first alpha, and a first beta is getting defined. It will be focused on a couple of areas:

Ensuring Economic Sustainability

Thunderbird deserves to be self-sustaining. Paying one’s way is a great validation of any effort, and it’s in the interest of Thunderbird users everywhere that we figure out a way to get there. As promised when we formed Mozilla Messaging, we’re starting to explore ways to make Thunderbird self-sustaining while at the same time promoting the Mozilla mission (as articulated by the Mozilla Manifesto). We’re specifically looking to identify business models that create economic value by improving the user experience of Thunderbird users. This is nothing new for Mozilla. The foundations of an open source codebase, the ability for users to opt-out of commercial relationships, and an architecture that allows plugging in alternative providers for whatever service or product we end up partnering with are non-negotiable requirements. With that as a foundation, we’re looking for ways to make the online life of our users better, and within those ways, identifying those which can help ensure Thunderbird’s long life.

This will happen through a set of public opt-in experiments. For each business model that we try, we’ll build a prototype, announce it, get data to evaluate it, solicit feedback from users, and evaluate whether it’s worth continuing. Anecdotal data suggests that plenty of Thunderbird users are happy to be offered commercial services which provide them value and help Mozilla too.

In addition, I’ll be actively soliciting input and help from what I’d like to call “business contributors”. Just like we encourage programmers and others to contributing to Mozilla through patches and other internet-mediated activities, I’m going to setup ways to “open source” the business model and business development activities. I’ve found in conversations with my peers that almost every business leader who’s aware of what we do would like to contribute, but we haven’t made it easy. Identifying and facilitating such contributions is one of my personal goals for the year.

To start, here are two possible ways for business folks to contribute:

I’m looking forward to the conversations!

February 10, 2010 09:50 PM

Kent James

My uber-cautious checkin procedure

Since I see that checkin errors are fairly common, and a poorly controlled source of potential issues in Mozilla code, I developed my own written process that I follow whenever I do checkins. It’s probably over cautious, with a practice checkin locally before I do the real thing, but here it is in case anyone else is interested. This is my actual text, with little massaging for general audiences:

====
Check tinderbox for current checkin status and burns

(cd pristine/src) [This is a directory containing a clone of comm-central from mozilla]
hg pull –u

(cd mozpush/src) [This is a directory containing a clone of my local pristine repository]

hg pull –u

(If there are problems, create a new mozpush directory, and do
hg clone /s/tb/pristine/src src)

hg import /f/tb/patch/name.patch
(above starts notepad, give bug & approvals and save)
hg outgoing -p
(check that the patch and comment are correct)
hg push

(cd pristine/src)
hg pull –rebase
(if changes, you may need hg update, or hg rebase -s revision -d revision)
hg outgoing -p

(if everything looks good)
hg push

Go to http://hg.mozilla.org/comm-central/shortlog and get the diff link for the push, something like:

http://hg.mozilla.org/comm-central/rev/324e7b178ad7

(or http://hg.mozilla.org/releases/comm-1.9.1/shortlog )

Go to bug, comment on checked-in attachment with above link.

Mark resolved/fixed, and add the appropriate pristine/src Target Milestone.

(when you checkin to comm-1.9.1, please set the status-thunderbird3.0 field to “.1-fixed” (or whatever the appropriate dot release is)

Follow tinderboxes.

February 10, 2010 05:50 PM

James Burke

RunJS is now RequireJS

As mentioned before, I considered renaming RunJS to RequireJS. I did the transition, and RequireJS is on GitHub. There is a conversion script that will convert CommonJS modules to the Transport/C proposal that works with RequireJS.

I have converted Raindrop to use a modified Dojo 1.4 that uses RequireJS instead of the normal Dojo loader, and all Raindrop modules are written in the Transport/C module format that RequireJS understands. Raindrop works, so the RequireJS code has been proven in a real project that has many modules with nested dependencies. The RequireJS code is already battle-tested.

I have opened a thread on the jQuery forum about using RequireJS for jQuery's require() needs. I can do a build with Dojo 1.4 that uses RequireJS, and any Dojo 2.0 effort is likely to use RequireJS as the module loader.

I believe RequireJS is the loader browser-based toolkits should use. At the very least, the module format and API supported by RequireJS should be used by browser-based toolkits, even if they want to build their own loader.

Next plans for RequireJS:

1) Contact the MooTools and Prototype folks to see if they want to use it. It allows loading code that does not export a module value, and has access to the global environment. They can use it to load code that augments native prototypes. RequireJS can load existing, plain JS files that do not define a module too.

2) Put up a web site with builds. While you can use RequireJS just from grabbing it from GitHub, it would be nice to have the builds of RequireJS with its different levels of functionality already built and easy to download.

2) Do a fork of Node that uses RequireJS on the server. I believe the async module format used by RequireJS is great fit for Node and its async goals.

3) See if I can do a fork of Narwhal to do the same thing.

I believe I can get RequireJS to work on the server and still support the existing CommonJS format when the server supports synchronous loading. By having native support in some server-based systems for RequireJS, it will be easier to share code with the browser.

To recap, my three main issues with using the existing CommonJS module spec, and why RequireJS exists:

1) So far the CommonJS group does not think the browser is common enough to qualify as a first class citizen in the module spec. The group is mainly concerned with environments outside the browser. As a result, the CommonJS module spec does not work well natively in the browser -- it either requires an XHR-based loader, which we have found to have problems in Dojo, or require a server-side transform process. A server-side transform process should not be required to do web development in the browser.

RequireJS uses a function wrapper around the module to avoid these problems and allow loading modules via script tags. Just save the file and hit reload in the browser.

2) There is a free variable, called "exports". It is an object. You cannot set the value of exports inside your module code, you can only add properties. This means for instance, your module cannot be a function. In Dijit, Dojo's widget system, all widgets are constructor functions. The "exports" restriction makes your APIs awkward if you want to export functions for module values. The claim is that this exports restriction helps with circular dependencies, but it only helps a little bit. To me, it is not worth slightly improving an edge case when it sacrifices a greater usefulness and simplicity in user's modules.

RequireJS and its format can handle circular dependencies just fine. In the format supported by RequireJS, you to define a module as a function. Although, you can still use exports as CommonJS uses it if you so desire.

3) The require.main property seems like a hack. It is normally used so that a module can say if (require.main === module.id) or if (require.main === module) then do some "main" work. The module format should just define an exports.main convention for indicating "main" functionality. It is less typing, and more robust, since different code entry points have a different idea of "main". For instance, an HTTP request handler likely has specific requirements on what it considers to be the "main". The top level entry point should decide what code to execute as "main", not logic inside the module.

RequireJS does not support the require.main idiom.

So I believe the path used by RequireJS is more robust overall, works better/scales better in the browser. However, I still want to provide enough support for the existing CommonJS modules in the meantime to allow more code sharing.

In the long run though, the CommonJS format as it exists today should be replaced with something better. It is troublesome that the CommonJS group is not really targeting the browser, but over time, the broader JS community will expect browser toolkits to support CommonJS specs. It does not seem right to end up with non-optimal solutions in the browser when the browser is the most common JS platform.

February 10, 2010 05:27 AM

February 09, 2010

David Ascher

Ikea Canada: WTF?

A few months ago, we needed more desks for our office, so I figured I’d order them from the Ikea website. Easy to do, except that the Ikea.ca store doesn’t work with US credit cards, and our corporate card is a US card. So I bite my tongue about the craziness of e-commerce in Canada, knowing it’s not just an Ikea problem, and I use my personal card, and will deal with expensing it internally. Annoying, but oh well.

Then I’m blown away because delivery takes eons, because the desks have to come from the “online distribution center” in Quebec (”it’s Canada, so it’s got to be close, right?”), and not from either of the two warehouses within 20 miles of the delivery address (who do have the items in stock!). But I’m busy, so I live w/ the delay. Environmentally criminal, but oh well.

This month, we need more desks, and I’ve learned my lesson, so I know to take time out of my weekend to go to Ikea, order the desks and chairs. After about 45 minutes in the store, it looks like we’ll have delivery on Tuesday morning. A few high-end desks and what seems like their most expensive chairs, but I have a soft spot for Ikea, and their furniture is working out fine for us.

Turns out the chairs aren’t in stock, so they have to be scheduled for delivery a few weeks out and delivery has to be charged separately. Annoying, and a bit more expensive, but oh well.

Monday, they call and say that we hadn’t talked about delivery times (we had), and we reschedule it for the same day/time. Seems disorganized, but oh well.

Tuesday, they come and call my cell to let us know they’re downstairs, but I’m on the phone on an important call, and I thought it was someone else, so I figure I’ll get the message when I’m done with my call. By the time I get off the phone, I’m told they went on with their route, and I need to reschedule another delivery, which will cost me $75. Frustrating, but I blame it on the olympics and how it’s messing with deliveries everywhere, and blame myself for not taking the call, but oh well.

I call back to reschedule, and I’m told that I need to go back to the store to reschedule, because I need to pay for another delivery. WTF? After a bit of back and forth with the CSR, I ask to talk to a manager, and I’m told to do that I need to go to the store. WTF? I then ask about canceling the order, and I’m told that, you guessed it, I need to go back to the store.

Oh, if I want to lodge a complaint, I can do it on their website. I’ll definitely be sending them a link to this page.

I guess I know what I’m doing this weekend. What I’m not sure of is where I’ll get the next batch of furniture from. What a totally horrible customer experience, just because they don’t have a system for paying over the phone (or, hey, the internet?!?!) for silly delivery fees.

February 09, 2010 06:47 PM

Ludovic Hirlimann

What is the best bleeding edge

At the moment If you want to run a bleeding edge version of Thunderbird, you need to choose between running 3.2x and 3.1x builds. In fact, it appears that most people willing to run bleeding edge are now running 3.2x builds.

Whilst our most dedicated testers are running 3.2x builds, the engineering team is working on bringing features and bug fixes to the 3.1x branch. There's a discrepancy here. This means that the issues that might exist in 3.1x have a greater chance to be discovered after releases rather than before. It's easy to fix that, instead of running 3.2x builds, we would like our bleeding edge user to use the 3.1x builds (you can find them at http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-comm-1.9.2/). By doing this simple switch you'll help to make the 3.1 series a great series.

February 09, 2010 09:12 AM

February 08, 2010

Thunderbird Localization

The death of opt-in threads is imminent

Good news, for localizers. With the new release of the l10n dashboard, co-developed by Pike (Axel Hecht) and Gandalf (Zbigniew Braniecki) we're killing off the opt-in threads for localizers.

Every localizer should take a close look at all the functionality that the new dashboard exposes. There is also a 5-minute screencast, that hopefully guides you through some of the new features.

We'll start to use this new functionality once Thunderbird 3.0.2 is out of the door. So Thunderbird 3.0.3 and onwards as well as Thunderbird 3.1 beta1 will be our starting points.

February 08, 2010 01:32 PM

February 05, 2010

Joshua Cranmer

Developing new account types, part 1: The folder pane

This series of blog posts discusses the creation of a new account type implemented in JavaScript. Over the course of these blogs, I use the development of my Web Forums extension to explain the necessary actions in creating new account types. I hope to add a new post once every two weeks (I cannot guarantee it, though).

In the previous blog post, I gave a broad overview on the overall structure of the backend interfaces and the components of account implementation. Now, we will prepare the necessary components of getting your extension's folder displayed in the folder pane.

Account implementation decisions

Before you start implementing, you have to decide how to structure the account. The first decision is what the internal account type will be. This will be the value of nsIMsgAccount::type and will dictate the contract IDs for several interfaces. The next decision is what the account URI scheme is. This will be the scheme for the URI and dictates the contract IDs for a few more interfaces; for mailbox accounts, this scheme will be mailbox. For my extension, I have decided to choose webforum for both of these.

Another important decision to make will be the server for which you will be doing most of your initial tests. It should be something that is manageable for debugging purposes. In my case, I've decided to bestow this honor on the Kompozer web forum, because it seems lower traffic than any other forum I'm reasonably interested in. As you may notice, I am starting my extension with the intention of focusing on phpBB access—it's sufficiently widely used that I expect that only supporting phpBB at first would still make a worthwhile extension.

Once you have decided that, you should take the time to study how things will be structured: what determines a folder? What determines a message? A thread? Replies? How are you going to be carrying out new actions, such as checking for new messages? What internal information are you going to need to save for accessing? Heck, what determines the "server" to begin with? In my case, the DOM inspector is an invaluable tool for answering this questions. Don't worry about how to figure out the list of possible subscribable folders yet. Subscription will come into play much later; we are going to start by just hardcoding this list somewhere.

In my case, I am choosing to structure the folders as a Category → Forum hierarchy. I'll pick a few of the smaller forums to use so I don't overwhelm debug logs.

Implementing protocol information

Since nsIMsgProtocolInfo is the shortest and simplest of the interfaces, let me start by implementing this one. There are a total of 12 attributes and 1 function on this interface, so the code will not be hard to write. Following is an implementation of the code [1]: 

wfService.prototype = {
  contractID: ["@mozilla.org/messenger/protocol/info;1?type=webforum"],
  QueryInterface: XPCOMUtils.generateQI([Ci.nsIMsgProtocolInfo]),

  // Used by the account wizard and account manager
  get defaultLocalPath() {
    let dirSvc = Cc["@mozilla.org/file/directory_service;1"]
                   .getService(Ci.nsIProperties);
    let file = dirSvc.get("ProfD", Ci.nsIFile);
  file.append("WebForums");
    if (!file.exists())
      file.create(Ci.nsIFile.DIRECTORY_TYPE, 0775);
    return file;
  },
  get serverIID() { return Ci.nsIMsgIncomingServer; },
  get defaultDoBiff() { return true; },
  get requiresUsername() { return false; },
  getDefaultServerPort: function (secure) { return -1; },
  get canDelete() { return true; },

  // Used by UI code
  get canLoginAtStartup() { return true; },
  get canGetMessages() { return true; },
  get canGetIncomingMessages() { return false; },
  get showComposeMsgLink() { return false; },
  get specialFoldersDeletionAllowed() { return false; }
};

The meaning of each of the attributes can be found in more detail on the MDC page. The properties used by the account wizard mostly control initial preference values; those used by the UI code mostly control which UI elements are enabled. I have excluded from the implementation also those attributes which are unused.

Perhaps the most leeway you have is in implementing defaultLocalPath. In this case, I have adapted the RSS implementation, which does not allow users to change this location. The other implementation (used by IMAP, POP, NNTP, Movemail, and Local Folders) uses a preference to return the default path. An example implementation of this method is like thus: 

get defaultLocalPath() {
  // This will probably be found in the constructor
  this._prefs = Cc["@mozilla.org/preferences-service;1"]
                  .getService(Ci.nsIPrefService)
                  .getBranch("extensions.webfora.");
  // Preference looks like [ProfD]WebForums
  let pref = this._prefs.getComplexValue("rootDir", Ci.nsIRelativeFilePref);
  return pref.file;
},

Once you have completed that, you should test that the service implementations work as expected via test snippets in the Error Console. The account manager can be mean when it comes to unusable account types [2], so this will help fix the most obvious bugs before the account manager attempts to do it for you.

Server and root folder discovery

Before I start going any further with code, let me take a minute to explain how servers and folders interact. The server objects themselves do surprisingly little in the UI; the most common property calls are probably rootFolder and type. This even includes what you might think of as server attributes: the bold display name, has new messages treeview properties, etc. Instead, those features can be found on the root folder, which is a "fake" folder object. Most of what we care about in this part happens on the root folder instead of the server; however, if you browse the implementation in nsMsgDBFolder, you can see that some of the property calls get forwarded back to the server for root folders.

The backend code will create server objects early on and hold onto them for the duration of the program (or until they are deleted). The server objects then create the root folders which then create subfolders as necessary. Links that go backwards (parent links and server links) are weak references to avoid refcount cycles. Most of this work is hidden in nsMsgDBFolder for you. After creation, various properties are accessed at will; some properties will be loaded in from the database info (a topic for later).

In more concrete code terms, the following is the steps in loading the folder pane:

  1. The account manager loads the mail.accountmanager.accounts preference; the values here are a comma-separated list of account keys.
  2. For each account key, an account is instantiated. Per-account data is read off of the mail.account.<key> preference branch; in specific, the server preference contains the server key to load and the identities preference is a comma-separated list of identity keys.
  3. The identities and servers are then bootstrapped. In the case of servers, the server is created as an object with the @mozilla.org/messenger/server;1?type=<type> contract ID. The server pref branch is mail.server.<key>; key preferences here are type, the type for the contract ID; userName, the (optional) username of the server; and hostname, the (required) host of the server.
  4. The account manager sets the key, type, username, and hostName properties, in that order on the server object instance and then retrieves the port property. The (type, username, hostName, port) tuple is the unique identifier for a server: no two servers can have the same combination of these values. Now your server is constructed and returned to the folder pane.
  5. The folder pane retrieves the rootFolder of your server. If you happened to be saved in the expanded state, subFolders is recursively retrieved from folders as corresponding to the saved open state. The folder pane also calls performExpand() on the server if the root folder is expanded.

So that explains how your server gets created; how do your folders get created? nsMsgIncomingServer::GetRootFolder [3] calls nsMsgIncomingServer::CreateRootFolder, which calls serverURI and uses it to construct an RDF resource. serverURI creates a URI of the form localstoretype://[<username>@]<hostname> by default. This URI is actually the URI of your root folder; other code will assume that this invariant holds true (especially subscribe!). Other folders are created when you get the subFolders property. When the folder URI is parsed (which is pretty much the first time a useful property is called), getIncomingServerType is called to get the type of the server.

In summary, you may need to implement localStoreType and possible serverURI on your server, and subFolders, and getIncomingServerType, and CreateBaseMessageURI on your folder [4]. First we'll start by getting the root folder display working: 

function wfServer() {
  JSExtendedUtils.makeCPPInherits(this,
    "@mozilla.org/messenger/jsincomingserver;1");
}
wfServer.prototype = {
  contractID: ["@mozilla.org/messenger/server;1?type=webforum"],
  QueryInterface: JSExtendedUtils.generateQI([]),
  get localStoreType() { return "webforum"; }
};


function wfFolder() {
  JSExtendedUtils.makeCPPInherits(this,
    "@mozilla.org/messenger/jsmsgfolder;1");
}
wfFolder.prototype = {
  contractID: "@mozilla.org/rdf/resource-factory;1?name=webforum",
  QueryInterface: JSExtendedUtils.generateQI([]),
  getIncomingServerType: function () { return "webforum"; }
};

At this point, I recommend you again check to make sure resources are properly registering via the Error Console. With that in hand, it's time to modify your preferences manually. I personally recommend changing settings via editing prefs.js while Thunderbird is off so you don't accidentally confuse the account manager. I'm using the keys account99 and server99 to make it plain which account is being edited. First, I copy the mail.identity.id3 pref branch (any identity would do) and change the id3 to id99. Then I copy the mail.account.account3 pref branch and change the 3's to 99's.

The next changes are the server preferences, which are going to be the most unique. directorydirectory-rel are set to a folder where I want to store stuff ([ProfD]WebForums/kompozer, in my case). download_on_biff and login_at_startup are set to false (to avoid dealing with biff for a bit longer). name is set to be the display name of the server. hostname and userName were set to the appropriate values for this account [5]. To the preference mail.accountmanager.accounts, I appended account99. With those changes done, I then start up Thunderbird to see the outcome:
Root server in folder pane
Perhaps I should have chosen a shorter name for display.

Folder discovery

Now that the root folder is displayed, we need to get the folders added to the display pane. Somehow, we need to figure out what the folder hierarchy looks like—it has to be stored in some file, in other words. The NNTP code uses the newsrc file to store its folder tree, and local folders looks at the directory hierarchy for its map, to name two examples.

In my code, I'm going to choose the use of a JSON file to store this data. I've considered SQLite, but I don't really need synchronization (per-server files work nicely here), and I'm mostly doing simple lookups. Plus, I can probably handle automatic schema migration more easily in SQLite.

For this next part, we concentrate on a single property: subFolders. This function typically has two parts: it first checks for initialization (if so, it returns the enumerator to the stored values); if it's not initialized, the rest of the function, or perhaps a second function altogether, is used to create the subfolders.

Some code to initialize these subfolders is as follows (the logic to retrieve the database is not included and can instead be found in the source code for my extension): 

 get subFolders() {
    if (this._folders)
      return array2enum(this._folders);// If we're here, we need to initialize.
    this._inner.QueryInterface(Ci.nsIMsgFolder);
    let serverDB = this._inner.server.wrappedJSObject._db;
    // Uninitialized -> no subfolders
    if (!serverDB.categories)
      return array2enum(this._folders = []);

    // First find our level
    let level = /* some logic */;

    let URI = this._inner.URI + '/';let folders = [];
    // Yes, we still use RDF
    let RDF = Cc["@mozilla.org/rdf/rdf-service;1"].getService(Ci.nsIRDFService);
    let netUtils = Cc["@mozilla.org/network/io-service;1"]
                     .getService(Ci.nsINetUtil);
    for each (let sub in level) {
      // Some URIs may contain spaces, etc. -> escape
      let folder = RDF.GetResource(URI + netUtils.escapeString(sub.name,
        Ci.nsINetUtil.ESCAPE_URL_PATH));
      folder.QueryInterface(Ci.nsIMsgFolder);.parent = this;
      folders.push(folder);
    }
    this._folders = folders;
    return array2enum(this._folders);}

There are a few major things to note. First, the new folders are created via the RDF resource. Both Thunderbird and SeaMonkey use RDF for folder access, so it is still a good idea to create via the RDF service so you don't confuse the caller code. Also, with that in mind, the subfolder name still needs to be escaped as well in the URI, hence the calls to nsINetUtil. The auxiliary function array2enum takes in a JS array and returns a proper nsISimpleEnumerator for the array. I've excluded it's definition here do to its simplicity and the length of this document; if you want to see it, you can view it from the extension source code. The last thing to note is that this code is using this._inner: this variable is a link to the nsMsgDBFolder implementation which was created for us by the JSExtendedUtils inheritance call. I will defer a more thorough treatment of this C++-JS glue until later.

Folder pane extras

At this point, you should have a simple, plain folder hierarchy, which is navigable if not fully usable. In terms of UI, though, it's not quite fully perfect: if you have an inbox, it will be rather indistinguishable from other folders; similarly, "fake" folders (think the [Gmail] folder if you have Gmail IMAP) show up as regular folders. These things are handled to a large degree by CSS.

A full list of the available of the styling points for the Thunderbird folder pane can be found on MDC. Extensions can also modify the folder pane views or add other, non-folder items. More information can be found at MDC's folder pane information page.

I would provide some example styling code here, but when I was doing testing, I discovered some related assertion failures that I have not yet had time to grok. In the interest of keeping to a posting every two weeks, I am going to defer this until either a mini "part 1.5" or the beginning of part 2, depending on how much time I will have available next week.

Notes

  1. I will not, in general, post the full code for any of the classes, only enough to demonstrate what needs to be done. For example, the classID property is omitted in this example. Something to note is that I have a modification to XPCOMUtils locally that will accept arrays of contract IDs as opposed to a single one (wfService will be implementing more than one contract ID).
  2. What it specifically does is attempt to get the server; if it fails, then it removes the account from the accounts pref. If you are compiling your own builds for your extension development profile, I recommend you remove the lines in nsMsgAccountManager::LoadAccount that remove the account on failure.
  3. In general, I will mix the IDL and C++ names for methods and properties in the course of the guide. As a basic rule of thumb, if you see a :: in the name, it's a C++ name; otherwise, it's the IDL name.
  4. getBaseMessageURI is a local function called by nsMsgDBFolder during initialization that is used to set up the URIs for getting individual messages. This function will be covered in more depth as we get messages working, but it is technically necessary for startup (a stub that does nothing is provided).
  5. A strong temptation for accounts whose sources are some web address (for example, RSS or my web forums account) is to put the base address as the hostname property. However, as you would quickly realize, that plays havoc on URI parsing, and nsMsgDBFolder::parseURI is not virtual. A better option would probably be to leave the hostname as some identifier that you use only for guaranteeing uniqueness and to store the base URI somewhere else. Since all of my folders have independent URIs associated with them, I can safely ignore the issue until account creation and subscription are covered.

February 05, 2010 11:25 PM

February 04, 2010

Dan Mosedale

Lanikai Alpha 1

Thanks to hard work by a whole bunch of folks, we shipped Lanikai Alpha 1 (the first development release of Thunderbird after 3.0) yesterday. More details about Lanikai can be found on the project page.

This release is a first in several notable ways:

* we're now requiring automated tests to land with most code changes
* the release cycle was much shorter than any development release in recent memory
* we're now having to do development and releases across both a development and a stability branch.

We've already learned a bunch of stuff from all the changes, and I expect that learning to continue for a little while before we're fully in a groove.

Thanks to everyone who has been part of making the release happen!

February 04, 2010 09:59 PM

Raindrop Design

Read/Unread

Recently I’ve been talking to Bryan about how we can differentiate between Unread and Read messages. Before we were simply using background colors to indicate old vs new. We felt this created too much of a responsibility to mark everything as read, and wanted something more subtle. We decided to leave the background color white no matter what, and simply change the way information is presented in older messages. We also make a subtle but obvious change in the opacity of the message title in older messages.


A message appearing as unread. We display full information, preview the message body, and thumbnail attachments.


The same message appearing as read. We display less information, cut out the message body preview, and summarize attachments.


An even more compressed version of a read message.

February 04, 2010 08:14 PM

February 01, 2010

Kent James

Toward mailnews Exchange Web Services support: SOAP calls

I’ve embarked on an effort to investigate adding support for Exchange server to the mailnews code. Although Exchange in Windows has traditionally used port 135-based protocols, my understanding is that the future for them is SOAP-based Exchange Web Services (EWS). As a first step, I wanted to get a basic SOAP library working in current mailnews code.

I considered a variety of approaches to this. One extension “Asertiva Thunderbird Extension for Sugar” uses the IBM/Prototype js library for SOAP access. Others recommended that I consider one of the open source SOAP libraries, such as a python-based library, or Apache’s AXIS2 library. Or that I cooperate with the existing project to provide an open-source method of accessing Exchange server.

But I’m not sure of how “open source” I want all of this to be. From my perspective, “open source” as a charitable activity is not successful. We all need to eat, and so the revenue model needs to be clear if a project is going to be more than a phase of life I am going through at the moment. So I would rather keep my options open until I understand that better. Anyway, that’s a long discussion which is beyond the scope of the current posting, which is supposed to be a status update.

I am still in an education phase, trying to understand SOAP and the related protocols, and to figure out what exactly I gain from using any existing library versus doing things more directly from the raw XML. So as both a trial and education step (and against the recommendation of others I might add) I’ve tried to update the old Gecko webservices extension to work in current Gecko 1.9.2, and to work with some current Microsoft SOAP protocols.

Rather than start with EWS, I started with the simpler BING search calls. I used existing Microsoft demos in C#, and could capture the communications using Wireshark to see what I was supposed to be sending and receiving.

Updating the abandoned webservices extension to Gecko 1.9.2

After testing webservices some under an old Firefox 2 build, I upgraded portions of the code to work under a current comm-central trunk build, using Gecko 1.9.2. My requirements are somewhat simpler than the original extension:

  1. Most importantly, my target is chrome-based extensions rather than browser code, so a lot of the security issues that FF folks worried about were not important to me.
  2. I had no interest also in allowing native JS creation of components, as I could rely on using .createInstance calls instead.
  3. At least initially, I am not supporting the reading of wsdl files, nor the associated automatic creation of proxy calls and interfaces. Instead, I read in a schema file, and generate my own code for each method. My understanding is that Microsoft, in their EWS libraries, also does not actually automatically generate method calls from a WSDL-based proxy, but follows this same approach of starting with the schema files.

That allowed me to avoid about half of the existing code, and focus on the /schema and /soap directories of the webservices extension.

Looking at my hg logs, it took one week of development time, and 17 patches to get to the point where I could write a unit test under Gecko 1.9.2, and confirm that I could create webservices components using a unit test. (I’m doing things in a test-driven development fashion, writing XPCSHELL unit tests to try out different features of webservices.)

Learning and testing Gecko webservices

Although there was a little old documentation around on Gecko webservices, ultimately I just needed to learn things the old fashioned way, reading the code and its interfaces and experimenting to see what worked. I took little baby steps, starting first with an XML schema primer and eventually working my way toward duplicating the functionality in some Microsoft Bing search demo C# code. This phase, starting from the first demonstration of loading of SOAP components under Gecko 1.9.2 through testing of encoding and decoding of a Bing search message, took about 2 weeks of coding and 23 patches, with the creation of 22 unit tests in the process.

The main issue that I had to deal with in the existing SOAP code is that it did not support maxOccurs>1 schema types, such as this one from the Bing schema:

<xsd:complexType name="ArrayOfNewsArticle">
  <xsd:sequence>
    <xsd:element minOccurs="0" maxOccurs="unbounded"
                 name="NewsArticle" type="tns:NewsArticle" />
  </xsd:sequence>
</xsd:complexType>

I solved this by using an nsIArray to hold multiple values of the same element.

Sample Code

So now I can do a Bing search in an XPCSHELL test, and decode and test the results. I want to show some of the js that I use, to give some idea of the complexity (or lack thereof) of using this.

I create a class BingSearch, then encode some values to setup the search. A basic call for a search looks like this:

function run_test()
{
 do_test_pending();
 getNews = new BingSearch();
 getNews.Query = "obama";
 getNews.Options = ["EnableHighlighting"];
 getNews.Sources = ["News"];
 getNews.News = {Offset: 0, SortBy: "Relevance", Count: 1};
 getNews.invoke(getNewsListener);
}

The “BingSearch” object is presumably what a sophisticated library would create automatically from the WSDL file. Instead, I create it by hand. Here’s my partial implementation, that does not support all of the allowed inputs to a Bing search, but works for my tests:

function BingSearch()
{
 // defaults
 this.Version = "2.0";
 this.AppId = "<you get this from Microsoft for your application>";
 this.Market = "en-us";
}

BingSearch.prototype = new BingBase();

BingSearch.prototype.invoke = function BingSearch_invoke(aSOAPResponseListener)
{
 let parametersBag = objectPropertyBag({
   Version: this.Version,
   Market: this.Market,
   Query: this.Query,
   AppId: this.AppId,
   Options: arrayPropertyBag("SearchOption", this.Options),
   Sources: arrayPropertyBag("SourceType", this.Sources),
   News: objectPropertyBag(this.News)
 });

 // soap message component
 let soapCall = Cc["@mozilla.org/xmlextras/soap/call;1"]
                  .createInstance(Ci.nsISOAPCall);
 let parameters = [];
 parameters.push(new soapParameter("parameters",
                   parametersBag,
                   this._schema.getTypeByName('SearchRequest')));
 soapCall.encode(Ci.nsISOAPMessage.VERSION_1_2,
                 'SearchRequest',
                 this._schema.targetNamespace,
                 0, null, // header blocks
                 parameters.length, parameters);
 soapCall.transportURI = "http://api.bing.net:80/soap.asmx";
 soapCall.encoding = this._encoding;
 soapCall.asyncInvoke(aSOAPResponseListener);
}

const kSchema = {
 file: 'data/bing20.xsd',
 schemaNamespace: 'http://www.w3.org/2001/XMLSchema',
 targetNamespace: 'http://schemas.microsoft.com/LiveSearch/2008/03/Search'
 }

function BingBase()
{
 if (typeof this._schema == "undefined")
 {
   this._schema = getSchema(kSchema);
   // use the 2001 SOAP encoder
   this._encoding = Cc["@mozilla.org/xmlextras/soap/encoding;1"]
                      .createInstance(Ci.nsISOAPEncoding);
   this._encoding.getAssociatedEncoding("http://www.w3.org/2001/09/soap-encoding", true);
   this._encoding.schemaCollection = this._schema.collection;
 }
}

So far, the complexity of this does not seem unmanageable to me. I’ve only shown the endoding step. Decoding the response consists of a creating a call-specific translator similar to the “BingSearch.prototype.invoke” function above, which relies on the webservices soap library decode method. All of the other functions I’ve created (such as arrayPropertyBag) are not at all specific to the nature of the SOAP interface being used. I am not seeing the need to process the WSDL file automatically and generate proxy functions.

I’m not yet convinced that this resurrection of the old webservices library is the right approach, but I am not seeing any obstacles to using it either. I can generate and decode soap calls fairly efficiently, debug issues that arise, plus I have code that will integrate fairly easily with either javascript or C++ code in a Gecko chrome environment.

Next steps

I’m trying to decide on the next step toward moving this forward. I’m leaning toward attempting a specific EWS application, such as read-only access to an Exchange calendar as a Lightning extension. Another option might be to add some core mailnews hooks to allow me to create either message accounts or addressbooks using an extension – though I’m hoping jcranmer will beat me to it.

February 01, 2010 10:28 PM

January 31, 2010

James Burke

RunJS to RequireJS?

There was a thread that started on the CommonJS list about a transport format, something that works well in the browser via script injection. I sketched out a proposal, Transport/C, that builds on the Transport/B and Transport/A specs.

Transport/C is very similar to some basic mechanics of RunJS but uses require() as the top level function, and supports the special "module" and "exports" free variables used in the normal CommonJS module spec.

In order to prove the concept for Transport/C, I made a branch of the RunJS code, calling it RequireJS, that implements Transport/C.

It seems like it fits with the existing CommonJS module spec, but is something that works well in the browser. I also made a simple conversion script that converts traditional CommonJS modules to this format.

I am tempted to convert from RunJS to this RequireJS branch, and to start evangelizing that approach for browser toolkits. It would be great if Transport/C would also be approved as the transport format for CommonJS too.

Kris Kowal has some concerns about the *very* long-term effects of the approach. I read his comments as possibly pointing out some things that would be done differently if the primordials and e-maker type of modules were ever accepted as part of an ECMAScript standard.

As I read the primordials and e-maker strawman proposals, I think the only difference is Transport/C functions are only expected to be called once, but e-maker style would favor calling the function on every require() call. As I say in my response, I believe e-maker support, would affect regular CommonJS modules in the same way as the transport format, and it is assuming the strawmans make it in to the spec at some point, as they are specified now.

I also believe how it works in how I coded Transport/C as part of the RequireJS branch is what a normal developer would expect, and I think fits better with existing browser/script behavior, and the assumptions that go along with coding CommonJS modules today.

So I am tempted to rename the RunJS project to RequireJS and proceed with that. If you have any feedback to the contrary, please let me know. Otherwise, I will likely do the change early this week.

January 31, 2010 01:29 AM

January 27, 2010

Roland Tanglao

Call for SuMoMo writers

K is for Knowledge - photo by desireedelgado

The Thunderbird 3.0 release is just around the proverbial corner. And we’d like to release the SUMO knowledge base for Mozilla Messaging, support.mozillamessaging.com, code-named “SuMoMo” (initially only Thunderbird of course since Raindrop is still in its early days) at about the same time as Thunderbird 3.0.

SuMoMo is currently in beta preview mode on our staging server and currently has the Firefox look and feel but we are in the process of theming it to look like the rest of the Mozilla Messaging web presence. Theming should complete in a few days.

The last thing to do before release is to add knowledge aka “content”, in English (of course you can contribute English plus other languages but for the first release we’d like to do English as the first priority). This is one of the easiest ways to contribute for people who are not software developers (other than helping out Ludo and the QA team).

No software development experience required! We just need people who are using Thunderbird and can write regardless of whether they are developers or not. SuMoMo is for users not developers. Developers have lots of other places for their documentation e.g. Mozilla Development Center, etc

Interested? Want to help?

Here’s how (don’t worry if you don’t know how to use Bugzilla email roland AT mozillamessaging.com or if you are IRC savvy ping me Monday-Friday 10-5p.m. Pacific on irc.mozilla.org, #maildev, my userid is rolandtanglao and I’ll get you up and running in no time):

  1. Download Thunderbird 3 (SuMoMo will only document Thunderbird 3 and higher) Release Candidate 1 or newer official pre-release build. As Thunderbird 3 is still in release candidate status at the moment, please do a backup and then try it out on a test email account.
  2. Join Bugzilla if you haven’t already
  3. Join SuMoMo if you haven’t already
  4. Pick a Bugzilla Bug from our list of Initial Thunderbird 3 content and assign it yourself so the community knows you are working on it
  5. Edit and create your article (full instructions are on our SuMoMo howto)
  6. Update the bug to let the community know you have finished

January 27, 2010 01:28 PM

January 26, 2010

Thunderbird Localization

Localized Thunderbird 3.1 alpha1 release

One week ago, I told you that we won't be able to release Thunderbird 3.1 alpha1 as a localized release and that the release will be en-US-only. We've reversed course on that issue, since we now have a working l10n dashboard now for TB 3.1 and because the TB 3.1 alpha1 release will be postponed by one week.

Therefore everyone interested in being part of the TB 3.1 alpha1 release should hop over to the mozilla.dev.l10n newsgroup and opt in for this release.

L10n-wise we will be doing this release from the l10n-mozilla-1.9.2 repository. Please do not opt-in to this release, unless

January 26, 2010 10:13 AM

January 22, 2010

Kent James

QA -> Developers communication

A few weeks ago on IRC dmose and I discussed the general issue of how QA communicates priorities to developers. I’d like to hear some comments on that from others, and possibly participate in some sort of trial of improvements.

The issue here is that I see lots of good work going on by people who are mostly involved in QA, such as wsmwk, WADA, and Ludo, but I as a developer don’t really know how to make the best use of that work.

I assume there is supposed to be a waterfall here, from (bug reporter)->(QA)->(developer)->(code reviewer)->(bug landing). I understand all of the steps of the process except this (QA)->(developer) handoff. I would be curious to hear from people involved in QA about what they view the main outcome of their work is supposed to be, as viewed by a developer.

Here’s what my understanding is of the current process. After bugs are submitted, QA has three main responsibilities: 1) get the bug in the correct component, 2) move the status to NEW or one of the inactive states (DUPE, INVALID, etc.) 3) clarify the bug information to get clear steps to reproduce.

Is this accurate?

Let’s look to see how that is working by looking at my recent work. In the last three months, I fixed eight bugs (that’s a little off my desired pace, but we were frozen a lot of that time). What brought those bugs to my attention?

(3) bugs I reported myself, either due to issues I observed or as a result of following support forums.

(3) bugs are fixes of crashes that wsmwk reported from crash stats

(2) bugs were filed earlier by others. If I recall correctly, both of those bugs were items that I noticed first in support forums, then located the bug in Bugzilla and fixed it.

In no cases did the standard QA waterfall process play a significant role in bringing a bug to my attention. And that concerns me, because I see some very competent and dedicated people working hard on QA, but I don’t seem to be making effective use of that work.

Am I somehow not following the process that I am supposed to be following, or is that process flawed? In theory I am probably in a better position than most people here, because I primarily track items that appear in the mailnews core/filters component.

I wish there was a clear way for the QA people to bring a limited number of bugs to my attention that are 1) important, 2) clearly defined and reproducible, and 3) likely to be fairly easy to fix.

The mailnews core/filters category currently has 326 NEW/ASSIGNED/REOPENED bugs in it. I could probably fix a few per month that were brought to my attention. A reasonable expectation might be that 10% of those are addressed in the next year. How are the QA folks supposed to influence the selection of which 32 bugs actually get my attention?

(posted to http://mesquilla.com and m.d.a.thunderbird, followup to m.d.a.thunderbird please.)

rkent

January 22, 2010 06:44 PM

Joshua Cranmer

Developing new account types, part 0: An introduction

This series of blog posts discusses the creation of a new account type implemented in JavaScript. Over the course of these blogs, I use the development of my Web Forums extension to explain the necessary actions in creating new account types. I hope to add a new post once every two weeks (I cannot guarantee it, though).

Before I begin the actual discussion, let me give some background. The ability to develop new account types has been my biggest extension goal for about two years now. Probably because of its difficulty, I know of only two extensions that have tried to do it: what is now the RSS code, and Webmail. In the first case, the implementer resorted to creating a binary component for the incoming server; in the latter, the implementer wrote a fake IMAP (and POP, SMTP) server to proxy the information to the web interface.

Some preliminary points: making a new account type is not a Good First Extension. You will need a fair amount of XPCOM experience, and probably decent experience at delving into implementations of undocumented interfaces. How much XUL and DOM (for stuff like webscraping) you use is up to you. MDC has a guide on building a Thunderbird extension from scratch. It is also probably not a bad idea to get comfortable with manual preference editing.

I am also trying a different form of development in this guide. This is not being done via my more common method of manually editing HTML by hand, but by writing in Kompozer. I'm also attempting to get more code included in my posts, and hopefully some images as well (the last part will be hardest). Like my first guide, I do expect that this will be adapted into a series of documents on MDC at some point. Some more reference-oriented documentation will be posted on MDC as I write this.

I personally use a debug version of Thunderbird, on Linux, very near the tip as the source code as the basis for my extension development (my regular profile is some 370 MB of stuff I don't dare threaten with developmental work). This is the same build I do patch development on, so I will rely on patches in said tree from time to time. One patch in particular is required [1], but otherwise, it should work on 1.9.2 and probably 1.9.1 as well.

This guide is structured to first demonstrate the actual activity components (e.g., displaying messages) and only cover configuration (e.g., the wizard to create a new account) when the more basic stuff has been completed. Therefore, you will need to get comfortable with editing configuration files by hand if you follow these steps exactly.

Backend introduction

So, let's start with an overview of the backend interfaces in mailnews. A list of the interfaces a front-end widget might use to talk to an account is: nsIMsgAccount, nsIMsgDatabase, nsIMsgDBView [2], nsIMsgFolder, nsIMsgDBHdr, nsIMsgIdentity, nsIMsgIncomingServer, nsIMsgMailNewsUrl, nsIMsgMessageService, nsIMsgProtocolInfo, nsIChannel, nsIProtocolHandler, and nsIRDFResource. Many of these would need to be implemented, and a few of them are not in any way small; to implement nsIMsgFolder would require a total of 186 methods, setters, and getters (as of this writing), many of which are not well-documented.

In reality, implementations are not from scratch. Everything tends to boil down into two or five different implementing classes: the server, the service, the folder, the url, and the database (there is also typically a protocol implementation as well). Of these, only the service is implemented from scratch, and it gets the simplest interfaces to implement. When I said "two or five," I am referring to the fact that there are actually two types of accounts. The first type, which only has to implement a server and service, can be called mailbox accounts: all of the messages are downloaded into local folders [3]. The second type implements all of the above, as the messages are generally stored on the server and downloaded on demand (or cached).

Of these two types, the less interesting is the first one. I will therefore generally ignore this account type. If you want to make such an account type, look at the RSS implementation for guidelines. The primary distinction is that mailbox accounts lack their own folder types, and therefore databases and URLs. In such a case, all you need to worry about is delivering the messages.

Following is a description of the major implemented components:

Server
The server represents the source of messages for an account. It also serves as the per-account configuration information for implementers. For example, NNTP stores the maximum connection limit to a server off of this implementation.
Folder
The folder represents a container of messages. Ultimately, the UI interacts more with folders than with servers, at least on a regular basis. This is the most complex interface to deal with, primarily because it can be hard to tell precisely what you need to implement versus what (eventually) calls back on some other message.
Database
The database represents a store of a subset of message information. It generally stores by default what NNTP would call overview information (enough to create a threaded message list), plus some flags like read status, as well as some information that extensions which to preserve.
Service
The service is more of a "how-to" guide for accounts. This is the external endpoint for ultimately copying messages, viewing messages, etc. Note that this is the only service implementation, so the actual server communication code typically happens in a different implementation.
URL
URLs are what the name implies. It's how one refers to messages, folders, and servers, although only messages are typically instantiated with the object in question. They also tend to be used as the primary internal communication system.
Protocol
The protocol instance represents a connection to a server. Unlike the other implementations, this one is not mandatory and is typically not visible via the "main" interfaces (nsIChannel is perhaps the most useful one they export). I suspect this is primarily useful for binary protocols, but I have not yet delved far enough into creating a new account to say for certain.

Important interfaces and their interactions

The center of an account is represented by the nsIMsgAccount. To get an idea for the amount of interfaces involved, look at the collaboration diagrams for nsIMsgAccount and nsIMsgFolder.

nsIMsgAccount represents an account. The interface itself is not terribly useful—it's mostly just a step on the way to get to a server or an identity.

nsIMsgIdentity represents an identity. Identities are essentially a way of persisting compose settings; since their use is wholly related to compose code, I will not discuss them in detail until later parts of the guide.

nsIMsgIncomingServer, as mentioned earlier, represents a message source. This is one of the interfaces you will have to implement, although much of it is already done for you. Everything that is specific to a server hangs off of this interface; everything that is specific to a folder hangs off of nsIMsgFolder; folders are accessible via the root folder of a server.

nsIMsgFolder, as mentioned earlier, represents a container of messages. This is one of the interfaces that has to be implemented, unless you are using a mailbox account. All folders have a database.

nsIMsgDatabase represents the message store overview. This has to be implemented if you are implementing nsIMsgFolder (unless you want to be sneaky). Databases are used to get at thread and header information, via nsIMsgThread and nsIMsgDBHdr, respectively. Messages themselves have numerous representations: URIs, header objects, message keys, and (sometimes) message IDs. Conversion between these forms is common.

nsIDBFolderInfo represents folder properties normally stored in the database. All of these properties are also stored in the folder cache (nsIMsgFolderCache) to avoid opening up all of the databases just to figure out how many unread messages are in each folder.

nsIMsgAccountManager and nsIMsgBiffManager are two managers that handle account creation and the periodic mail download (generally called biff), respectively. Expect to see these calling your code a lot.

nsIMsgDBView represents the thread pane view. This is going to be the primary consumer of nsIMsgDatabase, and this is where you should go to look to find out what happens if, e.g., you select a new message.

nsIMsgFilterList, nsIMsgFilterPlugin, nsIMsgFilterService, and nsIMsgFilter are the interfaces that deal with filtering. None of these will have to be implemented to support filtering [4].

The nsIMsgSearch* interfaces are those that deal with search (there are around 9 of them). Most of these will not have to be implemented to support searching. More on this when searching is discussed.

nsIMsgWindow represents the bridge to the front-end. It is passed into many functions, although it may be null, typically when being invoked from the backend.

nsIMsgMailNewsUrl represents the URL object that loads a message. This will generally have to be implemented if nsIMsgFolder is.

nsIMsgProtocolInfo represents the basic information about an account type's capabilities. This interface is one that is required to be implemented. As the name implies, it is generally geared towards the capabilities of the connection to the server.

nsIMsgMessageService and nsIMsgMessageFetchPartService represent the ability to retrieve the message (and message parts, more often known as attachments [5]). This is another interface that one must implement if folders are being implemented.

The MIME, compose, and import interfaces are omitted from this list of backend interfaces, as these are topics that will not be discussed for a while, and I am not certain they are useful to know about making new account types at present.

Notes

  1. The purpose behind this patch is to enable extensions to reuse files from base/utils like C++ components can. If you were to adapt this to use C++ instead of JS, this patch would not be necessary. As the comments in the linked bug indicate, there is no guarantee that this will be implemented for Thunderbird 3.1; however, in such a scenario, the specifically required binary components would be available for reuse on some webpage. More on this when a decision is made.
  2. Strictly speaking, this interface uses other interfaces in the list to talk to you. That said, a lot of interaction with folders and databases happens through this interface.
  3. I say local folders—not Local Folders—here because Global Inbox settings actually rely on POP-specific attributes. It is still possible, via a reimplementation, to change the delivery settings. Such a mechanism is outside the scope of this guide.
  4. It's not strictly necessary to implement these, but if you want to add custom filter terms or actions or custom search terms, some interfaces will need to be implemented. Such actions are beyond the scope of this guide.
  5. Classifying all message parts as attachments is a pretty big oversimplification. In general, the only time specific parts are requested in Thunderbird and SeaMonkey are when attachments are involved. For more information on message parts, please see RFC 2045, RFC 2046 (two of the five MIME specifications), as well as the IMAP FETCH subsection (for numbering).

January 22, 2010 05:06 PM

January 21, 2010

James Burke

Script async, Raindrop and Firefox 3.6

In honor of the Firefox 3.6 release, I upgraded Raindrop to use the new async attribute for script tags.

Why is async neat? It does not block the rest of the page, and will just evaluate the script once it is retrieved. More information is in the HTML5 spec. Note that the script you add async to should NOT use document.write(), as doc.write will likely destroy your page.

Also, be aware that async is a boolean attribute, but that does not mean you should use async="true" to turn it on. The HTML5 spec on boolean attributes says that a value of empty string or a string that matches the attribute name should only be used. To avoid async, just do not include the attribute. For Raindrop, I used async="async" since that looks better to me than an empty string.

Raindrop uses RunJS for the module loader, and RunJS uses dynamically added script tags via head.appendChild(), so the modules loaded by RunJS already behave in an async manner.

However apps that want to use the raindrop front end libraries normally include a script called rdconfig.js as their own script file, and that config file does a document.write to write out the Dojo+RunJS and jQuery tags. Those Dojo+RunJS and jQuery tags now use the async attribute.

January 21, 2010 07:43 PM

January 20, 2010

Ludovic Hirlimann

Thunderbird Quality Weekly Event

The people in charge of the quality of Thunderbird , are organizing on a weekly basis a quality team event. These event cover most of the area where quality is involved. This means testing new feature, testing pre-release version of the software, and maintaining the known bug database. If you come to think about it, none of these activities require to be done on a given date, so why bother with an "event" ?

First of All the event is virtual, it happens online - this is for practical reasons, it would be very difficult to have people living in Singapore, the US east coast or The Netherlands to meet and work in the same physical place. We do bother to have an event because sometimes when looking at a problem or at something new being able to ask other if they see the same thing is valuable, because they might know something you don't or might have encountered the same issue earlier etc ... The value of the event is communicating with other people doing the same thing as you do, but with a different perspective. This is specially true for people who want to join. Asking the people that have been doing quality for quite some time will be available to help new comers.

We are using a distributed chat system called IRC, which is available with dedicated clients or through a web interface. As all the people available for a chat are not always in front of the chat window, you might not get an immediate answer. Typing a name a person being in the chat room will help you get noticed and get a faster answer. And don't be afraid to ask or participate , it's not that difficult.

Now that you know how those events take place, you might be interested in figuring out the subject that is going to be going on during the event. We publish a wiki page for each event that take place, and we have an other page referencing all past and future events (well most of the future events are being announced on a weekly basis). This week for example will be focused on duplicate events. I'm also announcing the events on Thunderbird dev mailing list.

January 20, 2010 09:00 AM

January 19, 2010

Raindrop Design

Raindrop design status

announcementposter

Hey everyone - Sorry for the major delay since the last update. In this blog post I’m going to try and summarize what’s been happening here at Raindrop for the past month, and consolidate all of its Flickr activity into one post. I’ll be talking about what’s currently live, what we’re still iterating on, and what we still need to think about. I’ll also talk about our near future plans for a hosted version (so you can easily get your hands on it), and included at the end is a short screencast of our current interactions. Ok go!

metrics
So starting from the beginning of the user experience - the user is first brought to this prompt which informs you of your participation in gathering metrics data. The metrics data is a way for raindrop users to share anonymous information about their email and twitter habits with the raindrop designers who study the information to improve future versions. Once the user closes this prompt they are brought to their inflow of messages which will look something like this.

screen-shot-2010-01-18-at-123808-pm
The inflow displays a combination of direct and group emails sent to you, as well as twitter @mentions from people you follow. As seen in the above screenshot we are now able to pull out youtube links and thumbnail them for you. Thanks to Bryan Clark this also applies so far for vimeo and flickr links, as well as expanding bit.ly links. We have plans for link expansion and thumbnailing for many more services to come. Below the first twitter message you can see a message with several email attachments. We now also provide thumbnailing for image attachments, and allow the user to scroll through them all within the preview box. Eventually we would like to be able to open several image attachments into a lightbox style gallery.

rmqj9
The above screenshot shows an example of a youtube video being expanded inline.

screen-shot-2010-01-18-at-125937-pm
Message in personal inflow about to be moved to bulk

screen-shot-2010-01-18-at-10518-pm
Message now moved to bulk

Another feature we had previously blogged about was the ability to move messages from your inflow to your bulk section. Ideally Raindrop would automatically know how to deal with every one of your messages, but this feature was definitely necessary at this stage. This feature has since been implemented, and as you can see from the above two screenshots the message is moved from personal to bulk.

rrraa
Adding a contact

Something we started iterating upon was the steps one would take to add a new contact. Gmail currently has a contact manager which is, in our opinion, under utilized and not very well advertised. We would like Raindrop to allow you to have a very well sorted contact list, and encourage the user to assist in the process of organization without being overly intrusive. One iteration of this (shown above), would be to pull out a Raindrop Notification which alerts you when you have a pending contact when you receive a personal email from a new sender, and encourages the user to act upon this. The user would then be able to add the contact, or act on a suggestion such as merging the new contact with an existing contact (such as an email from someone who you already have on twitter). This way the user acts on the organization of contacts right away, much like one would accept a facebook friend request. This is likely to generate better organization than gmails system which hides the merge contact panel.

This series of events is still in the process stages. There is a discussion on the flickr group as to whether or not this is the right solution, and if it offers the user enough incentive for it to not simply be an annoyance. Another suggestion was to have the pending contact prompt within the message itself.

vppek
Clearing bulk

One idea I had and never really discussed much was a method for handling your bulk messages. Here I’ve mocked up a system which would allow you to mark bulk items as read without having to navigate to it’s full view which might be useful for messages that are short or that you get the gist of right away. There is then a method of clearing read bulk messages. The current iteration of Raindrop simply clears out your bulk messages when you navigate to their full view. Some thoughts on how people would like to handle their bulk mail would be interesting.


A stacked conversation

The last thing we started mocking up was conversation stacking similar to that of Gmail, except with the use of avatars for instant recognition. As of right now we don’t provide avatars for email messages, however with the use combining email and twitter contacts, gravatars, and facebook we feel we will slowly be able to almost guarantee an avatar image for all users.

The Next Steps

ubiquity screenshot

raindrop showing the find box Navigation

Inspired by the work of the Mozilla Labs Ubqiuity team search interface.  We have been iterating on a similar system for searching and browsing your conversations inside Raindrop.  A simple, single point where you can search with auto-complete helpers and browse for conversations and people within your Raindrop.  Right now we’re working collecting the data and getting it to fit into our own Raindrop style.

And then finally around spring time we’ll be looking into a hosted alpha version of Raindrop.  Just like all our other designs we’ll start small and invite as many people as we can into the process.  As we iterate and expand the invite system we hope more people can join us so we can integrate the feedback and work towards a better system together.  If you’d like to keep tabs on this you’ll want to check in with the Raindrop Milestone Planning wiki page

Lastly here’s a screencast demonstrating the currently live features of Raindrop.


View on Vimeo.
-Andy Chung

January 19, 2010 04:40 PM

January 15, 2010

Rafael Ebron

Lanikai beach

Just a quick note to get back into the blogging groove (been somewhat preoccupied microblogging on Facebook and to an extent Twitter).

The next version of Thunderbird has the project name Lanikai which made me super happy because it’s one of my favorite beaches of all time. Some photos.

Lanikai beach is on the East side of Oahu, in Lanikai and near Kailua (which is where the Obamas like to stay when they visit Hawaii).  You can walk up to Kailua beach for more action where there’s windsurfing, kite surfing, and kayak rentals.  What’s interesting is that they’re not crowded at all, probably because the towns of Kailua and Lanikai are a bit far from Honolulu and they’re small sleepy towns, more local than tourist area.

The water is very clear, warm, and it’s a very swimmable beach.  The sand is white to light tan and soft.  The beaches are easy to access, and stores are near enough for some coffee, snow cones, or sun block.

I like to think that part of the reason we’re going with Lanikai and beach themes is that it’s aligned to how we’re thinking about the Thunderbird email client.  We want to make Thunderbird run so efficiently that people spend more time on the beach than in their email.  Sounds good to me.

A couple more links for Thunderbird 3.1/Lanikai:

January 15, 2010 06:24 PM

January 11, 2010

SeaMonkey

SeaMonkey 2.0.2 Update

As part of Mozilla's ongoing stability and security update process, SeaMonkey 2.0.2 is now available for Windows, Mac, and Linux as a free download from www.seamonkey-project.org.

We strongly recommend that all SeaMonkey and old suite users upgrade to this latest release. If you already have SeaMonkey 2.0, you will receive an automated update notification within 24 to 48 hours. This update can also be applied manually by selecting "Check for Updates..." from the Help menu.

For a list of changes and more information, please review the SeaMonkey 2.0.2 Release Notes.

Note: All SeaMonkey 1.x and old Mozilla or Netscape suite users are encouraged to upgrade to SeaMonkey 2.0.x by downloading it from www.seamonkey-project.org.

January 11, 2010 07:08 PM

January 04, 2010

Joshua Cranmer

Building packages: harder than they look

For a course I'm TAing, we (the other TAs and I) decided to revamp the tools so that students could more easily install them on their own computers. This was really my first look into actually producing packages for other people. Here is the long tale:

Step 1: Build simpl

Okay, the basic, core tools here compile and work easily. The more complicated tale is the GUI, built on qt. qt 3, to be precise. Except the autodiscovery thinks we want to try building qt 4. A single post-configure change gets this working. Only took a few hours here (trying to go the qt4 route didn't work so well, and we had interesting endeavors trying to figure out how to get KDE headers to work).

Step 2: Build binutils

This wasn't all that hard at first. Configure ran nicely and without problems, and building... oops, there's a warning and someone turned on -Werror. Another reconfigure gets this building quickly.

Step 3: Build (cross-compiling) gcc

Configure... build... fail... reconfigure... rebuild... fail... Repeat for several hours. Make that days. Do I want these options? Or those options? Still failing. Try editing files mid-build, so if that gets it to work. And, no. Okay, let's try binutils again. Solution: make install binutils first, then build gcc. That works without problems.

Step 3.5: Test the build

I have a Makefile that just requires me to change a few lines to swap gcc versions and directories of everything. Do that, try it, and... it doesn't work. Something about libc not working correctly.

Step 4: Build newlib

By this point, I know the drill: copy the configure from elsewhere, configure, and build. Apparently there's a typo in one of the ARM assembly files. I teach myself a tiny bit more of ARM (this is turning out to be very educational!) and fix the file. Reconfigure, rebuild, install, and test again. This time, it's complaining about missing a few functions. I found some more documentation online, and wrote my own sbrk function (where "wrote" means copied from some file online and tweaked to make it build). Testing fails again, so I make myself a few more functions and everybody's happy.

Step 5: Build vba

As you might imagine, this one didn't work either. So many build errors. I look at what Debian did, so I ponder some more, talk it over with the other TAs, and give up. Skritch, skritch.

Step 5: Build vbam

This fork builds... oh, wait, I need cmake. Okay, this fork builds without problem. They don't have version package downloads for my build script to pull, so I just have it yank a specific svn revision. Nice, simple package to work with after the mess that is cross-compiling.

Step 6: Build gdb

No problems here. Worked fine the first time, no patching, no need to rebuild. Even the testing had no problems. Stunned me.

Step 7: Package and test on school computer

Problems:
  1. Can't find libmpfr.so
  2. cc1: /lib/libc.so.6: version `GLIBC_2.7' not found
  3. as: /lib/libc.so.6: version `GLIBC_2.7' not found
  4. (vbam) Segmentation fault
Solutions:
  1. Statically compile libmpfr.so. Not too hard...
  2. Statically link gcc. Not very trivial. Eventually, LDFLAGS=-static in the configure arguments works.
  3. Statically link as (and other binutils). This requires manually copying the final line and adding in the -static argument. Every time I rebuild binutils.
  4. Debug, find backtrace. It's in pthreads, called from SDL. Try statically linking SDL (no luck). Try using different SDL versions. Rebuild vbam with debug. Notice that the primary reason for fault is... no sound device. Patch vbam. Test again, it works!

For the sake of clarity, every time I had to test in the final step, I had to reupload the tarball, which started out at 49 MB and grew to 55 MB (thanks to static compilation). Sometimes I had to reupload it again, if the connection died in the middle (my internet connection started getting flaky... possibly related to the 100s of MB I was uploading a day. Or maybe the 100s of MB I was downloading (every time I restarted the script, it downloaded 100 MB of source archives....).

So, in short, I had to override build scripts for 2 different packages, patch another 2, and build 3 out of 5 packages statically. One package doesn't have a point release; the other three are spread out among three separate servers to download. Running the build script from scratch requires nearly 2GB of disk space and takes several hours. At least now I repackaged it in Makefile form so you don't have to restart all over from square one if you forgot to install cmake first. Building the final tarball requires a good minute on my system.

But, I've finally finished the experience. Plus, I won't have to do it again... after I build the 64-bit version.

January 04, 2010 09:28 PM

Mark Banner

Thunderbird - Lanikai/Thunderbird 3.1 nightly builds now set up

Lanikai/Thunderbird 3.1

As mentioned in David’s blog post, we’re using Lanikai as the code name for the Thunderbird 3.1 branch.

Last week we transitioned our Thunderbird 3.1 nightly builds to be building with Gecko 1.9.2 and to have the Lanikai code name. We’re still missing some new images for the branding, but hopefully they will come soon.

If you want to help with testing these builds, then the nightly builds can now be found in the latest-comm-1.9.2 (or latest-comm-1.9.2-l10n for localised builds) directory on ftp.

Thunderbird Trunk

In tandem with the setting up of Lanikai builds, we’ve also set up new trunk builds with Gecko 1.9.3. These builds currently have the version number “3.2a1pre” - this does not mean that the release after Thunderbird 3.1 will be called Thunderbird 3.2, it is just the lowest increase that we need to implement at this stage to be something different from 3.1.

Trunk builds are retaining the Shredder branding but will hopefully get new images at some stage.

At the moment, these builds are pretty much the same as the Lanikai builds from the Thunderbird perspective. It is only the core files that are different.

The nightly builds can be found in the latest-comm-central-trunk (or latest-comm-central-l10n) directory on ftp.

Thunderbird 3.0.x

There’s no changes on the stable builds for Thunderbird 3.0.x - just mentioning for completeness. The nightly builds are still in the latest-comm-1.9.1 (or latest-comm-1.9.1-l10n) directory on ftp.

For Developers / Other interested parties

The Lanikai and Thunderbird 3.2 builds are both generated using the comm-central repository (this has not been branched yet).

Thunderbird 3.2 builds are using the core mozilla-central repository.

Lanikai builds are using the mozilla-1.9.2 repository (specify --mozilla-repo=http://hg.mozilla.org/releases/mozilla-1.9.2/ to client.py to pull that repository).

The branch date for comm-central into comm-1.9.2 has not yet been agreed, iirc it is likely to happen around about the first Lanikai preview build, more on that later.

Tinderbox pages can be found as follows:

January 04, 2010 10:21 AM

January 02, 2010

Joshua Cranmer

Predicted work on Thunderbird

It's a new year, so it's time for me to predict (and probably overestimate, who knows) what I would like to do and see in the realm of Thunderbird (and SeaMonkey) and other tidbits in the Mozilla realm.

News submodule

Thunderbird 3 improved the filter story dramatically here; the next two biggest itches are the complete inanity that is news URIs (too many bugs to count), and the venerable old crossposts bug. I still contend that the latter would best be served by per-account database functionality; in any case, it does require some database changes to work properly. I doubt I'll find time to look at that bug in particular this year.

The URI issues are more tractable, but I don't think I'll find time to hit them for 3.1; in any case, I now consider them to be the highest priority news bugs. So, to anyone with time on their hands: feel free to take one or two of these and start fixing. You'll get much kudos from Thunderbird Usenet users.

Other various "nice-to-haves" on my list: fixing subscribe, cleaning up some of the gunk in the code, adding support for RFC 3977 CAPABILITIES, possibly changing how news:a.group URIs work (open the folder view, not necessarily subscribing to them), among others. Combine-and-decode also falls under this list, but it's a lot less tractable than some of the other stuff.

Analysis tools

jshydra could use some more love: I hope to be able to be able to get a converter to a more natural AST working by the end of the year, as well as an automated test suite to verify correctness whenever I change m-c versions. I've also been working on-and-off on getting symbols for DXR via MSVC, which should hopefully also be finished this year.

Other Mozilla/Mailnews work

As I've mentioned before, my biggest goal for 3.1 is to be able to specify new account types in Javascript. I basically have the necessary framework completed locally, I just need to finish writing the tests and fix some bugs before getting it reviewed and committed; after that, I'll be writing a series of blog entries on developing an account type in JS, similar to (and hopefully better than) my pork guides. Speaking of which, I hope to finish that sometime this year as well. Possibly during summer again.

I've yet to see a roadmap for the address book in 3.1 and later, so I don't know what I'll be doing for the address book in this upcoming year. I expect, though, that I won't do anything near the scale of what I did for bug 413260. De-RDF and de-morkification are another two things I'd like to see worked on that I don't expect to get to this next year as well.

Time to see how much I'll actually get done this year!

January 02, 2010 07:46 PM

December 23, 2009

David Ascher

Looking for an awesome test engineer

I don’t yet have a full job description handy, but figured I could start with a draft:

Mozilla Messaging is looking someone who can help us drive forward Thunderbird’s test automation framework, tooling, coverage, and community. We’re looking for someone who combines the usual skills we need:

Our current test infrastructure relies primarily on MozMill, and most tests are written in Python or JavaScript, so solid understanding of those technologies is obviously useful.

This is a unique opportunity for someone who takes testing, engineering, and community seriously, and who wants to have a huge impact on software that is used daily by millions of people.

Relocation not necessary.

Pass the word!

(resume submissions to jobs at mozillamessaging.com)

December 23, 2009 12:29 AM

December 18, 2009

Roland Tanglao

Call for volunteers for Thunderbird Community Support

We Can Do It! - photo by Matthew Shelley
Since Thunderbird 3.0 shipped last week, our community support traffic has increased dramatically. We have roughly three times the number of support topics as well as 15 times the amount of traffic. Needless to say we need help!

Do you use Thunderbird? Always wanted to contribute to a open source project but don’t know how? But you love explaining things and helping others? Then helping our community support  Thunderbird is a great way to start.

You don’t have to be a coder or be “technical”. Just somebody uses Thunderbird and wants to help other Thunderbird users.

Here’s how to start:

  1. Join Get Satisfaction (you can use your Facebook, Google, Twitter or Open ID login if you don’t want to create another login)
  2. Read our Get Satisfaction README which succinctly explains how to use it.
  3. Download and start using Thunderbird 3.0 if you aren’t already a Thunderbird 3.0 user (NB: if you are a Thunderbird 2.0 user and depend on  add-ons like Lightning, we recommend holding off on upgrading to 3.0 until those add-ons are available for 3.0. And of course it’s always worthwhile doing a backup)
  4. Use the dashboard at http://getsatisfaction.com/mozilla_messaging/ to figure out where you can help
  5. Get in where you fit in :-) i.e. help where you can by replying to support topics, and by tagging,

Questions? Need help on using Get Satisfaction and providing Thunderbird community support? Email me: roland AT mozillamessaging.com or ask myself (I am generally on there M-F 10am.-5p.m Pacific) and the other folks on the IRC chat channel  #gsfn on irc.mozilla.org

December 18, 2009 05:48 AM

December 16, 2009

SeaMonkey

SeaMonkey 2.0.1 Security Update

As part of Mozilla's ongoing stability and security update process, SeaMonkey 2.0.1 is now available for Windows, Mac, and Linux as a free download from www.seamonkey-project.org.

We strongly recommend that all SeaMonkey and old suite users upgrade to this latest release. If you already have SeaMonkey 2.0, you will receive an automated update notification within 24 to 48 hours. This update can also be applied manually by selecting "Check for Updates..." from the Help menu.

For a list of changes and more information, please review the SeaMonkey 2.0.1 Release Notes.

Note: All SeaMonkey 1.x and old Mozilla or Netscape suite users are encouraged to upgrade to SeaMonkey 2.0.x by downloading it from www.seamonkey-project.org.

December 16, 2009 03:06 AM

December 15, 2009

Jennifer Zickerman

MDC Version Tags and Templates

Now that we are living in a Thunderbird 3.0 world, there will be times when we will want to indicate that content on the Mozilla Developer Center applies to a specific Thunderbird release version. (We’ve already been doing this to some degree with Thunderbird 3, but over the next year we will have many more release versions to manage.)

There are two mechanisms for labeling content on the Mozilla Developer Center: tags and templates.

Tags

At the bottom of each MDC page there is a section called “Tags”. These are folksonomy tags that apply to an entire page (for example, “Thunderbird” or “Thunderbird 3″). These are not pre-defined, so you can add a new tag (such as “Thunderbird 3.2″) as needed. However, please check the list of tags that is displayed as you enter letters in the “Tags” field, and try to avoid duplicating existing tags.

The main benefit of tags is that you can list all the pages that have a particular tag  by clicking the hyperlinked tag word. Therefore, don’t be afraid of adding lots of tags, and don’t be afraid of making tags too specific.

Templates

There are four MDC templates that are used to indicate that page (or a section on a page) applies to a specific version:

So, for example, if you were to paste (as text paste_text1) the following into the MDC editor:

{{template.Tb_minversion_header(3.2)}}
{{template.Tb_minversion_section(3.2)}}
{{template.tb_minversion_inline(3.2)}}
{{template.Tb_minversion_note(3.2, "The <code>foobar()</code> method works differently in Thunderbird 3.2.")}}

…you would see this after saving the page:

template_result1

Another useful template is {{template.draft(”")}}. This generates:

draft

See the Template page on MDC for a complete list of MDC templates.

December 15, 2009 08:57 PM

David Ascher

A public internet deserves great beaches

Firefox releases have cool codenames while in gestation. As Chelsea explains, Firefox picks national parks as codenames, as metaphors for the values that go into making a Firefox release.

The idea made a lot of sense to us, so we decided to follow suit for Thunderbird. Rather than parks, we picked beaches. A good beach is a clear and compelling example of a public good. We can all go to the beach, share in the beauty and poetry of the place, swim, maybe surf. All that’s required of us in exchange is to treat it well — don’t fence it in, don’t litter, don’t crash your oil tankers into it. Yet beaches as a public commons are under threat. If Thunderbird can help beaches and beaches can help make it clear why Thunderbird matters, we all win.

Given the weather outside, it’s not too surprising that the codename for the next version of Thunderbird is Lanakai, in sunny Hawaii. “Warm turquoise green waters brush up against a fine sand beach while gentle trade winds offer a cool relief from the hot Hawaiian days. This beach is great for relaxing on the sand or taking a swim in it’s clear waters”. That pretty much sold us. Also, we can dream about having a Thunderbird summit there someday.

December 15, 2009 06:49 PM

Raindrop Design

Navigation and organization

So it has been a little while since the last update but we have been busy putting together some plans for the very near future. Hit the jump to check out some new mockups as well as an update on the current status of Raindrop.

nav
Since the last iteration we’ve thought up a way in which users will navigate through Raindrop. The primary means of navigation will be through a search bar, coupled with a drop down menu. When the user clicks within the search field a drop down menu will appear giving the users the ability to navigate to where they want to go through quick links (such as to quickly navigate to the inflow, mailing lists, tweets, etc). These quick links also act as filters, as when the user types in a search query the quick links will filter down to only those which are relevant. For example if you were to search for Raindrop, the quick links might only show RSS feeds and Mailing lists, and within those links display your results - for example a Raindrop Get Satisfaction RSS feed, and a Raindrop development mailing list. This search system is highly inspired by the Mozilla Labs product, Ubiquity.

move
The next thing we started thinking about was a system in which we could move messages from your personal inflow to your bulk mail. In this mockup the user has clicked “not personal” and is creating a filter. The user has a choice to filter all future messages from that sender, or to simply put that specific conversation and it’s subsequent replies in the bulk.

contact
We’ve also started mocking up different uses for the summary area (the gray area in the right hand column). We think this is a very useful space for showing the user content relevant to what they are looking at. For example we can now search for a contact, in this case Harrison Boyce, and it will display all their activity on the left hand side, and contact information on the right hand side. This is an example of what a twitter contact page could be like. Ideally when we merge contacts, the contact info would show more than just twitter info, and we would show email activity as well as twitter activity. Also note in this screen shot that we show conversation threading when viewing tweets. This is currently a live feature in Raindrop.

quickcompose
Another necessary feature for the twitter view is the quick compose. This screenshot is pretty self explanatory.

screen-shot-2009-12-15-at-114210-am
Finally we have this screenshot which is a live representation of where Raindrop is currently. Most of what was shown in this blog post is currently in place, however we are still working on getting the interactions to all work properly.

-Andy

December 15, 2009 06:24 PM

Jennifer Zickerman

Doc Day - December 17

Please help out with our first Doc Day, this Thursday December 17. By expanding the developer documentation available to the community, you help people become involved with Thunderbird.

You can contribute a how-to, describe a new 3.0 feature or module or provide some content to the Thunderbird Overview page. For more information see my previous post  “RC 1 - Good Time for Docs“.

Feel free to write in whatever environment works best for you. If you want to write directly on MDC - great, go for it. If you prefer to brain-dump to a text file - that’s fine too. Just email it to me (jen at mozillamessaging.com) and I’ll edit and publish it.

Don’t have the time or inclination to write a full piece? No problem - send me an outline or a partial draft. These are helpful too - other people can come along and continue your work later.

Thanks in advance to everyone who helps out! If you need help or have questions, contact me at jen at mozillamessaging.com or “jenzed” on the Mozilla maildev IRC channel.

December 15, 2009 05:32 PM

December 12, 2009

Instantbird

Translations

We have been contacted by lots of individuals who volunteered to translate Instantbird into their native language and were eager to start working on it. As we were not ready to host the translations, we asked people to wait before starting their work on localized versions of Instantbird.

As we plan to release the next beta of Instantbird 0.2 in several languages, we feel that now is a good time to start translating the UI of Instantbird. Please note that the development work is not finished yet, and that there will still be string changes before we are ready to release this next milestone.

You will find information on the translation process on our wiki at http://wiki.instantbird.org/Instantbird:Translation. As usual, if you have any question, feel free to ask them in #instantbird on irc.mozilla.org or to contact us at contact AT instantbird DOT org.

December 12, 2009 09:07 PM

December 09, 2009

Joshua Cranmer

Google Wave in Thunderbird 3

While it's not in the format I would ideally want, I recently got Google Wave inside Thunderbird 3. How, you might ask. Simple: the new content tabs feature.

So, to do it, go into the Error Console, and type this line in: Components.classes['@mozilla.org/appshell/window-mediator;1'].getService(Components.interfaces.nsIWindowMediator).getMostRecentWindow("mail:3pane").document.getElementById("tabmail").openTab("contentTab", {contentPage: "https://wave.google.com/wave/?nouacheck"});. Note that Google Wave for some idiotic reason decides that Thunderbird isn't a valid UA to be using, so you have to convince it to disable the UA with the ?nouacheck. I thought browser sniffing died out years ago...

For bonus points, if you restart Thunderbird, the tab will stay open, so all you need to do is login again!

December 09, 2009 06:57 PM

Instantbird

Instantbird 0.2 beta 1 released!

We are happy to announce the release of Instantbird 0.2 beta 1. The two most significant improvements in this release are new tabs in conversation windows and the preferences window. There's a lot more new stuff, read the release notes for a more detailed list.

You can download the beta and read the release notes from here.

December 09, 2009 04:30 PM

December 04, 2009

Raindrop Design

A personal message

screen-shot-2009-11-19-at-110115-am

This is a quick demo of the way in which we would preview a new message that has arrived in the inflow. This is showing an example which has a lot of information - several replies in a group message with many links and attachments. This demo shows the way in which we will allow you to preview and navigate through links and attachments (try the prev/next links), as well as how we could expand content (click the read more link) within the inflow itself (ideally this would transition or animate from a preview to full message, not just an open/close state).

Also, please excuse my poorly pieced together html for this demo, it’s just hacked together and is no indication of the actual code! Check out the DEMO HERE.

December 04, 2009 08:25 PM

December 02, 2009

Rafael Ebron

Thunderbird 3 Release Candidate 2 – now available

We just released Thunderbird 3 Release Candidate 2.  Check out the post at SpreadThunderbird for details.

December 02, 2009 07:09 AM

December 01, 2009

Mark Banner

Using the Add-on Compatibility Reporter for really incompatible add-ons

Whilst tracking the Thunderbird 3 release and looking through the bugs, every now and again we get a bug where something isn’t working and it turns out that it is due to one of the add-ons the bug reporter is using (unfortunately, in the cases I’ve seen recently I suspect it is because we’ve been forcing the extension author to decide on a single compatibility range for their add-on which means supporting the current branch and trunk, or just the current branch).

When we’ve been getting these reports, rather asking the bug reporter to report back to the add-on author, I’ve been spending an extra 5 minutes using the add-on compatibility reporter to pass a report back to addons.mozilla.org that will then make it back to the extension author. Although this takes me a bit longer, it isn’t as long as going to amo and looking for a web site or email address. It also means the add-on author will get back a good report (with versions and other information) and hopefully will subsequently fix the extension.

I like this way of reporting issues, the only thing I would like is a preference in the add-on compatibility reporter to allow me to decide if I want compatibility checking enabled or not - but that is more because I’m using it in a slightly different way (more towards bug reporting) than it was originally intended.

Even so, the original intention is good, and I like the way the reporter works and the ideas behind it.

December 01, 2009 01:25 PM

November 30, 2009

David Ascher

Business and open source…

Ashlee Vance wrote a story in today’s nytimes.com (I presume it’s in the print edition too ;-) about the business world’s supposed disappointment in the shareholder value of open source based businesses.

I suppose if you ignore all of the companies listed in the article who were sold for hundreds of millions of dollars, and you squint really hard, you can see their point: investors in open source companies in aggregate haven’t made as much money as investors in proprietary software companies. Given how short the age of open source has been, that’s hardly surprising. (Given how open source is missing the boat on services-based businesses, that’s also likely to continue, but that’s another story).

Others will I’m sure criticize the article based on proposing some better metrics for success for investors in open source companies. I don’t really care — what did strike me was this sentence:

The fight illuminates a larger truth about open-source companies: their societal and strategic importance far exceeds their financial value as operating businesses.

Exactly! It’s critical to me as CEO of Mozilla Messaging that it be a healthy business. But my requirements for “health” aren’t those of wall street. They include reaching a state of making more money than we need to operate, but they also include some variation on the triple bottom line, with some additional twists related to making sure that we operate in ways that are consistent with our values.

I was recently at a business meeting where a bunch of CEOs were “networking”. It was fascinating how quickly the conversation shifted when I answered the usual question about “exit” (the polite term for: “get rich by selling the company) with “well, no, I can’t, as we’re owned by a non-profit”. After a period of shock, it turns out that even CEOs (!) are interested in a business that isn’t all about financial rewards for shareholders. It can be about much more interesting pursuits, such as building a team of people who respect each other and work together for a common goal; it can be about providing awesome customer experiences; it can be about making the world better. There are lots of companies like that. It’d be nice if the “business” section of the newspaper spent more time thinking about that and less about how people who are merely shareholders can make money through speculation.

It’s probably healthy for Wall Street to realize that what’s interesting about open source isn’t some magically cheaper way to produce goods and services. To me, what’s much more important are the complex implications like transparency, a permeable barrier between your consumers and your staff, a built-in safeguard against complacency, and ideally a much more human relationship between your organization and everyone else. I look forward to seeing what the Economist’s new Schumpeter column on business says about it, whenever they get around to it.

In the meantime, I’m looking forward to exploring how to work with business-savvy types who are interested in how to make a deeply healthy business. Based on talking to other CEOs of open source companies, I’m pretty sure that just like we can find talented programmers, quality nuts and localizers to contribute to the products, I’ll find some smart business types who will find it rewarding to contribute to the business challenges.

November 30, 2009 07:49 PM

Feeds: Atom, RSS 2.0, RSS 1.0
Subscription list: FOAF, OPML

Last update: March 15, 2010 09:30 PM
All times are UTC.

Subscriptions