If you've been putting it off because other things always seemed to get in the way, you're in luck. It's not too late! You still have time to follow me on Twitter and perhaps be witness to my first 'tweet'.

Join the tens! of people who are already following me on Twitter in anticipation of my first post and you might just get to see me type something somewhere else some time!

Then again, if past performance is any kind of indicator of future results, probably not.

I learned about the Mozilla student club at Jordan University through Issa Mahasneh’s group on Spread Firefox, the online home of our Firefox marketing community.

Hey Issa: this is a really well-done design. Great combination of an overall visual metaphor (a student’s desk), professionally-executed graphic design, and balance overall between your copy and imagery. Thank you for sharing this!

* For those of you who are students or interested in general in helping out with grassroots marketing projects, check out Spread Firefox and The Mozilla Blog to participate or just keep up with our adventures bringing Firefox to the world.

ShareThis

For those of you who read the somewhat widespread coverage of the Vietnamese language pack add-on issue and came away wondering if Firefox was indeed infected with worms, demolishing city blocks underfoot, and stealing babies, I've posted a few responses to the common misunderstandings and misreportings around the issue over at the For the Record blog.

After the wildly popular April 30th report, we have much to report. Here is the current update of the top add-ons NOT yet compatible with Firefox 3. Be sure to check-out the RedShift V2 theme report!

Skype Toolbar for Firefox - 2.0.0.* (bug) - beta shipping in their builds. They are not going to be hosted on AMO — so removing from the list.

Now for the most used add-on that is not yet on AMO…

Firebug - 2.0.0.* (bug) - Still waiting on Firebug performance issues that will be resolved in the Firebug 1.2 b1 release. No updates from last week.

Tab Mix Plus - 3.0a5 (bug) - development builds available over here. Still no direct contact with the developers. Any help here appreciated!

Noia 2.0 (eXtreme) - 2.0.0.* (bug) - No new news, just an indication that it will land with Firefox 3. No direct communication with the developer — help appreciated.

FireFTP - 2.0.0.* (bug) - Will be shipped with Firefox 3. Minimal contact with developer.

Foxmarks Bookmark Synchronizer - 2.0.0.* (bug) - got an email from Foxmarks, it has over 10k beta users — and is right around the corner. There is one blocking bug, once it is resolved they will be ready to ship.

FoxyTunes - 2.0.0.* (bug) - beta available here. Will be shipped with Firefox 3.

Blue Ice - 2.0.0.* (bug) - development homepage says “coming soon”. Need help figuring out status. Any details appreciated!

RedShift V2 RC1 - 2.0.0.* (bug) - this developer gets a gold star. He is having trouble getting updated to Firefox 3, so he opened his code. You can find the project over at google code. Redshift is the second most popular theme on AMO — and you have the opportunity to contribute. Please help make one of the most popular add-ons on AMO compatible with Firefox 3!

Note: Piclens was on last weeks list, but is now updated to 3.0pre. Thanks Cooliris team!

ColorfulTabs - 2.0.0.* (bug) - Updated to beta 3 at one point, no longer updated. If anyone knows what is going on with the add-on, help is appreciated!

MinimizeToTray - 2.0.0.* (bug) - This add-on is blocked on a bug that will not be updated before Firefox 3. Decent contact with the developer, but no action or known intentions to updating to Firefox 3. Could really use help testing / updating for Firefox 3.

That’s this weeks update. RedShift needs development help, check out the google code project if you can. MinimizeToTray needs a work around, and has not started development. PicLens got updated. The rest seem like they are on their way!

UPDATE: this post is available in Japanese. Thank you Amigomr!

The Thunderbird folks are organizing a bug test day this Thursday, 08 May 2008, in preparation for Alpha 1 release. The schedule is located here. Generally, feel free to pop by outside of the sessions as well, some experienced folks should be around to help you.

The focus of this bug test day is found here.

The nightlies are here if you want to try out potential Alpha 1 builds.

Thunderbird 2.0.0.14 builds:

Official Windows installer

Official Linux (i686)

Official Mac (Universal binary)

Please drop by #testday and help us test Alpha 1; we need your help! First timers and experienced triagers welcome.

I will be available throughout all three the last two timeslots to assist anyone who wants to contribute. (My nick is "nth10sd") Several experienced folks will be there to assist as well. More testday information is available at the QMO blog.

The results of the bug test day will be posted to Mozilla Wiki.

Ken Kovash has an update on the Net Applications Market Share data for the month of April that reported an across the board drop in not-IE market share and a pretty substantial spike for IE 6.

Long story short, the report was wrong, Firefox did not lose share, IE didn't have a massive spike, and Net Applications will be posting a corrected report.

Here's what they had to say:

The April, 2008 market share data has some significant variations from established trends.  The following major anomalies occurred on April 18th:

A 25% increase in visitors

A 3% drop in Firefox share

A 4.9% increase in Internet Explorer 6.0 share

A 3.4% increase in Windows XP share (with a small drop in Mac share)

A .7% drop in Windows Vista share

Since April 18th, all trends have returned to expected values, including an expected uptick in Vista share due to the release of SP1.

Once we discovered the extent of the variations, we have worked diligently to discover the cause.  The variations were coincidental to the release of Vista SP1 to automatic updates, so we initially thought there might be a connection.  However, our investigation showed Vista SP1 had nothing to do with the problem.

What happened was a distributed collection of sites inadvertently caused the problem.  We can't identity the sites responsible, but the nature of the problem is that all the millions of new visitors we saw were part of a massive marketing campaign that only worked on Internet Explorer.  This glitch caused respective drops in Firefox, Safari and Opera share.

We are in the process of removing the skewing data.  It should be completed by May 7th.

So, one anomalous day that was enough to skew the monthly report. Now, had I subscribed to Net Application's super cool upgraded version, I'd have seen this as a one week anomaly in a specific geography (weekly reports and geo location data being the key parts of the paid upgrade,) and a return to normal trends before the month was over, saving me a few gray hairs. Live and learn :-)

A big thanks to Ken Kovash and Net Applications for getting to the bottom of this.

I spent some of last Thursday and most of last Friday being an Election Observer for the Open Rights Group, observing the London Mayoral and Assembly elections. ORG's interest is particularly with the electronic vote counting, which happened at three locations around the city. I personally found it very interesting, and some exciting things happened. ORG will be publishing a report in mid-June, and you can then read all about it. :-)

I and a few others have been poking at our widget layer for the past few weeks, looking at adding Qt support.  There was an earlier attempt at a Qt backend, but it never really got maintained, and there wasn't much interest in it back then.  Recently, though, Qt has made great strides on embedded devices and with support for advanced graphics architectures (such as support for OpenGL and DirectX rendering), and might be a great way for us to get a feel for some of the problems we'll face in the future when we try to integrate 3D-accelerated rendering into Gecko.  Folks at Nokia have contributed much of this code, since they're interested in experimenting with Qt as well.  We've got the initial work available on a hg branch (off mozilla-central; our first experiment on big-project branches in the future hg world).

I've had a great time working with Qt so far; it seems like a well-designed modern toolkit.  There are a few quirks; most notably, the pieces that Gecko/Cairo needs to render text aren't really there, but on the whole the integration is pretty good.  The big text piece that's missing is a drawGlyphs method on QPainter — something that would take a QFont and an array of glyphs and positions.  Additionally, methods to go from a string to an array of glyph indices/positions for a given QFont would also be helpful (though most of our font backend here is using FreeType directly, so we can obtain glyph indices directly).  In the QPainter Cairo backend that I wrote, I kind of cheat on this issue under X11 — I grab the X Drawable and pass on the show_glyphs work down to a wrapper xlib surface... but that doesn't work for Qt Embedded.  Anyone out there who knows Qt innards well want to implement this?

There are a few other minor annoyances with QPainter; Cairo's rendering code does a pretty good job of letting operations be specified in a general way (e.g. everything with paths), and it does whatever optimizations are possible internally (e.g. converting a rectangular path to a rectangle for clipping/painting purposes).  QPainter doesn't seem to have these optimizations for the general path methods, so the QPainter backend has to do a bunch of extra work to detect this case to call the faster filling functions.  Similar optimizations are missed for brushes — filling with a tiled pixmap QBrush is slower than calling drawTiledPixamp, even without transforms.  The Cairo backend tries to handle these cases, but there's more that needs to be done.

Overall, though, what's on the Qt branch now works pretty well under X11; under Qt Embedded, there are some problems with text rendering mentioned above, but things are in good shape otherwise.  I hope that in the future that the Qt port will be a toplevel supported Gecko port, alongside gtk2, Win32, and OSX, but there's still a bunch of work needed to make that happen.  If anyone's interested in helping out, drop in to #gfx on mozilla irc!

(Note that there aren't any plans on switching away from gtk2 for our official Linux/X11 builds; gtk2 will remain the default supported toolkit there.)

Deb's got another great Firefox 3 feature blog post up. This time she's delivering the goods on the Site Identification Button and "Larry" the Passport Officer.

Oh, and after you've read it, go digg it so others can learn.

When I first wrote Cascading Style Sheets: The Definitive Guide, the part that caused me the most difficulty and headaches was the line layout material. Several times I was sure I had it all figured out and accurately described, only to find out I was wrong. For two weeks I corresponded with Ian Hickson and David Baron, arguing for my understanding of things and having them show me, in merciless detail, how I was wrong. I doubt that I will ever stop owing them for their dedication to getting me through the wilderness of my own misunderstandings.

Later on, I produced a terse description of line layout which went through a protracted vetting process with the CSS Working Group and the members of www-style. At the time it was published, there was no more detailed and accurate description of line layout available. Even at that, corrections trickled in over the years, which made me think of it as my own tiny little The Art of Computer Programming. Only without the small monetary reward for finding errors.

The point here is that line layout is very difficult to truly understand—even given everything I just said, I’m still not convinced that I do—and that there are often surprises lurking for anyone who goes looking into the far corners of how it happens. As I’ve said before, my knowledge of what goes into the layout of lines of text imparts a sense of astonishment that any page can be successfully displayed in less than the projected age of the universe.

Why bring all this up? Because I went and poked line-height: normal with a stick, and found it to be both squamous and rugose. As with all driven to such madness, I now seek, grinning wildly, to infect others.

Here’s the punchline: the effects of declaring line-height: normal not only vary from browser to browser, which I had expected—in fact, quantifying those differences was the whole point—but they also vary from one font face to another, and can also vary within a given face.

I did not expect that. At least, not consciously.

My work, let me show it to you: a JavaScript-driven test file where you can pick from a list of fonts and see what happens at a variety of sizes. (Yes, the JS is completely obtrusive; and yes, the JS is the square of amateur hour. Let’s move on, please. I’m perfectly happy to replace what’s there with unobtrusive and sharper JS, as long as the basic point of the page, which is testing line-height: normal, is not compromised. Again, moving on.)

When you first go to the test, you should (I hope) see a bunch of rulered boxes containing text using the very common font face Webdings, set at a bunch of different font sizes. The table shows you how tall the simple line boxes are at each size, and therefore the numeric equivalent for line-height: normal at those sizes. So if a line box is using font-size: 50px and the line box is 55 pixels tall, the numeric equivalent for line-height: normal is 1.1 (55 divided by 50).

On my PowerBook, Webdings always yields a 1:1 ratio between the font-size and line box height. The ten-pixel font size yields a ten-pixel-tall line box, and so on.

This is actually a little surprising by itself. The CSS 2.1 specification says:

normal

Tells user agents to set the used value to a “reasonable” value based on the font of the element. The value has the same meaning as <number>. We recommend a used value for ‘normal’ between 1.0 to 1.2. The computed value is ‘normal’.

This is basically what CSS has said since its first days (see the equivalent text in CSS1 or in CSS2 for confirmation) and there’s always been a widespread assumption that, since 1.0 is probably too crowded, something around 1.2 is much more likely.

So finding a value of 1 was a surprise. It was an even bigger surprise to me that this held true in Camino 1.5.2, Firefox 2.0.0.14, and Safari 2.0.4, all on OS X. Firefox 3b5 didn’t render Webdings at all, so I don’t know if it would do the same. I actually suspect not, for reasons best left for another time (and, possibly, a final release of Firefox 3).

Various browsers doing the same thing in an under-specified area of the spec? That can’t be right. It’s pretty much an article of faith that given the chance to do anything differently, browsers will. The sailing was so unexpectedly smooth that I immediately assumed was that a storm lurked just over the horizon.

Well, I was right. All I had to do was start picking other font faces.

To start, I picked the next font on the list, Times New Roman, and the equivalent values for normal immediately changed. In other words, the numeric equivalents for Times New Roman are different than those for Webdings. The browsers weren’t maintaining a specific value for normal, but were altering it on a per-face basis.

Now, this is legal, given the way normal is under-specified. There’s room to allow for this behavior. It’s actually, once you think about it, a fairly good thing from a visual point of view: the best default line height for Times New Roman is probably not the best default line height for Courier New. So while I was initially surprised, I got over it quickly. The seemingly obvious conclusion was that browsers were actually respecting the fonts’ built-in metrics. This was reinforced when I found that the results were exactly the same from browser to browser.

Then I looked more closely at the numbers, and confusion set back in. For Times New Roman, I was getting values of 1.1, 1.12, 1.16, 1.15, 1.149, and 1.1499. If you were to round all of those numbers to two decimal points, you’d get 1.10, 1.12, 1.16, 1.15, 1.15, 1.15. If you round them all to one decimal place, you’d get 1.1, 1.1, 1.2, 1.2, 1.1, 1.1. They’re inconsistent.

But wait, I thought, I’m trying to compare numbers I derived by dividing pixels by pixels. Let’s turn it around. If I multiply the most precise measurement I’ve gotten by the various font sizes, I get… carry the two… 11.499, 28.7475, 57.495, 114.99, 1149.9, 11499. As compared to the actual values I got, which were 11, 28, 58, 115, 1149, and 11499.

Which means the results were inappropriately rounded up in some cases and down in others. 28.7475 became 28 and 1149.9 became 1149, whereas 57.495 became 58. Even though 11.499 became 11 and 114.99 became 115.

This was consistent across all the browsers I was testing. So again, I was suspecting the fonts themselves.

And then I switched from Times New Roman to just plain old Times, and the storm was full upon me. I’ll give you the results in a table.

Much the same happened when comparing Courier New with plain old Courier: full consistency on Courier New between browsers, albeit with the same strange (non-)rounding effects as seen with Times New Roman; but inconsistency between browsers on plain Courier—with Camino yielding a flat 1 down the line, Firefox going from 1.2 to 1, and Safari having a range of values above the others’ values.

Squamous! Not to mention rugose!

Now it’s time for the stunning conclusion that derives from all this information, which is: not here. Sorry. So far all I have are observations. I may turn all this into a summary page which shows the results for all the font faces across multiple browsers and platforms, but first I’ll need to get those numbers.

I do have a few speculations, though:

1. Firefox’s inconsistency within font faces (see Times and Courier, above) may come from face substitution. That’s when a browser doesn’t have a given character in a given face, so it looks for a substitute in another face. If Firefox thinks it doesn’t have 10-pixel Times, it might substitute 10-pixel something else serif-ish, and that face has different line height characteristics than Times. I don’t know what that other face might be, since it’s not Times New Roman or Georgia, but this is one possibility. It is not the minimum font size setting in the preferences, as I’ve triple-checked to make sure I have that set to “None”.

2. Another possibility for Firefox’s line height weirdness is a shift from subpixel font rendering to pixelly font rendering. 10-pixel text in Firefox is distinctly pixelly compared to the other browsers I tested, while sizes above there are nice and smooth. Why this would drive up the line height by two pixels (20%), though, is not clear to me.

3. Much of what I’ve observed will likely be laid to rest at the doorsteps of the font faces themselves. I’d like to know how it is that the rounding behaviors are so (mathematically) messed up within faces, though. Perhaps ideal line heights are described as an equation rather than a simple ratio?

Again, this was all done in OS X; I’ll be very interested to find out what happens on Windows, Linux, and other operating systems. Side note for the Mac Opera fans warming up their flamethrowers: I’ve left Opera 9.27 for OS X out of this because it seems to cap font sizes at a size well below 1000, although this limit varied from one face to another. Webdings and Courier capped at 507 pixels, whereas Courier capped at 574 pixels and Comic Sans MS stopped at 707 pixels. I have no explanation, though doubtless someone will, but the upshot is that direct comparisons between Opera and the other browsers are impossible. For sizes up to 100 pixels, the results were exactly consistent with Camino, if that means anything.

The one tentative conclusion I did reach is this: line-height: normal is a jumbled terrain of inconsistent behaviors, and it’s best avoided in any sort of precision layout work. I’d already had that feeling, but at least now there’s some evidence to back up the feeling.

In any case, I doubt this is the last I’ll have to say on this particular topic.

Update 7 May 08: I’ve updated the test page with a fix from Ben Lowery so that it works in IE. Thanks, Ben! Now all I need is to add a way to type in any arbitrary font-family’s name, and we’ll have something everyone can use. (Or else a way to use JavaScript to suck up the names of all the fonts installed on a machine and put them into the dropdown. That would be cool, too.)

Last month's Net Applications browser market share data looked a bit odd to me. Ken Kovash and the Net Applications folks are on the case.

One of my colleagues just pointed me to this blog post where Simeon Bateman calls Mozilla an ungrateful child.

I started to post a reply there but it got a bit longer than what I think fits in "comments" format so I'm posting it here instead (though, this is still more in the "reply" format than the "post" format.)

Simeon's basic assertion is that Adobe is doing a lot to open up some parts of their next-generation platform and Mozilla is a crybaby for suggesting that Adobe might have less than pure motives.

A secondary point, if I'm reading him correctly, is that Adobe deserves to be making lots of money by extending its control of the Web and Mozilla shouldn't be complaining about corporations undermining the free and open Web for profit because Mozilla gave up any say it had when it decided to operate as a public-benefit organization. Stupid Mozilla. You never should have put the interests of a free and open Internet ahead of the corporate bottom line.

So, here's my reply:

For Microsoft and Adobe, it's not about the money (yet.) It's about owning the platform.

Right now, the Web platform doesn't belong to any mega-corporation and the protocols and specifications that underlie the Web are developed in a cooperative process between many of the implementers.

The real issue here is the Web platform (HTML/CSS+JavaScript, plus lots of other cool bits,) that Adobe and Microsoft are challenging and determined to supplant and replace.

It's not that difficult for honest observers to admit that the open Web platform is much harder to monetize over the long run than open Web replacements like Adobe's flex+flash+actionscript or Microsoft's xaml+wpf+.net. (and yes, don't kid youself. Adobe and Microsoft are building replacements for the open Web with Air and Silverlight.)

Both Microsoft and Adobe want to own as much of the post-desktop platform as possible. Adobe has a big short term lead with the ubiquity of Flash, and Microsoft has the medium term advantage of a desktop monopoly with Windows (and whatever they want to label and distribute as a part of Windows.) The Air and Silverlight pushes coming from these companies are all about who will own the biggest piece of the next-generation Web platform pie.

And, don't be fooled by the big giveaways from Adobe and Microsoft. If owning the eventual Web.next platform, or even a large chunk of it, means giving away a lot in the short term, they're happy to give, give, give. It's taken a decade and a half for the Web to advance to where it is today and Microsoft and Adobe aren't focused on 2008 or even 2009. They're looking out at the Web of 2010 and beyond and doing everything in their power to be in control of as much of that space as possible.

As for what they're actually giving away, documenting the protocols and specifications and allowing others to re-implement them is interesting, but it's not open. Open is developing the protocols and specifications in a co-operative and participatory environment and then competing on implementations. Neither Adobe nor Microsoft are being truly open on this front, because doing so would mean giving up their big shot at control of the next generation Web platform.

If I was in Adobe's shoes, I'd give everything away, all of it. Hell, I'd pay people to develop on the Adobe platform and I'd encourage dozens of competing implementations of my platform across every type of device imaginable because, in the end, it'd be my platform and I'd decide how and when it evolved and to what ends.

And I'd do the same if I was Microsoft.

But, I'm neither. So, all I can do in this battle for the future of the Web is to advocate for advances in real open Web standards from groups like ECMA, W3C, and WHATWG. It may be a bit slower to market, (hopefully not too much slower,) via the collaborative and open road, but the end result is a powerful Web platform that isn't, and cannot be, controlled by any one company.

And to those who think I'm some anti-capitalist, I don't think there's anything wrong with people and companies making money. I don't even care if they're making ridiculous amounts of money. But the Web has always been about more than making ridiculous amounts of monkey. The Web has substantial non-commercial aspects including critical educational, social, and civic value that should not be owned or controlled for the purpose of driving corporate profits.

If we cede control of the Web platform to one or two large corporations, we will cede a big piece of what makes the Web so amazing and no short-term sparkle and flash are worth that concession.

Be careful. The first dose is always free.

Photo by Flickr user laughlin and used under a Creative Commons license.

Those marked as “yes” for active in Fx3 are going to be the indivuals in the credits for Firefox 3.  Please take a look and mail me with suggested changes ASAP.  Please don’t comment in the bug, I don’t want anyone put in an awkward position…

As a reminder, the criteria is anyone who made a substantial contribution to shipping Firefox 3, from design and engineering, to critical support people, and marketing/PR.  There isn’t a hard line, or a truly objective set of criteria, everything comes down to my discretion as the product owner.

Current Sunbird (0.8) | Next planned Sunbird (0.9) | Previous releases

Common:

• Fixed: 386596 - Option to show completed Tasks should be moved to the menu
• Fixed: 392855 - [Today Pane] 'Show Today Pane' button not available with fresh profile
• Fixed: 395928 - Event Dialog: Unify wording by renaming Importance to Priority
• Fixed: 414932 - Change String Name imipHtml.Comment to imipHtml.comment
• Fixed: 418414 - Remove obsolete Jan Mayen references
• Fixed: 420832 - Crash on exit while caldav-Calendars are being reloaded [@ OperationStreamListener::OnStopRequest]
• Fixed: 428392 - Accepting Events not adding event to calender - falsely reporting "not an attendee"
• Fixed: 429093 - Add margin to Event List for Today Pane
• Fixed: 429908 - Minimonth broken on Trunk
• Fixed: 429911 - [Minimonth] Year Popup doesn't listen to scrollwheel.
• Fixed: 429912 - Packaging cleanup for crashreporter.xpt
• Fixed: 429927 - Remove outdated comment from calendar/base/jar.mn
• Fixed: 430062 - remove some 1.8.0 branch specific code from calManager
• Fixed: 430430 - Consolidate context menus
• Fixed: 431031 - Remove files from resources/content/converters directory
• Fixed: 431041 - Correct tooltip for Print toolbarbutton
• Fixed: 431395 - Remove ununsed files from /calendar/resources/content/

Common (Providers):

• Fixed: 400278 - CalDAV provider issues requests to unselected caldav accounts at startup
• Fixed: 410898 - DTSTART/DTEND ignored in FREEBUSY response to scheduling request
• Fixed: 417629 - Import ICS file to CalDAV server fails to handle recurrence-id correctly
• Fixed: 428851 - Accepting Meeting Invites Does Not Update Google Calendar
• Fixed: 429061 - webcals scheme not supported (i.e., for https)
• Fixed: 430249 - Storage calendar sends out too many onOperationCompletes
• Fixed: 430280 - bad aOperationType on addItem

No outstanding bugs (marked blocking-calendar0.9+).

Lightning .xpi:

Official Windows .xpi, gdata provider

Official Linux .xpi, gdata provider

Official Mac .xpi, gdata provider

Sunbird builds:

Official Windows, Official Windows installer

Official Linux (i686)

Official Mac (Universal binary)

What's new in Trunk since 12 August 2005 | Previous releases

Thunderbird-specific:

• Fixed: 424098 - One mail identity that is a substring of another mail identity will make thunderbird fail to idenify the sender of a reply or forward mail
• Fixed: 424764 - Error: selectedFolders[0]/msgFolder is undefined when opening the File menu of the standalone msg window
• Fixed: 426715 - can't open new composition window anymore ("An error occurred while creating a message compose window. Please try again."
• Fixed: 427203 - Investigate turning on the ftp protocol in Thunderbird builds
• Fixed: 428062 - Command Shift M broken (os x, nightlies)
• Fixed: 428620 - 'Get Mail' fails for selected inbox in folder pane
• Fixed: 428887 - accounts not listed in account order under the Get Mail button
• Fixed: 429032 - Filter dialog broken
• Fixed: 429844 - Thunderbird Linux and Mac trunk l10n builds have "Mail/News" branding instead of "Thunderbird"
• Fixed: 429942 - Ditch prebinding for Thunderbird trunk builds
• Fixed: 431171 - Thunderbird crashes on closing address book.

MailNews and other related categories:

• Fixed: 332110 - Attaching out-of-locale Unicode-named file fails: won't send
• Fixed: 410747 - IMAP code deadlocks when it can't reach the network
• Fixed: 422178 - IMAP thread calls docloader from wrong thread [@ JS_BeginRequest]
• Fixed: 424570 - ###!!! ASSERTION: shouldn't have any listeners: 'm_ChangeListeners.Length() == 0' after adding and removing a mailing list
• Fixed: 424607 - Numerous regressions in news groups (caused by fix for bug 16913 ?)
• Fixed: 428614 - Crash every time I try to read news [@SearchTable]
• Fixed: 428996 - Expose less of the messenger chrome package to content
• Fixed: 430736 - Crash [@ strlen - nsCharTraits<char>::length - nsDependentCString - nsMsgSearchValueImpl::GetStr] clicking on saved search folder

Thunderbird 3 Alpha 1 is now in code freeze.

Outstanding bugs (marked blocking-thunderbird3.0a1+): (2)

• Since 07 Jan 08: 411171 - Thunderbird Mac tinderbox crashing in dump_syms
• Since 15 Apr 08: 429235 - Prepare Thunderbird 3.0 Alpha 1 release notes

Official Windows, Official Windows installer (discussion)

Official Linux (i686)

Official Mac (Universal binary)

Current Thunderbird 2.0 (2.0.0.14) | Next planned Thunderbird 2.0 (2.0.0.15?) | Previous releases

No checkins during this period.

No outstanding bugs.

Thunderbird 2.0.0.14 has been released.

Official Windows, Official Windows installer (discussion)

Official Linux (i686)

Official Mac (Universal binary)

A while back, there was a major update to the Add-ons site. At that launch, it was decided to try to move the site forward with a series of smaller milestones rather than one big one at the end. The first of those milestones is complete and addresses some of the great feedback on the 3.2 release.

Head over to Basil's Bodacious Blog for the detailed rundown.

Photo by Flickr user Roger Smith and used under a Creative Commons license.

For many months, my custom-built WinXP desktop has been giving me blue screens of death, and more recently, random restarts. Since I can't use it to build Mozilla anymore, I decided I might as well take it into the shop for repairs. The company that built it is closed on weekends (grrr), so I dropped it off at Fry's Electronics for a diagnostic.

Several days later, I spotted a computer deal that was pretty hard to beat: a Gateway GT5676 computer, 64-bit AMD processor...

I'm giving the venerable ScribeFire blogging add-on for Firefox another go.

In many ways it feels like a more solid tool than it did in the pre-2.x days but there are still some bits that still feel kinda clunky to me. Stacked sets of tabs and that ancient seamonkey splitter widgets for resizing the panels are a couple of UI bits that could use some cleanup.

Another area of some clunkyness is the category selection list and post options like timestamp, buried off in some tabbed panel to the side, rather than in the toolbar/title/formatting area with other post-related tools. I think the ScribeFire logo area to the right of the title form would be a much better location for a category select widget for blogs that support one category per post, or an auto-completing, comma-separated tag/category field for blogs that support multiple categories/tags.

Also, the share, configure, and info tabs are just wasting space. Share should just live in a browser context menu and be activated from the blog post itself (or any other page.) Configure and app info should be accessed from the add-ons manager preference.

Finally, the main compose panel needs some min-height and min-widths or something to keep the save/publish/delete/etc. buttons from getting pushed out of view.

What I like about the new version, though, is a lot more interesting than what I don't. Tabbed editing of posts makes managing a few in-progress posts much easier to manage. The YouTube and Flickr integration is quite nice and makes me want more (more sites, more search options, and saved/recent list or something like that.)

Overall, good progress and I hope to see more.

Update: Ugh. Why the <br /><br /> tags rather than, you know, actual paragraphs?

More to come on Canvas 3D in a bit, but I wanted to post that I've (finally!) updated the Canvas 3D extension to work with the latest Firefox 3 betas — will work with the latest nightlies, and should work with 3.0b5 as well.  You can grab it from its new home at addons.mozilla.org, which will give me the ability to push updates in the usual addon update fashion.  In the next week I'm going to try to provide builds that can use pure software rendering through Mesa 3D, for those without working GL support.  (The previous post on Canvas3D has some more information and a few test examples.)

I've tested this build on OS X and Windows; I was unable to test in Linux under VMware — Firefox crashed with a GLXUnsupportedPrivateRequest X error.  (If anyone wants to check this under Linux with a real OpenGL driver, let me know how it goes.)

Not just a victory, but a domination: Firefox wins the LinuxJournal's Readers' Choice Awards once again and this time with 86% of respondents giving the thumbs up to Firefox.

Firefox wins Favorite Web Browser with 86% of your votes. But where, oh where, have the very capable Opera and Konqueror gone? Fewer than 5% of you named them your favorite browser.

Linux is kind of an unknown when we talk about Firefox users. Because most Linux users get Firefox from their Linux distribution rather than from Mozilla, we don't have any decent visibility into how many of them there are. What we do know from this survey, and many others like it, is that Firefox is far and away the top browser on Linux.

This is a testament to the power of "shipping with the OS" and to the strength of Firefox considering that most Linux users are very comfortable downloading and trying new programs.

The Thunderbird folks are organizing a bug day this Thursday, 01 May 2008. The schedule is located here. Generally, feel free to pop by outside of the sessions as well, some experienced folks should be around to help you.

The focus of this bug day is found here.

How?

Triaging is easy! You don't have to be able to understand computer languages in order to triage most bugs.

You just have to try and reproduce the bug by following the steps written in the report. Add a comment stating whether the bug still applies in the latest supported version of Thunderbird 2 (2.0.0.12), or in the trunk nightlies (3.0a1pre) for the more adventurous.

Thunderbird 2.0.0.12 builds:

Official Windows installer

Official Linux (i686)

Official Mac (Universal binary)

Please drop by #bugday and help us get our bug numbers down; we need your help! First timers and experienced triagers welcome.

I will be available throughout all three the last two timeslots to assist anyone who wants to contribute. (My nick is "nth10sd") Several experienced folks will be there to assist as well.

The results of the bug day will be posted to Mozilla Wiki.

P.S.: Apologies for the lack of updates on The Rumbling Edge so far. I have been really busy these couple of weeks. I hope to give more updates, especially with the impending release of Thunderbird 3 Alpha 1 in the next few weeks, soon.

Based on feedback from last weeks report, I’m going to change how we do this. I’m going to go through the status of the top 10 add-ons that are not yet on addons.mozilla.org with Firefox 3 compatibility.

Skype Toolbar for Firefox - 2.0.0.* (bug) - beta available over on skype’s website, not sure when it will land on AMO.

Firebug - 2.0.0.* (bug) - Platform/Firefox issues resolved, now blocked on Firebug performance issues that will be resolved in the Firebug 1.2 b1 release.

Tab Mix Plus - 3.0a5 (bug) - still no direct contact with the developer. On the development forums, there are working releases. However, if you know anyone in the TMP community updates, help is appreciated! We really want TMP to be ready for Firefox 3.

Noia 2.0 (eXtreme) - 2.0.0.* (bug) - Our status indicates that this will land with Firefox 3. Any further information would be appreciated.

FireFTP - 2.0.0.* (bug) - compatible on the development website, but no direct contact with the developer. Looks ready, but still not on AMO, and we have no idea why not.

Foxmarks Bookmark Synchronizer - 2.0.0.* (bug) - beta on dev website. No direct contact with developers.

FoxyTunes - 2.0.0.* (bug) - beta in the works, but have not seen it. We have had direct contact with the developer, but still have not seen the .xpi on AMO.

Blue Ice - 2.0.0.* (bug) - development homepage says “coming soon”. Limited contact with developer. No known available betas.

RedShift V2 RC1 - 2.0.0.* (bug) - comments on AMO indicate it is in the works, limited contact with the developer. Help appreciated finding out the current status!

PicLens - 2.0.0.* (bug) - beta available on the beta site. Not sure when it will be on AMO.

In summary, all of the top 10 not-yet-compatible add-ons have some sort of hint that a Firefox 3 compatible release is on its way. If you have any updates about RedShift, Blue Ice, TMP, or FireFTP, please let me know!

If you were holding off on using the Firefox 3 betas or nightly builds because your extensions weren't compatible, another one just fell off that list. Today, over at the Delicious Blog, Nick says,

Firefox 3 users, rejoice! Today I’m pleased to announce a beta release of an enhanced version of our Firefox Add-on for del.icio.us that now has full Firefox 3 support while retaining Firefox 2 compatibility. While it is largely similar to the release version of our Firefox Add-on, there are a few nifty new features:

• Jump to Tag feature (press F2) allows you to quickly access tags and bookmarks using the keyboard
• New layout for saving bookmarks
• Preferences now in a separate dialog under Tools (which also can be invoked via the prefs button on the FF Add-ons pane)
• Status bar indicators for network activity, new links for you, and the del.icio.us website
• Classic mode for users who just want simple buttons without the overhead of sync

I spent the last week getting debug+leak testing slaves setup on our 3 key platforms for Moz2. This moves us a little closer to build system parity with current trunk development.

I’ve put my setup notes in the wiki to aid the next person.

We have this site called build-graphs.mozilla.org.  We seem to have a situation where nobody remembers why it still exists.  Given the number of tinderboxes that still report data to it, I find that hard to believe, so hopefully this blog post will shake out a few people who remember (in case I failed to CC the right people already). :)  If that’s you, go make yourself heard on bug 428617.

My Spurs rant wasn’t meant for planet — put the wrong category on that by accident last night, so sorry about that.

I wrote it after the game from a craptastic bar in SJC as I waited for my plane — it was delayed 3 hours because of weather in Chicago.

I did work on a diagram for upgrading the graph server architecture last night, so I’ll offer that as a nugget of truce to planet.mozilla.org readers:

Goal is to make the graph server snappier. Comments welcome.

Stuart J. Johnston, over at PC World's Bugs and Fixes column, does a fabulous job confusing and unnecessarily alarming Firefox users, while at the same time conflating the valuable contributions being made by the ethical security researcher community with the malicious activities of "bad guy" hackers.

That's quite an accomplishment in just 500 words.

Getting those column inches hammered out every month can be hard work, but when the obvious result of an article is that readers will walk away less informed than before they read it, it's time to consider a different approach or a different topic.

This particular piece should never have made it off of the author's laptop and definitely shouldn't have made it past an editor's desk. PC World, IDG, and Stuart Johnston are all better than this, and their readers deserve more.

Many people are switching from Internet Explorer to alternative browsers such as Firefox and Safari. Though that might make them feel more secure, the shift has also opened new doors for bad guys.

More users may make a particular program a more inviting attack target for the bad guys, but in the case of Mozilla's Firefox, more users and our open and responsive process also makes it a more inviting research target for the good guys. Yep, there are good guy hackers too, and it's those good guys working in concert with Mozilla developers that are finding and fixing the vast majority of Firefox security issues.

So, in the case of Mozilla's Firefox, more users may actually be helping to shut the door on bad guys, rather than, as Mr. Johnston claims, opening new doors for them.

Case in point: We have no IE bugs to report this month, but both Firefox and Safari have been hit hard.

If by "hit hard" the article means to communicate something like "this month security researchers and developers contributing to Mozilla's open source Firefox project have found and deployed fixes for several new potential vulnerabilities, shoring up Firefox's defense against malicious hackers and denying them new attack vectors," then sure, Firefox was "hit hard."

Unfortunately, I don't think that's what the article was implying.

So forget the idea that just because you've switched to a new browser, you're magically safer.

There's no magic here at all. Firefox has a long track record of being more secure by design, more responsive to security issues, and less often targeted by bad guys than I.E. Taken together, those factors really do mean that because you've switched from I.E. to Firefox, you are safer -- no "magically" about it.

You may be for a time, but to stay safe with any software, you need to keep current with fixes.

And here we have the only line in this entire article that could conceivably help users. Unfortunately, it's not in a context where it's likely to be taken that way.

This is one more area where just a bit more research would have resulted in an entirely different article or no article at all -- depending on the author's motivations.

With Firefox, users don't have to worry nearly as much about keeping current with fixes as they do with other browsers, I.E. in particular.

Firefox has the best record in the industry, not just for finding and fixing issues quicker, but for getting those fixes in the hands of users faster.

Thanks to Firefox's well designed update mechanism, 95% or more of our users are automatically updated to the latest secure version in less than a week.

That kind of information could have provided the context to make that one informative point actually useful to readers.

In a somewhat dubious recognition of Firefox's growing popularity, hackers have focused their attention on it, leading to a rash of newly discovered holes.

If by "hackers" the article is referring to Mozilla developers and ethical security researchers who work together to keep Firefox users safe, then sure, "hackers focused their attention on Firefox."

If, however, as it appears from the overall tone of the article, it means to suggest that Firefox users should be alarmed and worried that bad guys have discovered a bunch of new Firefox holes and users are in great danger, then no, not so much.

In an actual attack--neither the Safari nor the Firefox bugs have elicited one so far--a bad guy could take over your PC or steal your navigation history.

In an actual attack, Firefox users would be protected because the vulnerabilities were discovered and fixed by the good guys and rapidly deployed to virtually all Firefox users weeks before Mr. Johnston's article hit the Web.

With this paragraph, we also finally get the buried lede and the admission that should have killed this entire story. Bad guys are not attacking Firefox (nor, apparently Safari,) and all of the FUD from the previous four paragraphs falls apart by the author's own admission.

A month ago, with the help of some amazing security researchers, Mozilla found and fixed half a dozen problems and deployed those fixes to pretty much every Firefox user out there. In the time between those discoveries and the appearance of Mr Johnston's article, there have been no reports of any of those flaws being used to attempt attacks against Firefox users -- attacks that would fail thanks to the Mozilla developers and the security researchers that Mr. Johnston calls "bad guys" and "hackers."

What a waste and what a shame for those people who, having read this article, are now more alarmed and less informed about security than they were before.

Security is a complex area and it takes real effort to learn about all of the factors that interact in determining security outcomes. It simply doesn't lend itself to quick bean counting analysis or casual headline-skimming research.

It's also a critically important topic because a fundamental necessity of a safer Internet is that users have a clear understanding of how it actually works.

Security-related articles and headlines constructed with over-simplicifcations, fear-mongering, and out-right misrepresentations, not only don't inform readers, they actually slow the progress to a more secure Internet.

In a recent bug fligtar was nice enough to run some stats for me on platform strings passed in extensions.update.url via the %APP_OS% client variable in Firefox. He found some interesting results:

WINNT
Darwin
Linux
linux-gnu
SunOS
FreeBSD
linux
winnt
darwin
OS2
OpenBSD
NetBSD
BeOS
DragonFly
IRIX64
AIX
HP-UX
NTO
solaris2.10
OSF1
penis

Fixing bug 407211 will be a long and hard process, but I think I’ll be able to handle it.

This was just too good to pass up.

Halfway in the Digital Age at the Daily WTF

UPDATE: Gerv apparently found this a couple days ahead of me and I’m a victim of being behind on my bugmail.  See bug 430508.

Paul Kim, the architect of Mozilla's global marketing and PR program, explains the foundations of the upcoming Firefox 3 launch.

Best part? Yeah, the parties!

Actually, I shouldn't risk trivializing it. There's just an amazing amount of work that goes into a product launch of this scale. It's really so much more than anyone imagines it to be and there's always so much more that we could do with more community participation.

So head over to Paul's blog, read up on what's in the pipe, and then find a way to get involved. We're going to fly past the 200 million users mark this year and Firefox 3 is gonna be the vehicle. Climb aboard!

One of my very favorite sources for Mozilla news and reviews, MozillaLinks, just got a facelift and it looks great.

Keep up the awesome work, Percy!

The AwesomeBar keeps getting awesomer all the time.

We’re nearing the finish line for Firefox 3, so it’s a good time to share our plans for the launch marketing that will introduce Firefox 3 to the world.

As with every previous major version launch, we will be utilizing a combination of traditional marketing and PR programs with community and grassroots outreach. This combination has served us well over the past four years to drive adoption to over 160 million people worldwide, build the Firefox brand, and provide meaningful opportunities for participation at launch.

Core launch principles
It all starts with a great product.

Firefox 3 is the strongest version of Firefox we’ve ever built. It contains over 14,000 improvements from Firefox 2 and reflects three years of work by Mozilla project developers. Active use of Firefox 3 beta versions is roughly 4x what we saw at peak for Firefox 2 betas, and, most importantly, beta testers are sticking with Firefox 3, indicating it is already delivering a great daily experience.

Reflecting the strength of Firefox 3 across multiple dimensions - performance, user experience, security, customization, and web standards support - the theme for the Firefox 3 launch is: “A No Compromises Web Experience”. The core idea we will communicate in our launch marketing is that no other web browser matches Firefox 3 and the quality of the experience it delivers against these key measures.

The growth of Firefox is being supported by an active and vocal community of end users. We aim to give our community new tools and more importantly new reasons to continue the word of mouth referrals that have amplified awareness of Firefox.

Firefox is global. We will be shipping with over 40 language versions on launch day, and our launch will touch as many parts of the world as we can reach.

Our goals are simple: to accelerate the growth of Firefox and drive significant new user adoption beginning with the launch of Firefox 3 and continuing through the lifecycle of this release.

Driving awareness for Firefox 3
Press outreach: We will be conducting worldwide press tours for Firefox 3 in the US, UK, Germany, France, Spain, Italy, Poland, China, Japan and Brazil. We’ll meet with technology and business reporters in each country to present Firefox 3 and showcase new features that make their debut with this release.

Viral marketing: We have been working on a global, participatory marketing program that we will announce very soon. We wanted to give Firefox users all over the world a fun, easy way to join in on the launch and have developed a program that we think meets this objective well. More details when we unveil this program on spreadfirefox.com.

Search engine marketing: We will shift our ongoing search engine marketing program to focus exclusively on the launch in the weeks just prior to final release of Firefox 3. We’ll also be rolling out new search engine marketing campaigns in the UK, France and Germany (to complement our campaigns in the US and Japan).

Partner program: We are working with a group of add-on partners for the first time ever at launch to highlight the strength of the Firefox add-ons ecosystem. Partners will spread the word about Firefox 3 to users of their add-ons and will also work with us on press outreach.

Helping people get Firefox 3
All of our awareness generating activity is intended to drive visits to getfirefox.com, which serves over 85% of the cumulative downloads for Firefox. We’ve made major enhancements to the visual design and content on mozilla.com in preparation for the launch.

Website redesign: Mozilla.com has been completely overhauled for Firefox 3. New imagery and messaging evolves the Firefox brand while remaining true to the straightforward, human voice we’ve established.

Screencasts and tutorials: We are producing several screencasts and working on a project to invite community participation in creating more, to show people what’s new and useful in Firefox 3. We’ve also developed several quick and easy tutorials that will go live with the new site at launch.

But wait, there’s more!
Firefox 3 Parties: Continuing a hallowed tradition here at Mozilla, we are updating our Firefox Party Planner with the goal of topping the hundreds of parties held all over the world at the launch of Firefox 2. As usual, we will send party hosts a Firefox party kit upon registration.

Everyone on the extended Mozilla marketing team is excited about this launch, and we can’t wait to kick off what is shaping up to be the strongest Firefox release yet. Expect to hear more about the launch in the coming weeks on Planet Mozilla from the members of the team.

ShareThis

Finally, a bug-tracking system for everything. The priorities, severities, products, and components are great.

Deb’s excellent post about Firefox 3’s bookmarking system hit Digg today, on our shared server, which reminded me that I needed to install some WordPress caching software.

No sweat; wp-super-cache, I thank you.

Remember those shirt we promised to add-on developers for updating to Firefox 3? Looks like people are starting to get them…

Here's a another great example of why it's not only really important to identify, diagnose, and fix security issues quickly, but equally important to get those fixes into the hands of users quickly.

I predict that if it's not already the case today, that it will soon be the case that unpatched holes in mainstream browsers (where a fix does exist but isn't installed) will be responsible for more real-world security problems than holes that remain unfixed.

The number of browsers out there has gotten to be so huge that you don't need to exploit a large percentage of them to do real damage. With about a billion IE installs out there, and probably a similar number of flash plug-in installs, you only need a few percent that haven't yet updated to compromise a whole lot of machines.

Even worse, the time it takes to develop an attack for a patched flaw is approaching zero much faster than Microsoft's or Adobe's time to deploy is.

This is an area where Firefox really excels. Our update mechanism can move the majority of Firefox users from an insecure version to the new secured version in just a few days. At last measure, I calculated that it took us just 5 days to get over 90% of our users updated.

While that's pretty amazing for updating hundreds of millions of users, I think that we're going to have to find ways to make it even more efficient. Right now, for example, the update check only happens when Firefox is active and it only happens once per day. Those might need to change if we're going to make dramatic improvements on the already fast turnover.

A couple of days ago, while looking at the WebWare 100 winners, I noticed that the editor called out Maxthon for sort of cheating, they were driving traffic to the voting by incorporating a pop-up advertising the contest right in the Maxthon browser. Today there's a post up at the Maxthon blog bragging about how effective it was.

That got me thinking about what would have happened if Mozilla used that kind of tactic. Can you imagine the hardware meltdown at c|net that would have resulted from 170 million Firefox users all being directed to hit their WebWare voting site?

I don't really know much about internet loads, but I've seen pretty decent sites get taken down by the digg or slashdot effect which probably only amounts to hundreds, maybe a thousand hits per minute? Now, c|net's not some shared hosting $10/mo solution, but what happens when it's tens of thousands or hundreds of thousands of hits per minute?

Then again, that's all hypothetical for a couple of reasons. First, we wouldn't get in our users face like that for anything less than a critical security update (where we do actually throw a pop-up advertising the availability of the update.) Rallying the community that opts in to visiting Spread Firefox is completely reasonable. Interrupting 170 million Firefox users for a web poll is not. Second, I think most people would consider that cheating and I think we'd mostly all agree.

What do you think? Should Firefox win online polls at all costs ;-)

(Just kidding. I don't actually expect an answer there.)

Finally, while I think it's cool that Firefox got enough votes to be listed as a top 100 application (and apparently registered in the top total 10 vote-getters,) does it really say anything interesting when pretty much all of the browsers made it into the same top 100. It's pretty awesome that c|net was able to get nearly 2 million people to vote and to narrow down from many thousands of apps and sites to 100, but without some kind of public ranking within that 100 or at least within the various categories, it doesn't really inform people as much as it lets all the top players claim "winning" status.

I've linked to several great blog posts on Firefox 3 features lately, but there's one piece of an older feature that doesn't get enough credit. I got a reminder this morning when Firefox crashed (a flash bug that may have just been fixed,) while I was composing a rather long webmail message and just this evening read this blog post.

If you haven't needed to experience Firefox's crash recovery because you're never crashing, great. If you have, though, it sure is nice that it saves your work.

Wow.

About half a dozen vocal advocates of the Firefox 2 status quo, out of a pool of more than 3 million people using the improved feature in Firefox 3 betas, managed to stall a pretty cool step forward for how the Download Manager presents its much improved value to users. Maybe we can make that progress in 3.next.

Reminds me of some of the dysfunction of pre-Firefox days.

Bonus points to the several seriously f'n rude commenters in the bug. You do us all so proud. (And, to continue the sarcasm, it's great to see that our Bugzilla etiquette guidelines are being so well enforced.

It's a good thing for several of those folks that I'm not living in Bugzilla any more or they'd have been zeroed out of the system pretty f'n fast.)

Somewhat related, I'm sure glad the AwesomeBar and the bulk of places survived their time in Bugzilla. It's sobering to be reminded by what a thin thread feature progress actually hangs.

Hot off the success of her recent AwesomeBar is awesome post, Deb's got even more reason to love (or anticipate) Firefox 3.

I won't spoil it with any of my own commentary this time. Just head over to dria.org and read her latest post, Firefox 3 Bookmarks (My god, it’s full of stars…).

OK. I can't not say something :-) . I'll keep it short.

It would be an understatement to say that, like Deb, I've never been a big fan of traditional browser bookmarks. To be more blunt, I've always hated them. They fail in just about every way at helping me accomplish what I want to accomplish -- quickly and easily getting back to a page I've visited before.

With the exception of a few bookmarks on my bookmarks toolbar and a couple others called up by their typed shortcut (bookmark keyword,) I just stopped using bookmarks. If it didn't fit in my toolbar or the limited space I have in the part of my brain that stores shortcut names, I just didn't save it. I found it more convenient to keep a super-long browsing history and just search through there when I wanted to return to any of the sites that didn't fit in those two very finite spaces.

That was before Firefox 3.

Thanks to all the great new features that Deb describes, now I'm bookmarking the hell out of the Web and I'm never more than a couple of clicks or keystrokes away from all the content I want to revisit.

The Thunderbird folks are organizing a bug day this Thursday, 24 April 2008. The schedule is located here. Generally, feel free to pop by outside of the sessions as well, some experienced folks should be around to help you.

The focus of this bug day is found here.

How?

Triaging is easy! You don't have to be able to understand computer languages in order to triage most bugs.

You just have to try and reproduce the bug by following the steps written in the report. Add a comment stating whether the bug still applies in the latest supported version of Thunderbird 2 (2.0.0.12), or in the trunk nightlies (3.0a1pre) for the more adventurous.

Thunderbird 2.0.0.12 builds:

Official Windows installer

Official Linux (i686)

Official Mac (Universal binary)

Please drop by #bugday and help us get our bug numbers down; we need your help! First timers and experienced triagers welcome.

I will be available throughout all three the last two timeslots to assist anyone who wants to contribute. (My nick is "nth10sd") Several experienced folks will be there to assist as well.

The results of the bug day will be posted to Mozilla Wiki.