mozilla

Mozilla Nederland LogoDe Nederlandse
Mozilla-gemeenschap

Kent James: Thunderbird Summit in Toronto to Plan a Viable Future

Thunderbird - wo, 15/10/2014 - 06:17

On Wednesday, October 15 through Saturday, October 19, 2014, the Thunderbird core contributors (about 20 people in total) are gathering at the Mozilla offices in Toronto, Ontario for a key summit to plan a viable future for Thunderbird. The first two days are project work days, but on Friday, October 18 we will be meeting all day as a group to discuss how we can overcome various obstacles that threaten the continuing viability of Thunderbird as a project. This is an open Summit for all interested parties. Remote participation or viewing of Friday group sessions is possible, beginning at 9:30 AM EDT (6:30 AM Pacific Daylight Time)  using the same channels as the regular weekly Thunderbird status meetings.

Video Instructions: See https://wiki.mozilla.org/Thunderbird/StatusMeetings for details.

Overall Summit Description and Agenda: See https://wiki.mozilla.org/Thunderbird:Summit_2014

Feel free to join in if you are interested in the future of Thunderbird.

Categorieën: Mozilla-nl planet

Joshua Cranmer: Announcing jsmime 0.2

Thunderbird - za, 05/04/2014 - 19:18
Previously, I've been developing JSMime as a subdirectory within comm-central. However, after discussions with other developers, I have moved the official repository of record for JSMime to its own repository, now found on GitHub. The repository has been cleaned up and the feature set for version 0.2 has been selected, so that the current tip on JSMime (also the initial version) is version 0.2. This contains the feature set I imported into Thunderbird's source code last night, which is to say support for parsing MIME messages into the MIME tree, as well as support for parsing and encoding email address headers.

Thunderbird doesn't actually use the new code quite yet (as my current tree is stuck on a mozilla-central build error, so I haven't had time to run those patches through a last minute sanity check before requesting review), but the intent is to replace the current C++ implementations of nsIMsgHeaderParser and nsIMimeConverter with JSMime instead. Once those are done, I will be moving forward with my structured header plans which more or less ought to make those interfaces obsolete.

Within JSMime itself, the pieces which I will be working on next will be rounding out the implementation of header parsing and encoding support (I have prototypes for Date headers and the infernal RFC 2231 encoding that Content-Disposition needs), as well as support for building MIME messages from their constituent parts (a feature which would be greatly appreciated in the depths of compose and import in Thunderbird). I also want to implement full IDN and EAI support, but that's hampered by the lack of a JS implementation I can use for IDN (yes, there's punycode.js, but that doesn't do StringPrep). The important task of converting the MIME tree to a list of body parts and attachments is something I do want to work on as well, but I've vacillated on the implementation here several times and I'm not sure I've found one I like yet.

JSMime, as its name implies, tries to work in as pure JS as possible, augmented with several web APIs as necessary (such as TextDecoder for charset decoding). I'm using ES6 as the base here, because it gives me several features I consider invaluable for implementing JavaScript: Promises, Map, generators, let. This means it can run on an unprivileged web page—I test JSMime using Firefox nightlies and the Firefox debugger where necessary. Unfortunately, it only really works in Firefox at the moment because V8 doesn't support many ES6 features yet (such as destructuring, which is annoying but simple enough to work around, or Map iteration, which is completely necessary for the code). I'm not opposed to changing it to make it work on Node.js or Chrome, but I don't realistically have the time to spend doing it myself; if someone else has the time, please feel free to contact me or send patches.

Categorieën: Mozilla-nl planet

Instantbird: Instantbird 1.5 Released!

Thunderbird - vr, 20/12/2013 - 22:12

Instantbird 1.5 has been released: go grab your copy now! There are a ton of new features and bugs fixed for this new release, but we’d like to highlight a couple of new features below.

An exciting new feature you’ll find in Instantbird 1.5 is the New Conversation tab. It displays a list of your contacts, ordered based on how frequently and recently you’ve talked to them. Starting a conversation has never been easier! No longer will you have to open a separate window and scroll through your contact list to find a person. Just click the “+” button or press Ctrl/Cmd+T, start typing the name of the contact, and you should see your contact appear at the top of the list after typing only a few letters! You can then press enter and your conversation opens! The first time you open the tab, Instantbird will load your chat logs and learn who you talk to most often in order to offer accurate suggestions. New friends might not show up at the top immediately, but keep talking to them and they’ll reorder themselves. Don’t worry though, this ranking data is kept only on your own computer and is not transmitted or shared in any way!

Additionally, if you use Instantbird for IRC, the New Conversation tab will automatically query your servers to download the list of channels that are available to you. (This is generally known as LIST in IRC jargon.) Just like with your contacts, you can type in the name of a channel and it’ll bubble to the top of the list. Sometimes you don’t always know the channel name (that’s why you’re searching, right?): we’ve got you covered there too! Instantbird will search the channel topics in addition to channel names so you can quickly find new channels to join!

A very visible user interface improvement that was included for Instantbird 1.5 is redone tooltips that fit more into the visual style of the rest of the user interface. They should be immediately familiar to Instantbird users as they’re modeled after the conversation header! Hopefully this will help you find information quickly and easily whether conversing with your contacts or just checking their status.

For Linux users out there, we are still only offering 32-bit builds, although we hope to change that soon! If you are running a 64-bit Linux distribution, previously you’d have to install the ia32-libs (see our FAQ), but this has changed in recent versions of Ubuntu which no longer offer this package. The procedure now is to run:

sudo apt-get install libgtk2.0-0:i386 libpangox-1.0-0:i386 libpangoxft-1.0-0:i386 libidn11:i386 libglu1-mesa:i386 libxt-dev:i386 libasound-dev:i386

If you’d like to see a complete list of what’s new in Instantbird 1.5, please view the release notes.

Categorieën: Mozilla-nl planet

Joshua Cranmer: Understanding the comm-central build system

Thunderbird - wo, 08/05/2013 - 03:46
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."

Categorieën: Mozilla-nl planet

Joshua Cranmer: JSMime status update

Thunderbird - zo, 07/04/2013 - 23:47
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.

Categorieën: Mozilla-nl planet

Joshua Cranmer: Autotools, how I hate thee

Thunderbird - do, 08/11/2012 - 02:04
When writing custom passes for a compiler, it's often a good idea to try running them on real-world programs to assess things like scalability and correctness. Taking a large project and seeing your pass work (and provide useful results!) is an exhilarating feeling. On the other hand, trying to feed in your compiler options into build systems is a good route to an insane asylum.

I complained some time ago about autoconf 2.13 failing because it assumes implicit int. People rightly pointed out that newer versions of autoconf don't assume that anymore. But new versions still come with their own cornucopias of pain. Libtool, for example, believes that the best route to linking a program is to delete every compiler flag from the command line except those it knows about. Even if you explicitly specify them in LDFLAGS. Then there's this conftest program that I found while compiling gawk:

/* Define memcpy to an innocuous variant, in case <limits.h> declares memcpy. For example, HP-UX 11i <limits.h> declares gettimeofday. */ #define memcpy innocuous_memcpy /* System header to define __stub macros and hopefully few prototypes, which can conflict with char memcpy (); below. Prefer <limits.h> to <assert.h> if __STDC__ is defined, since <limits.h> exists even on freestanding compilers. */ #ifdef __STDC__ # include <limits.h> #else # include <assert.h> #endif #undef memcpy /* Override any GCC internal prototype to avoid an error. Use char because int might match the return type of a GCC builtin and then its argument prototype would still apply. */ #ifdef __cplusplus extern "C" #endif char memcpy (); /* The GNU C library defines this for functions which it implements to always fail with ENOSYS. Some functions are actually named something starting with __ and the normal name is an alias. */ #if defined __stub_memcpy || defined __stub___memcpy choke me #endif int main () { return memcpy (); ; return 0; }

…I think this code speaks for itself in how broken it is as a test. One of the parts of the compiler pass involved asserted due to memcpy not being used in the right way, crashing the compiler. Naturally, this being autoconf, it proceeded to assume that I didn't have a memcpy and thus decided to provide me one, which causes later code to break in spectacular bad function when you realize that memcpy is effectively a #define in modern glibc. And heaven forbid if I should try to compile with -Werror in configure scripts (nearly every test program causes a compiler warning along the lines of "builtin function is horribly misused").

The saddest part of all is that, as bad as autoconf is, it appears to be the least broken configuration system out there…

Categorieën: Mozilla-nl planet

Matt Brubeck: Metro Firefox without Windows 8

Mozilla planet - do, 20/09/2012 - 02:42

A few weeks ago I started working on the Firefox "Metro UI" project, for Windows 8's Metro (or Modern) touch-screen environment. While we're still working on getting our first preview builds ready for Windows 8 users to try out, you can already check out the current source code from the elm branch and build it yourself if you want to get involved and help us fix some bugs.

What you might not know is that you can run "Metro" Firefox even if you don't have Windows 8. It's been possible for a while to build and run on older versions of Windows using the -metrodesktop flag. Today I landed a patch to make this work on other platforms too. To build the latest elm source code on Linux or Mac OS X, follow these instructions:

  1. Clone the elm repo: hg clone http://hg.mozilla.org/projects/elm/
    (If you have already cloned mozilla-central or some other repo that shares with it, there's a faster way to do this.)

  2. Create a .mozconfig file with ac_add_options --enable-metro

  3. Build Firefox as you normally would.

  4. From your objdir, run dist/bin/firefox -metrodesktop (Linux)
    or dist/Nightly.app/Contents/MacOS/firefox -metrodesktop (Mac)

  5. You can visit about:config and enable metro.debug.treatmouseastouch (then restart the browser) to simulate touch interaction with the mouse. Right-click to simulate the Windows 8 edge-swipe gesture, which displays the toolbars.

This is still experimental and mostly untested. Elm might accidentally break on non-Windows platforms from time to time (because of course we are doing all our main development and testing on Windows). While it's not a perfect replacement for running in the real Windows 8 environment, I hope this is a useful option for adventurous Firefox contributors who want to experiment with the Metro code but don't have convenient access to Windows 8.

Categorieën: Mozilla-nl planet

Thunderbird Localization: Information regarding the upcoming Thunderbird 3.1 release

Thunderbird - do, 21/01/2010 - 14:56
as most of you know, after the successful release of Thunderbird 3, we are now moving towards our next major release Thunderbird 3.1 (codename Lanikai). Lanikai is scheduled to be released in early April 2010 and will be a considerably smaller release compared with the move from TB2 to TB3. This should result in a lot less string changes.

A draft release schedule of Thunderbird 3.1 is available on the mozilla.org wiki. Please note, that this is a preliminary schedule and still subject to change. In case of significant changes, I will of course notify the l10n community as soon as I become aware of those changes.

As of now, Thunderbird 3.1 is developed from the comm-central repository for all TB-related changes and the mozilla-1.9.2 repository for all core backend changes.

As a consequence that, l10n work on the respective TB3.1 localizations should happen on the respective l10n-mozilla-1.9.2 repositories. The same repositories that you use for the Firefox 3.6 localization.

For this we have updated the l10n dashboard. The tb31x tree there should now correctly report each localization's l10n-status. Looking at the dashboard now, it looks like many localizations will need to sync their 1.9.2 l10n repository with the work that they performed on their 1.9.1 l10n repository already. Some locales will have to move all their Thunderbird-related work (mail/, editor/ directories plus from other-licenses/branding/thunderbird/) over to their 1.9.2 repository. If you need any help with this, feel free to contact me and I'll help you with the move.
Categorieën: Mozilla-nl planet

Thunderbird Localization: Extension of l10n opt-in period for Thunderbird 3 RC1

Thunderbird - wo, 04/11/2009 - 10:43
The Thunderbird developers have slightly revised their release schedule and are now planning to start the builds for TB3 RC1 on the upcoming Sunday or Monday.

As a result I'll be extending the opt-in period for all participating locales until next Saturday (November 7) 23:59 CET. Please post your changeset updates into the existing opt-in thread.

If you have any questions, feel free to ask them here or in the mozilla.dev.l10n newsgroup.
Categorieën: Mozilla-nl planet

Thunderbird Localization: Thunderbird L10n at Mozilla Camp Europe 2009

Thunderbird - za, 03/10/2009 - 10:46
I'm in Prague right now at Mozilla Camp Europe 2009, where the whole European Mozilla community has gathered. I'm looking forward to meet most of our European localizers and drink some beers with them :)

I'll also be part of the Thunderbird talk that Ludovic Hirlimann is doing tomorrow about Thunderbird 3.

On a whole different topic: 17 locales have already translated all their strings for Thunderbird 3. More will hopefully follow soon. Very exciting!
Categorieën: Mozilla-nl planet

Philippe M. Chiasson: Thunderbird 2.0.0.21 is out, I think

Thunderbird - vr, 20/03/2009 - 16:04

Thunderbird 2.0.0.21 is out, I think
Originally uploaded by gozer Thunderbird 2.0.0.21 was recently released by the Mozilla Release Engineering team. The difference this time, well, all content, including the /start/ page is now hosted on mozillamessaging.com. Makes quite a large difference in our bandwitdh consumption, don't you think ?
The only problems I've been dealing with because of this is simply the amount of logs generated by this increase in traffic. Everything is fine now, but for a little while there, the rapid growth in traffic caught me a little off-guard. I was expecting more traffic, yes, but not quite that much more. It's actually a good thing, really, because except for a little disk space annoyance, the infrastructure behind mozillamessaging.com has handled a 20x increase in traffic without breaking a sweat. Good!
Categorieën: Mozilla-nl planet

Philippe M. Chiasson: MoMo CoLo

Thunderbird - vr, 14/11/2008 - 00:00

MoMo CoLo
Originally uploaded by active_gozer Finally gotten around to visiting the cage where the MoMo hardware is living. Couldn't resist snapping a few pictures, so here it is.

For the curious, here is what they are, from the top:
- Apple X-Serve
- Sun Fire 4150 x 4
- Sun Thumper (aka Sun Fire X5400) 18 Terrabytes of disk space

What's missing from the picture is the networking hardware.
Categorieën: Mozilla-nl planet

Philippe M. Chiasson: Pretty graphs, data and what to do with it?

Thunderbird - wo, 13/08/2008 - 21:43
hourly_usage_200806.png

Recently, we started receiving nightly logs of the Thunderbird start page hits. It now comes to us nightly, and I also got some historical data back to June 2008.


For the time being, I've just been feeding them all to webalizer, for lack of a better idea. There is not yet a complete plan as to what to do with all that data. Right now, it goes straight to infinite storage every evening. There is a lot of it, averaging at around 8 million hits a day, The included graph is the average traffic per hour of the day. That's in the 300k-500k hits per hour! I am glad that this traffic is being served by the mozilla.org hardware.


I know folks have already started to think of ways we could mine that data to learn useful things about Thunderbird and its user base, but it's only beginning. So, for the time being, I'd like to hear from anybody who can think of a questions that could be answered by all that data. Of course, respecting our users privacy is important, so I don't want anybody to know anything about specific individuals, just about trends. Are Russians users checking e-mails more often than us Canadians, for instance? (Not so sure that's a very useful thing to know)


Got a cool idea ? Have something you'd like to know ? Please, let me know.


<gozer at mozillamessaging dot com>


Categorieën: Mozilla-nl planet

Philippe M. Chiasson: Want your buildbot to talk IRC?

Thunderbird - za, 21/06/2008 - 07:21

In setting up a buildbot master, and, reading some documentation, noticed that it has tons of status plugins, one of which is an IRC bot.

Before anything else, you need TwistedWords, an instant-messaging library. So I had to go ahead, download and install it.


cd tmp
lftpget -c http://tmrc.mit.edu/mirror/twisted/Words/8.1/TwistedWords-8.1.0.tar.bz2
tar jxvf TwistedWords-8.1.0.tar.bz2
cd TwistedWords-8.1.0
python setup.py install

Once installed, all I had to do is to make a 2-line change to the buildbot master's master.cfg config file


from buildbot.status import words
c['status'].append(words.IRC('irc.mozilla.org', 'thunderbot', ['maildev']))

Next thing you know, you've got an IRC bot announcing builds, and you can even ask for new builds straight from an irc /msg, cool.

Categorieën: Mozilla-nl planet

Pagina's