Blog-O! (Posts about thunderbird)

A long time ago, on a computer far far away…

Blake Winton — Fri, 27 Feb 2015 19:04:00 GMT

Six years ago, I started contributing to Mozilla.

Building Thunderbird on OS X Lion (10.7) and XCode 4.2

Blake Winton — Tue, 06 Mar 2012 15:34:10 GMT

A few people recently asked me about building Thunderbird on the latest version of Mac OS X. Since I have it working, and to give myself a place to point to the next time they ask, I figured it would be a good idea to blog about it.

So, here’s my .mozconfig.

# Debug .mozconfig
mk_add_options MOZ_MAKE_FLAGS=-j4
mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/../objdir-`basename \`pwd\``-`hg branch`
# mk_add_options AUTOCONF=autoconf213
ac_add_options --enable-application=mail
ac_add_options --enable-extensions=default,inspector
ac_add_options --enable-inspector-apis

# Compilation options
ac_add_options --disable-optimize
ac_add_options --enable-debug
ac_add_options --enable-tests
ac_add_options --disable-jemalloc
#ac_add_options --enable-trace-malloc
ac_add_options --enable-chrome-format=symlink

ac_add_options --with-macos-sdk=/Developer/SDKs/MacOSX10.7.sdk
ac_add_options --enable-macos-target=10.7

# For NSS symbols
export MOZ_DEBUG_SYMBOLS=1
#ac_add_options --enable-debug-symbols="-gdwarf-2"

#Use ccache
#ac_add_options --with-ccache=/usr/local/bin/ccache

# We don't have GCC anymore, since XCode 4.2, so use clang instead.
CC=clang
CXX=clang++

There are probably a bunch of things I don’t really need in there, so if anyone wants to take it, and cut it down to the minimal set, I would definitely appreciate it. But in the meantime, this works for me, and will probably work for you, too.

Thunderbird’s UI Directions.

Blake Winton — Tue, 27 Sep 2011 15:02:38 GMT

On a previous post in a different blog, some commenters were asking us if we were considering doing things that we have planned to do for a while now, and that led me to realize that I haven’t been communicating the future of Thunderbird’s UI nearly well enough. I mainly blame it on my trying to do too many other things, and thus failing to cover all the bases. So, having said all that, here is the list of things, in no particular order, that I would like to see worked on in the next few versions of Thunderbird. But first, I’ld like to say a little bit about why I want them.

I recently heard about someone who said “Thunderbird looks like iTunes”, and while that’s rather complimentary given the amount of time Apple puts into making things look good, it doesn’t really lead me to believe that people can pick our product out of a screenshot. And so one of the overall goals is to make Thunderbird iconic. You can always tell when a screenshot is of Apple mail, based on the layout and the lack of colour, and Firefox is similarly immediately recognizable because of the big circular back button and smaller rectangular forward button. Similarly, I’m hoping to have Thunderbird look different to other apps, while still fitting in on the platform, and maintaining a little consistency with Firefox. Of course, that’s not the only goal, nor even the main goal. My main idea for Thunderbird is to let you focus on the content that’s important to you, and not be distracted by things you don’t care about. Hopefully most of the changes I talk about here will help that, and as a side benefit also help to give us a more unique style.

A simple thing that will make the product nicer to use is just to line things up. We’re all over the place, and it should be fairly simple to make this better. There are a couple of bugs that are related to this, and I suspect we could file a few more for various other parts.
We want to put the tabs on top, because they let us put the compose and address book into tabs, while still having the appropriate toolbars. (As well, having everything be a tab makes the application more consistent, as described in the next point.)
This leads into removing the standalone Compose and Address Book windows. You’ll still be able to open a window for those functions, but it will just be a regular window with a Compose or Address Book tab. (No bugs for this yet. Removals are sensitive things, and we want to get the replacement UI working well before we remove the existing UI.)
We really want the Thunderbird button, so that we can hide the menus, and have less Glass on Windows, and make the most common actions easier to find and use.
But, to add that button, we first need to see what the most common menu items people use are, therefore we need Test Pilot.
We would like to add a HomeTab, to give people a personalized place to land when they start Thunderbird, or open a new window.
We would like to merge the Gloda bar and Quick Filter bar, cause duh.
Having two different settings locations is too confusing for me, let alone people who don’t care about the details of the product. We want to merge those into a single searchable place for all the settings, a la Mac System Prefs.
This next change is more a small, personal thing, rather than part of a grand plan. It was originally suggested by Mike Beltzner, and while I’ve had some time to work on it, I haven’t had enough to push it through to completion. Basically, I’ld like to be able to order my email by date, while grouping it by subject. (This is different than threading, because I don’t care about which replies are to which messages. I just want a single group for the subject, with the messages ordered by date within that group, and the groups ordered by the date of the most recent message.) There’s no bug for this yet, but as mentioned, I started to write an extension, before hitting some annoying bugs that made it hard.
Compactify the header. It’s really too big. Well, that’s a bit of a lie. What I really mean here is that we should move the buttons and their toolbar out of the header, to float just above it. This would allow people to easily turn them off (by removing the entire toolbar), and for those of us who like to keep them, it would make them more visually distinct. As an added bonus, in vertical mode, we could merge that toolbar with the other toolbars, to get something like the pictures of what Thunderbird could look like posted by Asa Dotzler.
And finally, I think we should remove the Migration Assistant. It was very useful in the 2.0⇒3.0 transition, but it’s been less and less useful as time goes on, and as people have moved more and more onto Thunderbird 3, and 4, and 5… (No bug for this one either, again, because removals are sensitive things.)

See all the bugs in one big list.

Many thank-yous to Alex Faaborg, and areweprettyyet for the code to link the bugs, and the basis of the styling to make them stand out.

A Proposal for Updates with Add-ons.

Blake Winton — Thu, 08 Sep 2011 18:49:44 GMT

Add-ons are an important part of many Mozilla products, and many people have noticed that they’ve taken a hit as we’ve switched to the Rapid Release process. To help users have a little more control over how well their Firefox works, I would like to propose the following slight modification to the automatic Update process:

It all starts when Firefox (and Thunderbird) notice an update is available.

We immediately check the user’s add-ons to see if they are compatible, or if there are compatible versions we haven’t downloaded yet.

If all the add-ons are compatible (or will be made so at the next download), we show the NoAddons dialog:

It‘s the same as the current Firefox or Thunderbird update dialog, and as you would expect, the “Ask Later” and “Update Firefox” buttons do the same things that they do now.

On the other hand, if there are in-compatible add-ons, we show the Addons dialog:

As you can see, we let the user know which add-ons are incompatible, and give the user an extra button at the bottom to do something different.

The new “Update when my add-ons work” button (wording to be clarified later) will check the add-ons periodically, and automatically update Firefox when all the add-ons are compatible. If the add-ons aren’t compatible after a week (period of time to be configurable), the user will be shown this dialog again, with the (hopefully smaller) list of incompatible add-ons.

Showing the user which add-ons are incompatible will let them decide whether the add-ons are important enough to not upgrade, or whether they can live with the (hopefully short) period of reduced functionality.

As always, comments welcome, but keep them polite or they’ll be deleted.

Who should review my change?

Blake Winton — Thu, 02 Jun 2011 00:13:37 GMT

One of the big questions I had when I started writing patches was who I should ask to review them. Now that I’ve been in the community for a while, I’ve got a much better sense of who I should be talking to for the type of things I’m likely to write, but there are still times when I want to make a change in a part of the code that I haven’t touched before, and I’m not sure who to ask. In those cases, I usually fall back to a fairly simple (if non-obvious) set of steps to try and figure out who to pick.

Get the list of files I’ve changed.
Get the hg log for those files.
Check through the log for “r=”, and “sr=”.

Of course, that’s a fairly easy set of steps to automate, and so I present my first cut at the automated reviewer chooser!

Of course, there are a lot of things I’ld like to do with this, such as:

Improving the documentation.
Checking to see how well this script would have done on previous commits.
Taking into account the length of the queues for the reviewers.
Adding some sort of recent-ness calculations.

But I think that this tool is useful enough in its current state that releasing it and getting feedback on what to actually work on would be a win.

To use it, be in a mercurial source repo, and type getReviewer.py to get a list of suggested reviewers for the current differences, or getReviewer.py temp.diff or getReviewer.py https://bugzilla.mozilla.org/attachment.cgi\?id\=536017 to specify a different set of changes.

New GetAnAccount UI.

Blake Winton — Fri, 01 Apr 2011 01:41:40 GMT

Since we released the GetAnAccount addon, we’ve had a lot of feedback. Many of the people who commented were looking for the option of getting an ad-supported account instead of paying for email access. We were always planning on integrating ad-supported services, as soon as we could, but of course, doing this required a redesign.

One important note before we get to the good stuff: I’ve used GMail soley as an example of a well-known ad-supported email provider here. We may or may not be partnering with them, and you should not take these screenshots as proof of our intentions one way or another.

As you can see from this first mockup, the initial view makes it much more obvious that you don’t need to create a new account just to use Thunderbird.

If you click in the bottom half, it expands up to make it more obvious that that’s what you want to do, and to allow us to display more information (although we don’t have any extra information to display there yet.

On the other hand, if you click on the top, we do have more information that you probably want to see before continuing on.

And this is something like what we hope to show you when the results have been returned. (Note: the Terms of Service, Existing Account, and Do It Later buttons are still there, but have been scrolled off the bottom of the dialog in this mockup.)

And finally, once you pick one of the providers, we expand that list to show you all of the results for that provider.

Feedback, as always, is welcome, either here or in the forum.

OpenSearch add-on for Thunderbird updated!

Blake Winton — Fri, 25 Feb 2011 16:25:47 GMT

Over the past week, I’ve been working on fixing some of the reported bugs in the OpenSearch add-on for Thunderbird, and now I think I’ve fixed enough of them to release a new version.

You can find the full details on the Mozilla Labs blog, or you could just jump straight to the OpenSearch add-on page to install it. And please leave your feedback about the add-on on our Google group!

What files have the most bugs?

Blake Winton — Fri, 24 Dec 2010 19:59:24 GMT

I was reading Making Software by Andy Oram and Greg Wilson, and got to the chapter about An Automated Fault Prediction System. It’s a pretty neat chapter, and it got me wondering which files in the Thunderbird code base had the most bugs. Now, I don’t have all the info I need, but I figured an easy first pass would be to go through the commit logs, and for each commit that started with “bug ”, add one to the files changed in that commit. Hmm, that sounded unintuitive. Let me just paste (and link) the code:

from mercurial import ui, hg
import operator
import re

ext = re.compile("(\.c(pp)?|\.js|\.xml)$")

repo = hg.repository(ui.ui(), ".")
changes = [repo[i] for i in repo
                   if repo[i].description().lower().startswith("bug ")]

master = {}

for change in changes:
  files = [f for f in change.files() if ext.search(f)]
  for f in files:
    master[f] = master.get(f, 0) + 1


files = master.items()
files.sort()
counts = master.items()
counts.sort(key=operator.itemgetter(1))
counts.reverse()
print "\n".join([c[0] + ":" + str(c[1]) for c in counts[:10]])

And so, without further ado, here are the files that have been changed the most in bug fixes, and the number of times they've been changed:

mail/base/content/mailWindowOverlay.js:109
suite/browser/browser-prefs.js:73
suite/browser/navigator.js:70
mail/base/content/msgMail3PaneWindow.js:69
mail/app/profile/all-thunderbird.js:67
suite/common/src/nsSessionStore.js:66
mail/components/compose/content/MsgComposeCommands.js:60
mailnews/imap/src/nsImapMailFolder.cpp:56
suite/browser/tabbrowser.xml:53
mail/base/content/msgHdrViewOverlay.js:52

As a side note, for the mozilla repo it looks like this:

js/src/jstracer.cpp:780
browser/base/content/browser.js:654
layout/base/nsCSSFrameConstructor.cpp:410
layout/base/nsPresShell.cpp:400
js/src/jsobj.cpp:399
browser/base/content/tabbrowser.xml:397
widget/src/windows/nsWindow.cpp:390
toolkit/components/places/src/nsNavHistory.cpp:374
js/src/jsinterp.cpp:345
js/src/jsapi.cpp:343

Making sure I don’t forget things.

Blake Winton — Sun, 05 Dec 2010 00:49:11 GMT

I’ve created a couple of checklists, and would like to hear any feedback on them. They are a Review Checklist, and a Commit Checklist.

They came about after I had been working mostly on experimental add-ons for a while, and then attempted to push a couple of reviewed fixes. Since I was out of practice, I managed to get something minor wrong on both of the pushes. (The first one failed to attribute the patch to the proper author; The second one failed to mention the bug number in the commit message.) Since I’m a bit of a perfectionist, this really annoyed me, and so I vowed to write up the steps that I go through when I need to commit and push a patch, so that I could refer to them later, since if checklists can save lives, then I figure they can probably also help me do my job better. But before I go to that, I needed to review a patch, so I wrote up some of the things I look for when I review a patch too.

DOM appendChild error in Gecko 2.0

Blake Winton — Tue, 30 Nov 2010 15:58:11 GMT

I was recently modifying an add-on for the upcoming Thunderbird 3.3, and part of what I wanted to do was to run some javascript in a chrome context that added some DOM nodes to a document in a content context. But when I ran the following code:

let browser = document.getElementById('tabmail').getBrowserForSelectedTab();
let doc = browser.contentDocument;
dump("\n\n\n\nXXXXXXXXXX\n");
dump("DOM Content loaded for " + doc.location + "\n");
var topBar = document.createElement("div");
topBar.innerHTML = "We got it!!!!!";
dump("iB = "+doc.body.insertBefore+"\n");
dump("fC = "+doc.body.firstChild+"\n");
doc.body.insertBefore(topBar, doc.body.firstChild);

I got the following error:

WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x80530009: file /Volumes/Devel/thunderbird/src-central/mozilla/content/base/src/nsNodeUtils.h, line 304
WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x80530009: file /Volumes/Devel/thunderbird/src-central/mozilla/content/base/src/nsGenericElement.cpp, line 4077
-- Exception object --
[snip…]
+ message (string) 'Operation is not supported'
+ result (number) 2152923145
+ name (string) 'NS_ERROR_DOM_NOT_SUPPORTED_ERR'

Poking around a little, it seemed like I had reasonable things for the insertBefore method, the firstChild attribute, and the topBar variable, and so since it was late, and I couldn't see what I had done wrong, I went to bed.

That turned out to be a the best thing for me to do, because this morning Jonathan Protzenko came to the rescue, saying (in response to a similar problem with a Firefox 4.0 beta 7 extension):

If you're modifying some content DOM from chrome code, you need to make sure the child you're appending was created using the unprivileged document, not the global document.
// This is chrome code, this is wrong because the span is now chrome
// and you're trying to insert it into content
myContentNode.appendChild(document.createElement("span"))

// This is right, appending a content node to another content node
myContentNode.appendChild(myContentNode.ownerDocument.createElement("span"))
I've hit this issue at least three times when upgrading stuff for Gecko 2.0. Might be what you're looking for .

And sure enough, when I changed var topBar = document.createElement("div"); to var topBar = doc.createElement("div"); , it all started working beautifully.

Thank you, Jonathan!