Log Viewer showing dates in a tree

Get your copy of Instantbird 1.4, hot off the presses! We’ve made a lot of improvements (for full details, see the release notes):

• Twitter:
• The character counter should now be correct when tweeting links.
• Twitter now uses the v1.1 API, this will allow Twitter to continue working past June 11th, 2013 (when the v1.0 API is disabled).
• Invalid/self-signed/out-of-date SSL certificates can now be easily overridden for IRC accounts.
• Logs are now organized by the date they were created, and smartly folded to easily find recent chats.

As we stated during the Instantbird 1.3 release, this version now requires Mac OS X 10.6 (Snow Leopard). Instantbird 1.4 is based off Mozilla 20 and libpurple 2.10.7, the newest versions available.

You might be asking “What’s next?” for Instantbird; we will be participating in Google Summer of Code 2013 (again through Mozilla). Through this and our other volunteers, we’ll continue improving Instantbird to make it a chat program you love to use. Hopefully we can integrate some cool new features from this year’s Google Summer of Code and finish integrating the Account Import Wizard from Google Summer of Code 2012! As always, if you see any issues, please file bugs!

In grad school, I remember a conversation across the campus green with an visiting psychologist from Harvard.  I don’t remember much about the conversation except that he introduced me to Isaiah Berlin’s notion of the Hedgehog and the Fox, and correctly pegged me as a Fox.  I think I was a bit offended at the simplification, but time has proven him right.  I’m certainly no hedgehog.

I got into a silly argument on twitter last night, about whether my looking to hire someone who I labeled (as job descriptions make us do) a “Coding Designer” was not just foolish (I’d seen the Unicorn references in my tweetstream already) but apparently a bad idea, because, so the ultra-simplified argument goes, you somehow can’t be both.  And so I’ll use the energy to rant a bit about what seem to be prevailing attitudes around titleism and narrow definitions of “professionalism”.

We all need to define ourselves to others. It helps us be understood, and hopefully valued.  Labels can be useful for that. We also, even more, like to label others.  It helps us simplify our approach to them.  If I can find a label for you, then I can rely on a prioris about how people with that label tend to think and behave, and I don’t need to actually get to know you too much.  The more people we interact with, the more important these shortcuts are.  Some roles are particularly subject to that (Recruiters, VCs, politicians, etc. — people who routinely talk to dozens if not hundreds of people a day).  And the best at these roles are those who use a different labeling system than their peers.  Recruiters who see the latent ambition or genius in a shy candidate; VCs who see the determination behind a stutter, or, conversely, the lack of self-confidence behind the bravado, etc.

Labels are useful and practical in the short term.  And I don’t know how one could run a large HR department without them.  But we should be careful to not take them too seriously, as in the long term, they can hurt. They hurt because people, especially interesting, worth-getting-to-know people, are much more subtle, complicated, confusing and hard to categorize creatures.  Whether you take the label too seriously when thinking about others (e.g., refuse to see the valid opinion about a design expressed by a non-Designer) or about yourself (and limit your impact on the world because “oh, that’s not something that a mere ____ like me could say/do”), you’re not getting the most out of anyone involved.

As I write this, I realize that I feel quite strongly about this topic.  Part of it is probably because I grew up in an educational system, which at least then believed way too much in labeling people and determining their fate based on that label.  Much waste ensued.  Part of it is probably because I can’t for the life of me figure out what my label should be, and if I can’t, then that must be bad. I’ve had a range of professional labels, from scientist to engineer, architect, team lead, vice president, CTO, CEO, blah blah blah.  I’ve been called a designer, strategist, entrepreneur, boss, blah blah blah. None of those words will, I hope, be in my epitaph.  And so I get cranky on twitter at night, because if there are people who strive to be both excellent at design and at coding, then by golly we should encourage them.

Titles are a poor approximation of a professional ideal, and a profession is a poor approximation of a human’s breadth, contributions, and talents.  Embrace your inner fox, and if you happen to have both design and coding skills, can see a problem, conjure up a solution, prototype it, welcome challenges to your idea from peers, data, and users, apply.

As Digital Preservation is part of the agenda of the US Library of Congress, they're doing a workshop on Software Preservation next week, and Mozilla was invited as an expert group. Otto de Voogd and myself are in the delegation going there (I'll be roughly in the Washington, DC, area from Saturday until June 2) for Mozilla - and the text below is a guest post by Otto with questions that we would like some feedback on so we can represent the Mozilla community as well as possible:



On the 20th and 21st of May the Library of Congress holds a workshop on the topic of preserving software.
Otto de Voogd and Robert Kaiser will be representing Mozilla, putting forward our viewpoint as custodians of a codebase with a significant heritage and importance.

Many questions and thoughts arise. Here's an overview of ours; we look forward to feedback.


- Should archivists keep source codes or executables or both?

Executables and source code are both valuable. Executables are valuable because the source code is sometimes not available, or perhaps the build tools are not, and setting up a build environment for older code can be a difficult and complex thing.

Source is valuable to determine how a program works. It also makes it possible to reuse code and algorithms, especially, but not only, in the case of open source software.


- Preserving documentation.

Preserving documentation that goes with software, seems logical.
Would this need to go as far as preserving discussion threads and entries in bug trackers?


- Preserving environments/platforms.

It seems obvious that without preserving an environment in which the software can run, it is going to be impossible to experience the software.
Preserving such an environment should therefor be part of the software preservation effort.

To avoid the physical constraints imposed by preserving old hardware (which would be a preservation effort in its own right), a solution would be to build virtual machines and emulators.
As hardware capacity constantly grows, running virtual versions of older hardware should generally be feasible.

To fully recreate an environment we'd also need to preserve the operating systems and other software tools that the preserved software needs to run.
Those being software themselves would logical already be included in any software preservation effort.

Preserving documentation concerning environments, would also be required.
To build virtual machines and emulators it would be helpful for hardware makers to make technical specifications available. One could envision this to become a legal requirement at least for older hardware.

Can we imagine a world where web based emulators would allow an online digital library to serve users worldwide? Users who would be able to run old software in emulators running in their browsers...


- Is everything worth preserving, if not how does one go about selecting what is worth preserving?

Does one need to preserve every version of software, just the last version or all major releases? What about preserving software that has not spread widely. Would there be some threshold, or some other criteria?


- How does one index software and search the library?

There will be a need to gather meta data about software and the preservation of documentation as we already mentioned. This meta data and documentation could serve to populate an index enabling for instance the search for particular features.


- Can software preservation help in making code reusable?

If there are good ways to actually find relevant and useful code, this could lead to more reuse not only of actual code, but also of algorithms and concepts.
It may also become a valuable source for students who wish to learn about actual implementations of software solutions.

At the very least a minimum of meta data, such publication dates, copyright owners and licenses should be available to determine how certain code can be reused.
In particular for open source software we believe that software libraries should strive make it available without restrictions.


- Preserving data formats.

The software preservation effort should also include an effort to preserve data formats. Including technical descriptions of those formats and the tools to read, write and edit those formats.


- Can software preservation help in the discovery of prior art?

We believe it can, and as such preserving old code could be a great tool in preventing the repatenting of existing software concepts.

Of course we believe that software patents shouldn't exist in the first place, as software is already covered by copyrights, but at the very least prior art is a good avenue to prevent some of the worst abuse of software patents.


- How do copyrights affect software libraries?

A lot of software is licensed to be used on a particular piece of hardware or only available via subscription. How does this affect software libraries? Should there be exceptions like there are for traditional libraries?

In the life cycle of software, the commercially exploitable time is limited, likely anything older than 10 years no longer has any commercial value.
Maybe copyrights on software should be significantly reduced to something like 10 years, which is more than enough to cover the commercially exploitable timeframe of the software life cycle.

Such a limit would greatly enhance the work of software libraries, increasing availability and ease of access as well as removing a lot of the red tape involving requests for permission to keep copies.


- What about software as a service?

And what about software as a service, where neither the source code nor the executables are ever published? How can something like Gmail be preserved, when neither the service's code nor the environment is available to the public?


- Preserving "illegal" or cracked copies?

What if a copy of a piece of software comes from an illegal source? A cracked version with modifications maybe? They have value in themselves as they are a cultural expression.

What if such an illegal copy is the only copy still available? Would it make sense to preserve that too?

Hello Folks. If you have been using Lightning 2.3b1 with a localized version of Thunderbird, you probably had troubles with undefined entities. This happened due to a glitch with the Mozilla localization dashboard, the wrong changeset was used.

I have just uploaded Lightning 2.3b2, which should fix the issue. As always, you can download beta versions from the addons.mozilla.org site in the “Developer Channel” box. If you have previously installed a beta, you should get the update via automatic updates.

https://addons.mozilla.org/en-US/thunderbird/addon/lightning/#install-beta

The OpenStreetMap project has launched an all-in-JavaScript map editor called "iD" this week:



While we at Mozilla know you can do a lot of good things in JS these days - after all, we're even launching our own phone OS building fully on HTML+JS, and we have been using more and more JS code to power key functionality in our browsers and other products over the years - it's great to see that complex things like editing maps can be done fully in JS and available for all platforms now, while previously it took proprietary and availability-limited technologies like Flash or Java to do the same thing.

Great work, OpenStreetMap guys!


(And yes, as a contributor to OpenStreetMap and even OSMF member, I am biased, but free and open map data on the web fits Mozilla philosophy pretty well anyhow...)

Among the build systems peer, I am very much a newcomer. Despite working with Thunderbird for over 5 years, I've only grown to understand the comm-central build system in gory detail in the past year. Most of my work before then was in trying to get random projects working; understanding it more thoroughly is a result of attempting to eliminate the need for comm-central to maintain its own build system. The goal of moving our build system description to a series of moz.build files has made this task much more urgent.

At a high level, the core of the comm-central build system is not a single build system but rather three copies of the same build system. In simple terms, there's a matrix on two accesses: which repository does the configuration of code (whose config.status invokes it), and which repository does the build (whose rules.mk is used). Most code is configured and built by mozilla-central. That comm-central code which is linked into libxul is configured by mozilla-central but built by comm-central. tier_app is configured and built by comm-central. This matrix of possibilities causes interesting bugs—like the bustage caused by the XPIDLSRCS migration, or issues I'm facing working with xpcshell manifests—but it is probably possible to make all code get configured by mozilla-central and eliminate several issues for once and all.

With that in mind, here is a step-by-step look at how the amorphous monster that is the comm-central build system works:

python client.py checkout

And comm-central starts with a step that is unknown in mozilla-central. Back when everyone was in CVS, the process of building started with "check out client.mk from the server, set up your mozconfig, and then run make -f client.mk checkout." The checkout would download exactly the directories needed to build the program you were trying to build. When mozilla-central moved to Mercurial, the only external projects in the tree that Firefox used were NSPR and NSS, both of which were set up to pull from a specific revision. The decision was made to import NSPR and NSS as snapshots on a regular basis, so there was no need for the everyday user to use this feature. Thunderbird, on the other hand, pulled in the LDAP code externally, as well as mozilla-central, while SeaMonkey also pulls in the DOM inspector, Venkman, and Chatzilla as extensions. Importing a snapshot was not a tenable option for mozilla-central, as it updates at an aggressive rate, so the functionality of checkout was ported to comm-central in a replacement python fashion.

./configure [comm-central]

The general purpose of configure is to discover the build system and enable or disable components based on options specified by the user. This results in a long list of variables which is read in by the build system. Recently, I changed the script to eliminate the need to port changes from mozilla-central. Instead, this script reads in a few variables and tweaks them slightly to produce a modified command line to call mozilla-central's configure...

./configure [mozilla-central]

... which does all the hard work. There are hooks in the configure script here to run a few extra commands for comm-central's need (primarily adding a few variables and configuring LDAP). This is done by running a bit of m4 over another file and invoking that as a shell script; the m4 is largely to make it look and feel "like" autoconf. At the end of the line, this dumps out all of the variables to a file called config.status; how these get configured in the script is not interesting.

./config.status [mozilla/comm-central]

But config.status is. At this point, we enter the mozbuild world and things become very insane; failure to appreciate what goes on here is a very good way to cause extended bustage for comm-central. The mozbuild code essentially starts at a directory and exhaustively walks it to build a map of all the code. One of the tasks of comm-central's configure is to alert mozbuild to the fact that some of our files use a different build system. We, however, also carefully hide some of our files from mozbuild, so we run another copy of config.status again to add in some more files (tier_app, in short). This results in our code having two different notions of how our build system is split, and was never designed that way. Originally, mozilla-central had no knowledge of the existence of comm-central, but some changes made in the Firefox 4 timeframe suddenly required Thunderbird and SeaMonkey to link all of the mailnews code into libxul, which forced this contorted process to come about.

make

Now that all of the Makefiles have bee generated, building can begin. The first directory entered is the top of comm-central, which proceeds to immediately make all of mozilla-central. How mozilla-central builds itself is perhaps an interesting discussion, but not for this article. The important part is that partway through building, mozilla-central will be told to make ../mailnews (or one of the other few directories). Under recursive make, the only way to "tell" which build system is being used is by the directory that the $(DEPTH) variable is pointing to, since $(DEPTH)/config/config.mk and $(DEPTH)/config/rules/mk are the files included to get the necessary rules. Since mozbuild was informed very early on that comm-central is special, the variables it points to in comm-central are different from those in mozilla-central—and thus comm-central's files are all invariably built with the comm-central build system despite being built from mozilla-central.

However, this is not true of all files. Some of the files, like the chat directory are never mentioned to mozilla-central. Thus, after the comm-central top-level build completes building mozilla-central, it proceeds to do a full build under what it thinks is the complete build system. It is here that later hacks to get things like xpcshell tests working correctly are done. Glossed over in this discussion is the fun process of tiers and other dependency voodoo tricks for a recursive make.

The future

With all of the changes going on, this guide is going to become obsolete quickly. I'm experimenting with eliminating one of our three build system clones by making all comm-central code get configured by mozilla-central, so that mozbuild gets a truly global view of what's going on—which would help not break comm-central for things like eliminating the master xpcshell manifest, or compiling IDLs in parallel. The long-term goal, of course, is to eliminate the ersatz comm-central build system altogether, although the final setup of how that build system works out is still not fully clear, as I'm still in the phase of "get it working when I symlink everything everywhere."

Thunderbird-specific: (21)

• Fixed: 68784 – when sending mail, should first check “no recipient”, then “no subject” (it’s currently the other way round)
• Fixed: 308690 – No confirmation prompt when force-deleting messages with SHIFT+DEL (currently no protection against accidental permanent dataloss)
• Fixed: 431217 – Send button should be disabled until we have a recipient
• Fixed: 507103 – Composition’s “Save” button remembers last “Save as” choice (draft, template, or file), but no indication of current choice in dropdown menu (menuitems should be type=”radio”)
• Fixed: 810763 – create test file to check proper handling/rejection of certain values input into the Account manager
• Fixed: 813725 – Top of RSS item viewing window frozen
• Fixed: 814956 – AppMenu button on Mail Toolbar of standalone message window does not work
• Fixed: 816414 – Changed UX / performance issue with “Automatically mark messages as read” “Immediately on display” and keyboard shortcut “N” on RSS feeds
• Fixed: 846551 – The unread count on the chat toolbar button is ugly and unreadable on a Mac retina screen
• Fixed: 847259 – (Linux) drag and drop rss feed link from browser to folderpane does nothing
• Fixed: 851173 – Can’t change encoding for e-mails in TB17 using AppMenu button
• Fixed: 855057 – handle account name that is a substring of another one properly in the activity manager
• Fixed: 856432 – Modernize the New Mail alert appearance
• Fixed: 856451 – Make the New Mail alert show time easy adjustable
• Fixed: 856456 – Prompts to save unmodified message forward draft (commit in bug 762594 not complete fix)
• Fixed: 859287 – After the toolbar customization dialog is used, the “Get Mail” pull down does not display full width until TB is restarted.
• Fixed: 860093 – Regression from Bug 824150: toolbox has no method getElementById()
• Fixed: 860406 – When using Personas on Mac, the title bar is overlaid by the tab bar
• Fixed: 861867 – Add new Toolbar Icons for Thunderbird.
• Fixed: 863231 – Send button not working properly after Bug 431217, when filling recipients via Contacts sidebar
• Fixed: 866498 – Radio group for Main Menu Bar->View->Feed Message Body As-> and Radio group for App Menu-> View->Feed message Body As-> are not in sync with each other

MailNews Core-specific: (20)

• Fixed: 523796 – Eml file content change sending it as an attached file (if there is no [CRLF] at end of .eml file, Tb tries to send in Base64, then bug 326303 occurs)
• Fixed: 745919 – TB 11.0.forwarding plain-text (non-MIME) emails creates empty “Attached Message Part” even when forward messages is set Inline, if no Content-Type header, no parameter in Content-Type:.
• Fixed: 810675 – do not needlessly preprocess some mail/ files
• Fixed: 825012 – Expose methods to insert/remove indices in the m_keys array in msgDBView
• Fixed: 832034 – support non-IMAP async folder create types in processNextBatch of mailWindowOverlay.js
• Fixed: 833971 – LDAP password requested for each lookup even if password is saved (also can’t save it again after removal)
• Fixed: 837409 – crash [@ nsImapMailFolder::AddMoveResultPseudoKey(unsigned int)], [@ nsImapMailFolder::AddMoveResultPseudoKey] (Mac)
• Fixed: 845187 – JavaScript interpreter encounters an uninitialized memory from XPCOM interface (thunderbird)
• Fixed: 846540 – Emasculate comm-central/configure.in
• Fixed: 851275 – show size on disk for newsgroup folders
• Fixed: 854536 – Remove GRE_MODULE from Makefile.in’s (port bug 852534 and rules.mk of bug 817076)
• Fixed: 855754 – Pass current nsIURI to PGP/MIME proxy object
• Fixed: 856304 – remove some obsolete constructs in /mailnews
• Fixed: 856506 – crash in nsSmtpProtocol when parsing IDN
• Fixed: 856914 – Add a mail services C++ helper
• Fixed: 859068 – Cannot create or amend mailling lists in the address book
• Fixed: 860966 – Compile failure in msgMapiImp.cpp with Visual Studio 2012
• Fixed: 862757 – Permanent Orange: TEST-UNEXPECTED-FAIL | test_detectAttachmentCharset.js | UTF-16 == UTF-16LE – See following stack:
• Fixed: 864256 – Build failure in nsMsgStatusFeedback.cpp: “error: ‘class nsIXULBrowserWindow’ has no member named ‘SetJSDefaultStatus’”
• Fixed: 866412 – Build failure: cannot convert from ‘already_AddRefed<T>’ to ‘nsIAtom *’

Official Windows, Official Windows installer

Official Linux (i686), Official Linux (x86_64) (2013-04-29 build)

Official Mac

Common (excluding Website bugs)-specific: (15)

• Fixed: 374973 – multiweek/month view jumps to another week when (de)selecting ‘tasks in view’ from context menu
• Fixed: 479674 – Don’t include toolbar.css in application chrome
• Fixed: 727434 – Import Calendar.CSV files doesn’t work for Lightning calendar add-on.
• Fixed: 857155 – Test beta/release runs with Thunderbird infrastructure in staging area
• Fixed: 861620 – Improve test coverage in backend components
• Fixed: 861644 – Comptor for binary search is incorrect
• Fixed: 861646 – Missing nsIObserver on calIStartupService
• Fixed: 861647 – aMaxCount argument is not correctly taken into account
• Fixed: 861650 – calIPeriod implementation doesn’t correctly understand duration periods and forces utc
• Fixed: 861651 – Minor issues in calItemBase (immutability, properties, attachments)
• Fixed: 861652 – ics parser is missing listener, everything is called synchronously
• Fixed: 861654 – Fix repeatOffset and repeatDate in calAlarm
• Fixed: 861656 – Removing X-Parameters does not work
• Fixed: 861657 – Setting count = -1 in calRecurrenceRule causes isByCount = true
• Fixed: 864138 – Duplicated condition in switch statement (calXMLUtils.jsm)

Sunbird will no longer be actively developed by the Calendar team.

Official Windows

Official Linux (i686), Official Linux (x86_64)

Official Mac

On Februrary 20, 2004, the day before FOSDEM 2004, I apparently made slides of my talks public for the first time, putting the L10n status update for that weekend up on kairo.mozdev.org for everyone to refer to.

It was nice to have them up on the web both for people to look them up and for myself in case there would be a problem with my laptop and I'd not have my "master copy" available there. Also, having the contents managed in a version control system (cvs) meant that recovering from accidental changes would be easier and that I could easily sync copies between my desktop, laptop and the web.

Over the years, I added all slides from any presentations I made to that site, and even those from the years before - even that "outliner" for the 2002 talk about what "chrome" was all about (which I wrote up during the presentation right before it, and which was my only slide for that talk - things were a bit different on our first FOSDEM appearance then nowadays for sure).

Fast forward to today: mozdev.org isn't all that well-maintained any more, I never did put up much more than the slides there as I ended up putting all my content on my own server (and domain) anyhow, and cvs also probably isn't the state of the art any more for version control. In addition, I recently discovered how I could do decent auto-deploy of changes on my websites with git hooks on the repos that I host on my own server anyhow.

So, I did a simple "git cvsimport" on a cvs checkout of my slides, and now am using the resulting git repository to host all this right on my server at slides.kairo.at.

I also improved the index page from a pure list into a tabular format, of course using the common KaiRo.at color scheme and my logo, and exchanged the URLs on the slides themselves to point to the new domain. Note that I didn't do any other changes to the slides, so some of them might not be optimal in usability or design in current Firefox versions (I relied on SeaMonkey's site navigation bar a lot in the earlier slide sets, and I didn't add unprefixed versions of some CSS rules I used), but the newer ones should be as good as they can.

Now all I'm missing is to find a way to do a smart redirect (or URL rewrite) from mozdev to the new domain. Oh, and I need to get to creating slide sets for my Linuxwochen 2013 presentations...

With our new add-on, any mathematics contained in your conversations will be beautifully rendered using MathJax.

It’s rather nice to be able to discuss math using familiar LaTeX markup, but with the equations displayed properly. And of course, as LaTeX is text-based, this works for all protocols, and does not depend on your conversation partners also using Instantbird!

No configuration is necessary — to use this, you don’t even need to have TeX installed.

You can easily obtain the LaTeX source of any equation using the context menu. AMSmath symbols and environments (such as \begin{align}…\end{align}) are supported.

There are a few customization options — for example, you can choose to have displayed equations numbered automatically, to make them easier to refer to.

The add-on works with all Instantbird message styles, so you don’t have to change your favourite theme.

Get the add-on here!

Common (excluding Website bugs)-specific: (1)

• Fixed: 852496 – The image for the delete button in the Event/Task Edit Dialog is messed up.

Sunbird will no longer be actively developed by the Calendar team.

Official Windows (2013-04-03 build)

Official Linux (i686), Official Linux (x86_64)

Official Mac

Thunderbird-specific: (27)

• Fixed: 283425 – Add prefs UI for option to disable (don’t show) the new-message tray icon
• Fixed: 325777 – “Search messages” window has mislabeled button – “File” should be “Move”
• Fixed: 431439 – Add about:crashes button in prefs
• Fixed: 465731 – Don’t include toolbar.css in application chrome
• Fixed: 507622 – remove some usage of obsolete dialogOverlay.xul in mailnews/
• Fixed: 519252 – consider builder newsgroup link in a safer way
• Fixed: 599036 – Feeds that should open in a new window opens in a new tab.
• Fixed: 660211 – There is no way to save a custom message list column layout (as standard for new folders) nor apply columns to virtual folders or newsgroups
• Fixed: 781466 – Shortcut keys used to assign tags are not consistent with those shown in the Menu.
• Fixed: 804091 – IMAP account option “Synchronize the most recent” not saving correctly
• Fixed: 817329 – “this addon could not be installed because it appears to be corrupt” is quite invisible
• Fixed: 817468 – color of attachment bar with wide view layout different from other layouts
• Fixed: 824150 – Code cleanup in /mail/ and /mailnews/: Use new String methods like startsWith, endsWith, contains, remaining Services.jsm switches and querySelector use instead of NodeList calls
• Fixed: 824778 – Add bottom border to tab toolbar
• Fixed: 841996 – Permanent orange: TEST-UNEXPECTED-FAIL | test-plugin-crashing.js | test-plugin-crashing.js::test_crashed_plugin_notification_bar / test_crashed_plugin_notification_inline
• Fixed: 844599 – Implement Bug 842913 on comm-central (Rename winstripe->windows, pinstripe->osx, gnomestripe->linux)
• Fixed: 845509 – Checkmarks not shown on AppMenu menuitems
• Fixed: 845807 – Blue link text should be lighter by default.
• Fixed: 852461 – Remove growl support from comm-central
• Fixed: 852690 – Remaining conversion to mailServices.js in /mail/ and /mailnews/
• Fixed: 853135 – The Attachments menu belongs under the Message menu (port seamonkey bug 352696)
• Fixed: 853309 – Fix typo in comments and logs: |recieve| -> |receive|
• Fixed: 853926 – Grain texture is too light on Linux.
• Fixed: 855135 – Change link and signature colors in themes from hard-coded definitions to follow preferences
• Fixed: 856350 – new tag dialog stopped working
• Fixed: 857049 – Port Twitter API v1.1 from Instantbird to c-c
• Fixed: 857575 – Various UI complaints about the threadpane’s header.

MailNews Core-specific: (21)

• Fixed: 117878 – [meta] evaluate mailnews code for buffer overruns.
• Fixed: 326809 – modernize nsIMsgHeaderParser – |string| and |wstring| vs AString and AUTF8String
• Fixed: 448624 – Remove imap specific “Empty trash” confirmation dialog.
• Fixed: 465351 – Wrong message and reason reported with untrusted CA roots when signing email
• Fixed: 480843 – Implement memory reporter for mailnews
• Fixed: 514134 – usage of sprintf in Address book code
• Fixed: 544621 – Use or remove ‘#ifdef HAVE_PORT’ code
• Fixed: 688135 – crash [@ nsMsgDBFolder::CallFilterPlugins(nsIMsgWindow*, int*)]
• Fixed: 737519 – attachment1_body of nsProxySendRunnable will not be non-null terminated string.
• Fixed: 831993 – convert nsISupportsArray m_serversToGetNewMailFor variable from nsPop3IncomingServer.cpp to something better
• Fixed: 833399 – crash in nsImapOfflineTxn::UndoTransaction
• Fixed: 837643 – crash in nsMsgDatabase::ClearHdrCache
• Fixed: 838805 – remove some small occurrences of nsISupportsArray in mailnews
• Fixed: 847172 – sort entries in the “Trust junk mail headers set by” menulist
• Fixed: 848477 – Extensions are not allowed to use custom folders for mail storage
• Fixed: 851899 – fix some compiler warnings in mailnews/imap/src/nsImap*.cpp
• Fixed: 854162 – Should use nsImapMailFolder::HasMsgOffline() instead of checking for nsMsgMessageFlag::Offline in nsAutoSyncState.cpp
• Fixed: 855573 – Missing file(s): bin/components/layout_forms.xpt
• Fixed: 855631 – Get New Messages for all accounts does not work
• Fixed: 856478 – remove nsISupportsArray from mailnews/extensions/mailviews/src/nsMsgMailViewList.cpp
• Fixed: 857647 – Don’t show balloon notification on new mail if tray icon is disabled

Official Windows, Official Windows installer (2013-04-03 build)

Official Linux (i686), Official Linux (x86_64)

Official Mac

When running final tests for my latest patch queue, I discovered that someone has apparently added a new color to the repertoire: a hot pink. So I now present to you a snapshot of TBPL that uses all the colors except gray (running), gray (pending), and black (I've never seen this one):

This post is admittedly long overdue, but I kept wanting to delay this post until I actually had patches up for review. But I have the tendency to want to post nothing until I verify that the entire pipeline consisting of over 5,000 lines of changes is fully correct and documented. However, I'm now confident in all but roughly three of my major changes, so patch documentation and redistribution is (hopefully) all that remains before I start saturating all of the reviewers in Thunderbird with this code. An ironic thing to note is that these changes are actually largely a sidetrack from my original goal: I wanted to land my charset-conversion patch, but I first thought it would be helpful to test with nsIMimeConverter using the new method, which required me to implement header parsing, which is best tested with nsIMsgHeaderParser, which turns out to have needed very major changes.

As you might have gathered, I am getting ready to land a major set of changes. This set of changes is being tracked in bugs 790855, 842632, and 858337. These patches are implementing structured header parsing and emission, as well as RFC 2047 decoding and encoding. My goal still remains to land all of these changes by Thunderbird 24, reviewers permitting.

The first part of JSMime landed back in Thunderbird 21, so anyone using the betas is already using part of it. One of the small auxiliary interfaces (nsIMimeHeaders) was switched over to the JS implementation instead of libmime's implementation, as well as the ad-hoc ones used in our test suites. The currently pending changes would use JSMime for the other auxiliary interfaces, nsIMimeConverter (which does RFC 2047 processing) and nsIMsgHeaderParser (which does structured processing of the addressing headers). The changes to the latter are very much API-breaking, requiring me to audit and fix every single callsite in all of comm-central. On the plus side, thanks to my changes, I know I will incidentally be fixing several bugs such as quoting issues in the compose windows, a valgrind error in nsSmtpProtocol.cpp, or the space-in-2047-encoded-words issue.

It's not all the changes, although being able to outright remove 2000 lines of libmime is certainly a welcome change. The brunt of libmime remains the code that is related to the processing of email body parts into the final email display method, which is the next target of my patches and which I originally intended to fix before I got sidetracked. Getting sidetracked isn't altogether a bad thing, since, for the first time, it lets me identify things that can be done in parallel with this work.

A useful change I've identified that is even more invasive than everything else to date would be to alter our view of how message headers work. Right now, we tend to retrieve headers (from, say, nsIMsgDBHdr) as strings, where the consumer will use a standard API to reparse them before acting on their contents. A saner solution is to move the structured parsing into the retrieval APIs, by making an msgIStructuredHeaders interface, retrievable from nsIMsgDBHdr and nsIMsgCompFields from which you can manipulate headers in their structured form instead of their string from. It's even more useful on nsIMsgCompFields, where keeping things in structured form as long as possible is desirable (I particularly want to kill nsIMsgCompFields.splitRecipients as an API).

Another useful change is that our underlying parsing code can properly handle groups, which means we can start using groups to handle mailing lists in our code instead of…the mess we have now. The current implementation sticks mailing lists as individual addresses to be expanded by code in the middle of the compose sequence, which is fragile and suboptimal.

The last useful independent change I can think of is rewriting the addressing widget in the compose frontend to store things internally in a structured form instead of the MIME header kludge it currently uses; this kind of work could also be shared with the similar annoying mailing list editing UI.

As for myself, I will be working on the body part conversion process. I haven't yet finalized the API that extensions will get to use here, as I need to do a lot of playing around with the current implementation to see how flexible it is. The last two entry points into libmime, the stream converter and Gloda, will first be controlled by preference, so that I can land partially-working versions before I land everything that is necessary. My goal is to land a functionality-complete implementation by Thunderbird 31 (i.e., the next ESR branch after 24), so that I can remove the old implementation in Thunderbird 32, but that timescale may still be too aggressive.

It all started on March 31, 1998. Just a few days off from 15 years ago.

Netscape open-sourced the code to its "Communicator" Internet suite, using its own long-standing internal code name as a label for that project: Mozilla.

I always liked the sub-line of a lot of the marketing material for this time - under the Mozilla star/lizard logo and a huge-font "hack", the material said "This technology could fall into the right hands". And so it did, even if that took time. You can learn a lot about that time by watching the Code Rush movie, which is available under a Creative Commons license nowadays. And our "Chief Lizard Wrangler" and project leader Mitchell Baker also summarized a lot of the following history of Mozilla in a talk that was recorded a couple of years ago.

Just about a year later, in May 1999, so 14 years ago, I filed my first bug after I had downloaded one of the early experimental builds of the Mozilla suite, building on the brand-new Gecko rendering engine. This one and most I filed back then were rendering issues with that new engine, mostly with my pretty new and primitive first personal homepage I had set up on my university account. After some experiments with CSS-based theming of the Mozilla suite, I did some playing around with exchanging strings in the UI and translating them to German, just to see how this new "XUL" stuff worked. This ended up in my first contribution contact and me providing a first completely German-language build on January 1, 2000.

A few months after that, in May, I submitted my first patch to the Mozilla project, which was a website change, actually. But only weeks later, I created a bug and patch against the actual Mozilla code - in June of 2000, 13 years ago. And it would by far not be the last one, even though my contributions the that code were small for years, a fix for a UI file here, a build fix for L10n stuff there. My main contributions stayed in doing the German localization for the suite and in general L10n-related issues. Even when Firefox came along in 2004, I helped that 1.0 release with some localization-related issues, esp. around localized snippets for its Google-based and -hosted start page - and stayed with L10n for the full suite otherwise (while Kadir would do the German Firefox L10n). I wrote a post in 2007 about how I stumbled into my Mozilla career.

As Firefox became rapidly successful and took an increasingly large standing in the project and community, I stuck with the suite as I liked a more integrated experience of email and browser - and I liked the richer feature set that the suite had to offer (Firefox did cut out a lot of functionality in the beginning to be able to found its new, leaner and more consumer-friendly UI). When in March of 2005, it became clear that the suite was going into strict maintenance mode and be abandoned by the "official" Mozilla project, I joined the team that took over maintenance and development of that suite - once again using a long-standing internal code name for that: SeaMonkey. In all that project-forming process 8 years ago, I took over a lot of the organizational roles, so that the coders in our group could focus at the actual code, and eventually was credited as "project coordinator" within the project management group we call the "SeaMonkey Council".

When I founded my own business 7 years ago, in January of 2006, I was earning money in surprising ways, and trying to lead the SeaMonkey project into the future. We were just about to release SeaMonkey 1.0 and convince the first round of naysayers that we actually could have the suite running as a community project. In the next years, we did quite some interesting and good work on that software, and a lot of people were finally realizing that "we made it" when we could release a 2.0 version that was based on the same "new" toolkit that Firefox and Thunderbird were built upon, removing a lot of old, cruft code and replacing it with newer stuff, including the now common-place add-ons system and automated updates among a ton of other things. I would end up doing a number of the major porting jobs from Firefox to SeaMonkey, including the places-based history and bookmarks systems, the download manager (including a UI that was similar to the earlier suite style), and the OpenSearch system. With the Data Manager, I even contributed a completely new and (IMHO) pretty innovative component into SeaMonkey. In those times, I think I did more coding work (in JS, mostly) than ever before, perhaps with the exception of the PHP-based CBSM community and content management platform I had done before that.

The longer I was in the SeaMonkey project, the more I realized, though, that the innovation I would like to have seen around the suite wasn't really happening - all the innovation to the suite came from porting Firefox and Thunderbird features and/or code, and that often with significant delay. Not sure if anything other than the Data Manager actually was a genuine SeaMonkey innovation, and I only came up with that when trying to finally get some innovation going, back in 2010. I was more and more unsatisfied with the lack of progress and innovation and the incredible push-back we got on the mailing list on every try to actually do something new. In October of 2010, I took a flight to Mountain View, California, to meet up with Mitchell Baker and talk about the future of SeaMonkey - and I also mentioned how I wanted to be more on the front of innovation even though I seem to not manage to get the SeaMonkey community there. Not sure if it came out of this or was in the back of her head before, in one of those conversations I had with her, she asked me if I would like to work for Mozilla and Firefox. I said that this caught me by surprise but we should definitely keep that conversation going. Just after that I met then-Mozilla-CEO John Lilly, and he asked if Mitchell had offered me a job - just to make sure. As you can imagine, that got me thinking a lot more about that, and gave me the freedom to think outside SeaMonkey for my future. I was at the liberty to think about my personal priorities in more depth, and it became clear that the winds of change were clearly blowing through my life.

After some conversations with people at Mozilla, I decided I wanted to try a job there, and Chris Hofmann proposed my working on tracking crashes and stability, so I started contracting for Mozilla on the CrashKill team in February 2011, first half-time, finally full-time. So, 2 years ago, I opened a completely new chapter in my personal web story. Tracking crash statistics for our products - Firefox desktop, Firefox from Android, and now Firefox OS - and working with our employees and community to improve stability has turned out to be a more interesting job than I expected when I started. Knowing that my work actually helps thousands or even millions of people, who have a more stable Firefox because of what I do, is a quite high award. And I'm growing into a more managerial role, which is something I really appreciate. And I'm connected to all kinds of innovation going on at Mozilla: A lot of the new features landing (like new JIT compilers for JavaScript, WebRTC, etc.) need stability testing and we're tracking the crash reports from those, Firefox for Android needed a lot of stability work to become the best mobile browser out there - and with Firefox OS, I was even involved in how the crash reporting features and user experience flow were implemented. I'm also involved in a lot of strategic meetings on what we release and when - an interesting experience by itself.

Where this all will lead me in the future? No idea. I'm interested in moving to the USA and working there at least for some time - not just because it would make my day cycle sane and having most or all my meetings within the confines of the actual work days in the region I'm living in, but also because I learned to like a lot that country has to offer, from Country Music to Football and many other things (not to mention Louisiana-style Cajun cuisine). I'm also interested in working from an office with other Mozillians for a change, and in possibly becoming even more of a manager. Of course, I'd like to help moving the Mozilla mission forward where I can, openness, innovation and opportunities on the web are something I stand behind nowadays more than ever - and Firefox OS as well as associated technologies promise to really make a huge impact on the web of the future. I'm looking forward to quite exciting times!

If you’ve ever downloaded anything using Firefox, you’ve probably seen this fellow:

Early 2000?s baby, yeah!

This new window would pop up, and you could use it to manage and monitor your downloads.

There are a few problems with this new window:

• You had to switch back and forth from it just to see how close your downloads were to being finished

• It was easy to lose track of this window, especially when you had lots of windows open

• The window listed every download you’d ever started, meaning that it got slower to render as the list got longer and longer.

This is just scratching the surface. Suffice it to say that the downloads window left much to be desired.

So, your friendly neighbourhood Firefox Desktop team have been working hard to make things a whole lot better.

 

The Downloads Button and Panel

 

Starting in Firefox 20 (released today!), a new button will be added to your toolbar:

BEHOLD!

This button serves a number of purposes. For one thing, it tells you how long it will be until all of your downloads complete:

2 minutes until all of my downloads finish.

This button also animates when a download completes, and changes colour when all of your downloads are done:

Downloads are done!

Clicking on the button will show you your latest downloads:

Well, hello there.

And from here you can open your downloads easily. Not too shabby!

Like most things in Firefox, the new button can be moved to wherever you’d like it. Simply right click on your toolbar, and choose “Customize”, and drag the buttonto someplace new. Or, if you don’t want the button, you can drag it into the customize window to remove it completely (although, clearly you won’t be notified of downloads progress this way).

 

Manage your downloads in the Library

 

The downloads panel is a lightweight way to check the progress of your downloads. This is all well and good, but it doesn’t give us nearly the same power of the old downloads window. That’s why we have moved the functionality from the old downloads window into a new view in the Library.

Getting a fresh copy of Ubuntu 12.10.

The new manager has similar functionality to the old one, so you can search your downloads, clear them and even leave this window open while closing any other browser windows to complete downloads in the background.

Since this unifies the concept of downloads and history, there is no more risk of clearing downloads for privacy reasons, only to find that your history had retained them!

You’ll also notice that with the new per-window Private Browsing feature, downloads are managed separately by each window – the downloads manager opens in a tab so that you can easily manage your private downloads.

Just some wholesome browsing going on here.

This way, we make absolutely sure that your private downloads do not show up in your history, while still giving you full control over those downloads. Engagement ring PDFs for everybody!

 

Some tips and tricks

 

There are some neat shortcuts from the old manager that some of you may have used. We tried to retain those and even make them better.

• Pasting a url into the panel or the Library downloads view with CTRL-v will start a new download

• You can drag downloads from the panel or the Library to the desktop or any other path

• Related to this, you can download a PDF, and then drag it to the browser window to preview it using our built-in PDF viewer!

• You can drag a link to the downloads button to start a new download

• CTRL+j opens the Library directly in the Downloads section

 

Help us make it even better

 

If you find a bug in the new downloads experience, or you have enhancement requests for it, please file a bug in the Firefox / Downloads Panel component. You can also discuss the feature or your improvements ideas in the new firefox-dev mailing list.

On behalf of the team that helped make this thing happen (and folks, it’s been a long time coming), we hope you enjoy your new downloads experience in Firefox 20!