There is no support for outlook/exchange. Not saying it's trivial, but it's useful in the modern era.
IMAP folder support is very flakey, I reported some bugs but nothing got fixed.
The search is really weird. I had to install an extension to always filter by date but even then it's broken to the point where I have to open webmail to do real searches.
[0]: https://addons.mozilla.org/en-us/thunderbird/addon/exquilla-...
I've never had problems with IMAP, nor do I use Exchange, so I can't speak to those...
http://davmail.sourceforge.net/
It may not be an "ideal" solution in that it requires a second program running, but given that you're working with a closed, non-standard protocol, that's kinda par for the course.
Not only that, but making one based on web technologies that moves away from the native look and feel it currently has would truly be a loss in my opinion. I'd probably give Claws Mail and alpine another go, maybe even desktop outlook before I'd go to something Electron-esque. I already have enough shitty electron apps - I'm currently dealing with a really weird font rendering issue arising from Electron use in VS Code.
I don't see why a new implementation couldn't maintain the current UI/native feel outside of poor decision making.
I could see it as a net positive, with cleaner easier to maintain code base built on more recent tech that is more accommodating to younger developers.
If they could pull off what Atom.io/Github did for the old ingrained IDE world in a mail client, that would be incredible, IMO.
I use Thunderbird every day and am generally happy with it, but often when I come across some feature that I wish were changed and start digging into Bugzilla it becomes apparent to me that the Thunderbird codebase is old, convoluted, and difficult to work with -- the result of growing organically over many years. I could see a lot of benefits to a re-write. On the other hand, trying to match feature parity with the current version would probably take a lot more work than the author of that proposal is accounting for.
So yeah, it's mostly done, but better virtual folder support, and a streamlined UI would both be hugely appreciated by me.
But, because it's mostly done, I also will just happily keep using it as it is now for the next three years, waiting for the rewrite.
Overall the main problem is probably that not enough people can spend enough time on it. Which makes me hypocritical given that I'm not currently helping…
Then, when sending mail, if there's a public key for the recipient, then encrypt it. No user interaction is required.
Yes it is. Or someone would have done it by now.
> When receiving mail, store the sender's public key
You mean "the public key associated with the inbound email". You don't know anything at this point about how it relates to the person you're intending to correspond with, because the key could be MITMd.
Also, this approach does nothing to solve the fact that most people would prefer webmail and mail synced across multiple devices, which is an even more painful key management problem.
I think that the intention is to keep it that way. They're proposing mostly a reimplementation of the UI, from Gecko+XUL to HTML+JS, but also a reworking of the interface between frontend and backend code (I guess between the model/controller and view parts of the code).
The search is just broken. It gives messages that don't have anything of search string in them and misses the right ones.
Having said that it's still the best email client software I can find - UI issues aside.
1. Can I tag messages? If not, it is unusable for me. Once you get used to notmuch/sup type workflows, everything else sucks.
2. How good are its searches? Can I say I want all messages after a certain date, with a certain word, with no attachments (or with attachments > 100 KB, or with attachments whose name includes "xxxx")?
3. Does it support virtual folders, which essentially are saved searches?
2. Search filtering options are all there, however the actual search algorithm is mediocre as fuck. You'll probably eventually find the email you are looking for.
3. Yes, virtual folders are supported.
Overall it's a great, however clunky piece of software. I didn't realize the code base was ~20 years old, so I fully support them doing a new implementation. Thunderbird has been a great client for me for 5+ years but imagining it powered with fresh, up-to-date tech excites me even more.
Is something like that now available in Thunderbird?
If it's done, it isn't going away, just keep using the same binary forever.
If it isn't done—i.e. if it needs porting to new platforms, security patches, bug fixes, etc.—then there needs to be people who interested and invested in the codebase, both at Mozilla and the OSS community. Which means having a path into the future.
Based on some chatter here recently, I just recently switched to trying out Claw, it hasn't been too long yet, so I don't know all of the issues yet, but at least it was easy to setup and is really really snappy and uses about 1/3 of the RAM.
(It also refuses to acknowledge deleted and created folders on my work account, but, not knowing the actual cause, I am very happy to suppose that the blame lies on some administrator at work making some hostile-to-non-Outlook-users change in OWA setting.)
Frankly, on occasions, I find Thunderbird is unusable for some jobs and I end up using either an ancient copy of Eudora Mail, or Outlook or other packages to get the job done (it's just about the most idiosyncratic software package I know).
Briefly, the key issues for me are:
1. The editor sucks, big time, to call it a HTML editor at all is stretching the truth beyond reasonable recognition it is so broken. (a) It's bug-ridden in the extreme (long emails with formatting are better edited outside TB and then cut-and-pasted back in when finished but this is only a partial solution for the obvious reason that the underlying editor will then screw up perfectly good HTML). (b) Bugs develop/manifest over time whilst actually editing a single email/email reply (seems to have memory leaks). The formatting is very limited—superscripts etc., etc. require add-ons, to be implemented. Today, HTML formatting is a trivial matter (or it ought to be) so why after decades hasn't Mozilla implemented such basic formatting within Thunderbird by default. (Moreover, heaven help us when we need to add proper math formulae to the mix—just forget the notion!) (c) Global typeface change(s) is so broken it's better to save one's work before attempting them, alternatively one has to cut them into a plaintext editor (notepad etc.) to all kill formatting and start again preferably in another decent HTML editor such as BlueGriffon (which, incidentally is also based on Firefox). (d) Text size and text spacing is likewise hopeless and also has to be edited outside Thunderbird then cut-and-pasted back in. (e) There is no Format Painter! (f) Nor is there an Add/Remove quotes level facility (AND THUNDERBIRD ACTUALLY CALLS ITSELF AN EMAIL CLIENT?)—not having proper quotes handling is like buying a vehicle without wheels! It's sheer crazy stuff.
I could keep going on about editor problems and mention the issues with inserting images etc. but that's enough for here.
Finally, summarizing the matter of the Thunderbird editor issues, I again mention the BlueGriffon HTML editor by comparison, specifically because it is based on the same Firefox code as TB is. This proves that the limitations within the Thunderbird editor ARE NOT in any way limited by the underlying Firefox code. It seems to me that as BlueGriffon is open-source, the simplest immediate correction Mozilla could do to Thunderbird to fix its horrible editor would be use this BlueGriffon code as is, as it actually works!
2. The Thunderbird UI is confusing for both new and older users alike. The issue of the UI is too involved to discuss here in any detailed way except to say TB's designers should look at one of the all-time great classic email client designs for guidance: Eudora Email. (Many of us would still be using Eudora in preference to Thunderbird if Qualcomm hadn't killed it off over a decade ago—even then, many still do use it). Why reinvent the wheel if you're going to break it in the process? For starters, you cannot even dock the windows in Thunderbird. Why on earth not? (One wonders whatever went on in the minds of the original TB developers.)
3. Thunderbird's implementation of MBOX mail format is severely broken (it is dead easy to lose mail permanently from crashed indexes, compacting mail etc. The fact that Thunderbird's MBOXes are essentially incompatible with other email packages that also use MBOX is a serious issue when it comes to large site usage, maintenance etc. The MBOX problem is one of the main reasons why Outlook is often preferred to Thunderbird in corporate environments (Microsoft may be proprietary but every man and his dog either knows about its PST mail files or has a utility to maintain or fix them—not so with Thunderbird MBOXes. Moreover, Thunderbird MBOX mail files almost invariably crash when they reach the 4GB size threshold (it's a very risky business and you'd better have a decent backup strategy if you want to risk it).
4. Thunderbird even [still] has bugs in the mail addressing department (the text goes red for some reason if one does editing on the email entry). This alarms users. Furthermore, even the method of entry of CCs, BCCs is unnecessarily different to other email clients. Why unnecessarily confuse users with a redesign just for the sake of it (for heaven's sake, it seems to me the only way this could ever have happened is that TB's original developer's had never used an email package before starting on the project). Talk about this as being peculiar is a gross understatement, unfortunately such inane thinking underpins much of the basic design (Thunderbird is a quintessential, truly wonderful, example of Rube Goldberg/Heath Robinson design principles!)
5. At various times, I have tried to fix Thunderbird's limitations by applying various add-ons, and after installing sometimes up to about 35 I've just given up. Some things were fixed, others not, and there were inevitable interactions between these various add-ons. I could write a lengthy article about what is (still) not fixable with any number of add-ons; essentially though, the underlying code is so broken and haphazard that no add-on is able to fix some problems. ONE SHOULD NOT HAVE TO RELY ON ADD-ONS JUST TO OVERCOME FUNDAMENTAL DESIGN LIMITATIONS.
6. Thunderbird is slow in almost every aspect of its operation—truly unbelievably slow when compared to other packages of similar design.
From what I've read in this Thunderbird Mozilla post, I have little faith that the end product will ever satisfy serious email users (especially if lesser used features are dropped) which seems to be the proposal. Likely we'll end up with another mishmash similar to the confounded MS Office ribbon (that'll alienate most of its traditional user base—after all, Mozilla has been a past master at incompatibility for many years (every new version of Firefox has at least broken some my favourite add-ons, then there's the horrid Australis interface, and so on). Unfortunately, at Mozilla, developer culture has always taken precedent over user requirements; it would be foolhardy to think current Mozilla culture will change with a new Thunderbird design (corporate culture is always too ingrained to change that quickly).
Finally, it seems to me, that if Thunderbird's developers are actually serious about producing a better design for the majority of users (other than their own pet design) then they should open a web site to that effect and allow ordinary users to discuss and thrash out exactly what features they want within the new design. Perhaps they should include existing forks in such discussions, FossaMail for instance.
In the meantime, I reckon developers of other email clients have very little to worry about.
I will also point out that there is actually some fairly deep integration code within the Mozilla editor with Thunderbird's compose backend (particularly in regards to the need to generate inline embedded images). There have been attempts to replace the editor with a more functional one in the past, but they all came to naught.
If you need to write something lengthy and heavily formatted, do it in a Google Doc or blog post and put a link in your email.
Search could be smarter (and faster). Also I remember I had to do something tricky to make search default to "date" sorting instead of "relevance", and that should really just be in the preferences dialog somewhere.
But basically I have no complaints!
I consider this almost a deal-breaker. It's such a simple theory that just about every other GUI MUA gets right.
Overall, it's a certain bare minimum of acceptable. It's not a great application.
(protip don't subscribe to LKML)
Careful configuration of the sending/reply address should let you reply to the mailing list by email as normal, or there may be a way using NNTP -- the documentation on the GMane website is missing, as they're rewriting the service.
[1] http://dir.gmane.org/gmane.linux.kernel
[2] nntp://news.gmane.org/gmane.linux.kernel
But this! The post outlines a three year timeframe. I do not believe it. I believe Mozilla will be gone before three years, and Thunderbird with it, one way or the other.
That's a dramatic prediction! Why do you believe it?
But to answer your question, I and several others I know whom use Thunderbird consider it a "least awful" choice. It's less complicated, opinionated, and buggy that Outlook. It's cross-platform unlike some of the other top-tier options. And it's less centralized, surveilled, and inverse-productized than third-party web-based email such as Gmail. It supports multiple accounts, through add-ons it supports GPG, it blocks bad HTML in messages, and for the most part it works well enough.
However, yes, I do have a lot of problems with Thunrderbird, ranging from daily annoyances to minor pet peeves. Reviewing my Bugzilla votes would be exhausting, but some highlights:
As others have pointed out, the search functionality is poor. It's slower than alternative clients (e.g., Opera Mail) and less accurate. It also opens to a low-value "search results" view rather than a list view. ( See https://bugzilla.mozilla.org/show_bug.cgi?id=580252 ) It's not easy to quickly execute a search on the current folder only. The full search is so frustrating that I am in the habit of using the quick-filter bar (control-shift-K) because it works as I feel an e-mail search should work, but woe to the user who has "Body" selected in that UI control since the filter function does not use the search index. Also, why does ESC hide the quick-filter bar?
Addressing is slow even on extremely fast workstations, to the point of routinely causing me to need to correct addressing errors. However, they recently fixed bug 1012397 so that resolution will occur after a blur of an addressing field. Yay! ( See https://bugzilla.mozilla.org/show_bug.cgi?id=1012397 ) Though other composition / addressing quirks such an improper initial focus on the composition pane still remain. ( See https://bugzilla.mozilla.org/show_bug.cgi?id=329482 )
The email composition window is often slowed by activity occurring elsewhere within Thunderbird. If Thunderbird is working on moving a bunch of messages, for example, it can sometimes struggle to keep pace with typing in a composition window, on workstations with 8 or 16 modern CPU cores and NVMe SSDs.
All told, I would also be more or less happy with ongoing improvement to the existing product. But I understand that may not be viable if the underlying technologies start fading away.
Absolutely correct, it's why we have to put up a strong clear-cut case now to ensure the developers know exactly what we users want. To do just that will, on occasions, require us to be very specific.
We should not be the slightest bit shy about complaining.
The old Opera 12 browser featured such a similar HTML based email client. Vivaldi promised such a email client, but no news for years.
Thunderbird is like Outlook Express aka Windows Mail (Windows Vista/7/8) (both deprecated), Outlook's little brother.
(Citation Needed).
This proposal identifies serious legitimate concerns with Thunderbird development going forward, but the proposed solution looks more like a hammer seeking a nail than a thoughtful approach to addressing the concerns.
> Why not do it in Rust and start with some of the Servo code as a base?
Thought about it, but I think Servo might just not be that ready yet given the expected timeframe. Could be of a great synergy and a nice real-life testbed for Servo though.
† I've extensively used a lot on various OSes, from Claws to Gmail (web) to mutt to Mail.app to Eudora to Fastmail (web) to Outlook to AirMail. For none of them could I ever say "nailed it" and while some do have their pluses they're all broken one way or another which brings the whole package down.
For most of the last three years I've worked on Nylas Mail (https://github.com/Nylas/Nylas-mail), and it hit 2.0 yesterday with Mac/Win/Linux support. It's entirely open source (GPL), written in JavaScript, syncs mail locally, etc. It essentially -is- what the author of the post is looking to build, except it doesn't look like Thunderbird. Nylas put at least $2M+ worth of engineering time into it, and I imagine ThunderbirdJS would take at least a similar commitment of time and effort. Heck, maybe they could just skin Nylas Mail and call it Thunderbird ;-)
I tried it out, didn't read the fine print, filed an issue, never looked at it again.
Because "It keeps user data local and private." is kind of one of the main benefits.
Originally Nylas Mail was OSS, but tied to the Nylas Cloud APIs (which did the actual mail processing.)
The cloud strategy was too expensive, and in version 2.0 the entire mail-sync system was moved into the client and open sourced. (https://github.com/nylas/nylas-mail/tree/master/packages/cli...). It's now much more like Thunderbird. There's a bit of cloud processing for snoozing / send later, etc., but it no longer syncs all your email through the cloud.
I really don't see the point of Thunderbird reinventing the wheel to essentially build another Nylas.
I used Thunderbird years ago; now I'm a very happy Nylas user. I don't doubt that the Thunderbird team could spend the next 3 years building a very polished desktop mail app using web technologies, but uh...
...do we need another? And if so, wouldn't it be better to fork Nylas as a base? I mean, they could probably get most of the way their with a couple pull requests to make themes more powerful and a custom theme...
Question: Will the revenue from the Pro product really support development and maintenance of the free product? The free product is perfect for my needs, none of the Pro features are that useful for me (and its too expensive - email accounts from Google or Fastmail are $5/month, Nylas Pro is $12/month on top of that just for the client). The free product, as is today, is easily worth $20-30, IMO.
Additional Comment: https://www.nylas.com/pricing needs to be updated. A lot of the Pro features are now available in the Free 2.0 version.
Skin it or Fork and Skin ;)
Great job.
I dont get the C++ hate though. C++11 and up is a totally new language and much more productive than its reputation gives it.
Sadly I doubt TB has the resources to make that happen, but still, it would be neat...
And there's some work in progress to put a WebView-compatible API on top of Servo, making it trivial to substitute it in an arbitrary application.
Not trying to start a this language is better flame war, but is this true? I still find JS to be a strange and incomplete feeling language, but I've not really done much outside of front end work with it. Is it really that productive?
Also I've disliked every interaction with NPM. You end up with a huge chain of decencies for even simple applications. Is this something that's workable with production software?
But that doesn't mean JavaScript is a good language. e.g., you have to be extremely careful to not get bitten by the floating point-only math. It was the source of catastrophic bugs for many Twitter clients (in the sense that they stopped working) -- I would hate to find such a bug ate my local mail store.
Not sure what I'd recommend, though - JavaScript is technically bad, but socially excellent for such a project. Python is not fast enough for it (PyPy not withstanding), D/Rust/Nim/Ocaml/Scala are not mainstream enough.
It is definitely production workable. It's "LTS" cycle is insane, but it's workable.
I have yet to find a better system for rapid application development. XUL is wonderful, extentable, everybody know CSS and Javascript these days, XML is very well suited for such tasks. It's one of the best technologies for power-users I ever came around!
All that was ever needed would habe been a Mozilla, that creates an XUL IDE, rather than taking up on a lot of stupid projects (Persona Light Themes, Hello Chat, FirefoxOS, removing XPFE (how coding with XUL is actually called) and whatever (the only real good thing to mention would be Ubiquity, but they killed that off as well), oh, and let's not start talking about Firefoxy mugs, t-shirts, community barbecues, community videos... But hey, that's what happened.
Now, if some people would just fork xulrunner and mirrror the addons.mozilla.org stuff...
As for Thunderbird, I am also pretty satisfied as it is. It may be nice, if one could set certain To: email-addresses per folder (mailing-list folders would greatly benefit from that, along with subscribe/unsubscribe configured per such folder), alternate views onto mails and have, maybe, a modernized foldering-system.
It also looks awful and ignores desktop themeing. Or is that just firefox?
Doesn't 4 people dedicated to front-end UI seem excessive/unnecessary? At least, at the beginning? I would dedicate almost all work to the framework and backend modules; UI with web technologies is far from complicated compared to everything else the client would require.
The thread is worth a read, interesting arguments regarding rewrite/refactor/approaches to transition.
in the process of being planned or done
Even JavaScript is not that bad. I not familiar with Electron: do those apps run from a directory with the source code or are a binary file? Running from source code would make it easy to hack with the code, which is good.
Does any cross-platform GUI toolkit have a widget that can handle this with sane defaults?
The problem browser based apps run into is rendering the entire list into the DOM and thus the browser has to lay out the whole thing in order to compute scroll bars and scroll positions.
You can work around this using requestAnimationFrame, large empty padding divs, and inspecting the scroll position to create DOM elements for only things that you compute are visible. At my last job I implemented a web based table that could do 60fps scrolling on 100,000 items that were all dynamically updating using js_of_ocaml and https://github.com/janestreet/incr_dom.
You can do this with JS and HTML. There are some popular small JS libs that do just that.
It works like this: it creates a div with a very big "height" value to get the scrollbar look like there is a long list, and JS just loads in the visible area plus a few items above and below, and reloads data as you scroll. It works very good in Chrome and Firefox, and even okay in IE11.
10/second for 2.5 hours, no pause, no breaks.
You read those emails? You acted on them? You remember what's in them? Archived data is a hoarding disorder, a garbage heap.
Using web technologies for desktop apps is not ideal, but at the same time it's probably the easiest way these days to build cross-platform apps because of the lack of a good cross-platform UI toolkit.
A big benefit I see is that it will make it very hackable as a lot of developers are familiar with web technologies. That should be a good way to get a lot of contributors to implement features and innovate (See for example the community / contributions around Visual Studio Code).
And it worked decently.
Start by tidying it up for Android and then port it to desktop. One code base - for mobile, tablet and desktop.
after using slack for a while i feel we can use one slack-channel for each email contact, a bit like google wave probably, and thunderbird can merge email+slack experience into one.
This Electron competitor would become very popular, and it could become the "entry drug" into Rust development (you would be able to do everything in HTML/CSS/JS but you would also have the option to code some parts in Rust, for more power), which would also grow the number of Servo contributors. With a large enough community, Servo-based Firefox could fight for a place at being the best browser (safest, fastest, full-featured).
That's too bad, in a way. One thing I'd really like that Thunderbird doesn't offer today is to separate the mail receive/store/send functionality from the reading/writing UI, so I could run the former on my own server and access it from any device on my network.
Obviously there are some relevant standards here and you could set something like this up with enough technical knowledge using other tools that already exist. However, that reduces the potential market by a few orders of magnitude to those who are sufficiently expert with those tools, and then probably by a few orders more for those who have the time to actually do it.
Uh, that's exactly what an email server does. Thunderbird is just the client used to access it from any device.
Sure Thunderbird kind-of works, as in it's "done", but people find Security bugs in the Firefox base and it's not sure how they apply to Thunderbird to Thunderbird has to take the update and then they have to deal with the breakage and the incompatibility. You can't just stop and be on Firefox 45 forever. That's just asking for trouble.
Nylas all over again... Why complicate and bloat things as if it's the obvious sensible choice?
The time to finally learn how to configure mutt is that much close...
edit: Scratch that, it was in this reply: https://mail.mozilla.org/pipermail/tb-planning/2017-March/00... . "I'd suggest using TypeScript, Mithril.js, Tachyons, and Node.js for the base technologies -- probably with Mocha/Chai for testing. Later we can make a more stand-alone desktop version with Electron or such. We could use socket.io to push notifications for changes in real or virtual folders and then use Mithril.js (a vdom library) to quickly rerender changed data the client UI requests (or is pushed)."
Worth noting that reply looks more like a wishlist of stuff than a meaningful viable proposal.
I used to use both Thunderbird and Firefox a few years ago as my main mail client and browser. Since then, Mozilla started spreading between too many projects, chasing the failed phone thing, and both Firefox and even worse Thunderbird are nowhere near where their competitors are.
I now use Google Chrome and Google Inbox (via Electron app Wavebox, formerly WMail), and they actually look from this century. I downloaded Thunderbird a few months ago out of nostalgia, and everything looks the same as 5 years ago. Pretty sad.
You know what I want? NWJS/Electron but using Firefox/Spidermonkey. I want to package desktop apps with Firefox. They almost had this with xulrunner but killed it for some reason. And I want them to build crosswalk (https://crosswalk-project.org/) for mobile, but with Firefox. The only real reason is that I don't trust Google or anything they touch, and I've never actually been able to build Chromium/NWJS from source (such a complicated build), which worries me.
Call me paranoid, but the monoculture around Chromium creeps me out and I'd really like a viable alternative from Mozilla. Seems like they jumped ship from the packaged HTML5 desktop/mobile app paradigm right when it started getting popular.
IMHO, one of Mozilla's greatest failures was its decision to more or less give up on embedding (for both SpiderMonkey and Gecko). They effectively killed off embedding in the process of moving to the train model back in 2011, 2012, but back then, the expectation was that they would have their 2 years of "let's kill our broken architecture." Instead, it sort of ended up dragging on how long it would take them to stabilize some APIs for embedding, and they certainly never bothered to try to maintain any documentation (I briefly attempted to maintain some client application that used SpiderMonkey in 2011, and it was a headache trying to find any sort of documentation on how to fix each incremental bustage, since everything that was found on MDN was woefully out of date).
First, there was to be some sort of IPC-based embedding mechanism in Gecko. Then that idea was nixed in favor of just XULRunner. Then Mozilla decided it didn't want to maintain XULRunner anymore. For a period of time, they had a XULRunner-like setup called something like webapprt (which was basically a Firefox sans normal Firefox UI), but that too was killed off within a few years.
If by "they" you are referring to Mozilla: they will not be involved in the rewrite.
It's the paradigm, the absence of automatic sorting of emails (priority/promo, etc.), failure of prioritizing common actions in the UI (everything is the same, the spam folder and the inbox folder are given the same importance, "compose" is not prominent, etc.). I could go on forever.
IMO, it's kind of how good software was made 10 years ago, but now we're used to much better.
Just the fact that the address bar font is the same size as the rest of the UI gives me the impression that they didn't think it through. Downloading files has the same problem, it's relegated in a small button, while it's one of the main features.
The whole interface is one of the most unintuitive things I've ever used, considering how simple a browser can be in terms of functionality the user must access. I'll also never forget they they thought tabs on top didn't make sense (it's actually still an option you can change).
Chrome had search integrated in the address bar from version 1, every time I opened Firefox year after year and I saw that little separate input for searching I felt like using grandma's browser.
In terms of how pretty the UI is, Firefox 53—which just got released—looks better, but it took them years to get to where Chrome was back at version 1.
Syncing of bookmarks, settings, addons, passwords, tabs across devices etc. on Firefox is a lot less efficient.
From a technological point of view, it took them years to implement sandboxing, and they're still not done. If a tab misbehaves in Firefox it can take down the whole thing. Chrome had it right away.
I briefly tried switching to Firefox again a few months ago. Initially I tried fixing it via changing the interface via XUL, but the problems were too deep. I got very frustrated and went back to Chrome.
git clone <thunderbird-url>
<build from source and sudo make install>
I hope for two things.
1) Drag attachments to folders finally works on Linux.
2) Message filters keep working exactly as they are now or it's going to be a huge pain to migrate them. And a showstopper with no filters.
Stop making your problems worse and get your $#!% together! I'm a sysadmin, dangit, I need this tool to work!
This leads to a completely independent Mozilla project, Thunderbird, that relied on this technology to get the axe.
That project thus is discussing taking the difficult technical step to start from scratch while keeping the user experience the same its been for 10 years.
This, in turn, leads to you criticising Mozilla for not focusing on making their browser fast, stable and secure. Because you are hitting some configuration/update/UI bugs that seem entirely unrelated to the core browsing experience. Thunderbird, BTW, has 25 million users. So even if you don't need it, some people do.
If you're a sysadmin and you test everything in an ancient version of Firefox that doesn't display SSL errors, you're not getting an accurate picture of what the product's users will see. The latest browsers might entirely block people from visiting your site, display a huge warning, etc. and you wouldn't know. Maybe being a sysadmin requires getting the fixes, refreshes, rebranding as they come down the pipe? I'm also not a fan of the recent changes, just take a more defeatist attitude I guess!
I keep FireFox portable 3.x around for sites (intranet devices) like that.