I wanted to love Thunderbird, used it for years then a bug [0] literally deleted all my emails. I regularly see updates of people understandably raging on the ticket :( It's a bug that literally deletes user data from both the server and the client without warning. It's been open and confirmed for 17 years straight. It could happen to you. How is it not top 1 priority to fix it?
I too think they should drop everything else and work on this bug. But an example of how these kinds of bugs are tricky:
I have a similar bug at my job: Sometimes browsers delete our extension's database, or otherwise corrupt it. It's been an issue for years, but no one has been able to reproduce it. It's probably a 1 in 10 million bug.
I think it's a hardware bug. My "fix" was to backup a small, but key, part of the database to a separate storage mechanism browsers let us access. When the issue arises we can now try to detect the missing data and restore part of the db.
BUT! If this is actually a hardware bug, there is a chance that this additional database write will cause this big to occur even more often, as we now have to write to storage twice as often!
> Sometimes browsers delete our extension's database ... but no one has been able to reproduce it.
Are any of the bug reporters using Vivaldi? As for some reason that browser allows (and enables by default) clearing extension storage when clearing history/cookies via Delete Browsing Data.
This is something the Stylus addon dev noted when a user was reporting the addon wasn't remembering their settings and it was because the user had unwittingly wiped the extension storage due to the browser defaults.
(I actually use Vivaldi myself but virtually never use that feature so was unaware of the behavior until reading about the bug report)
"Delete" was an over simplification. The database seems to be there, but the data isn't. Dozens of engineers over the years have tried to find a way we could have accidentally cleared the data, but not the keys.
No user that has reported it has been willing to share their database with us (chrome stores it in a standard leveldb), as it contains private information.
But good to know that about Vivaldi! I didn't know that before, thanks!
Thanks for linking that. I've tried Thunderbird a couple of times in the past and quite liked it, but that thread has put me off using it forever.
Even if the bug is fiendishly hard to track down and reproduce, you'd think there would be some additional safety checks they could add that would at least let it fail with an error message instead of actual data loss.
People would still complain about them on forums, often ones run by the company who makes the client! I'm often reading threads of issues on Apple's public support forums. Being open or closed source has nothing to do with hearing about problems.
Closed software doesn't have open bug trackers, so there's no systematic way to find out.
An acquaintance of mine were twice hit with a bug that corrupted Word documents stored on iCloud if editing on her iPad. Searching online yielded others with the same problem from more than one year ago...
I was able to find complaints fairly easily. I had them listed but HN ate my comment. Search "Missing emails" instead of "delete all emails" as the latter tends to provide instructions about how to bulk delete.
> Being open or closed source has nothing to do with hearing about problems.
Also, pay attention to observation bias and userbase bias.
If my dad faced this issue, he'd never post online. He'd call me or go to a computer repair shop. That's what your average user will do.
Open Source users tend to be a bit more tech savvy. There's that famous article about Linux gamers reporting way more bugs than average users and how it can be accidentally misinterpreted as "why develop for linux?" These frequency biases are a big part of this. Pluus, OSS tends to do better bug tracking.
> you'd think there would be some additional safety checks they could add that would at least let it fail with an error message instead of actual data loss.
My guess is that these would exist, and do.
I think you've just made an assumption about a bug that was reported 17 years ago. Assuming nothing has been done since. It looks like they can't reproduce it, *making it impossible to mark as fixed* even if it was. But I wouldn't assume nothing was done.
Also remember that Gmail, Outlook, and others are in play here. They also maintain trashed items for 30 days, making it easy to recover. As the provider, they shouldn't make it easy to mass delete things either, right? TB is just the interface, frankly, I'm not sure I know how to permanently delete emails with it. I'm not sure I can. But the interaction here should result in multiple lines of defense.
It's not just one report from 17 years ago, it's 194 comments with the most recent one from nine months ago. It doesn't seem like mitigation steps have been implemented.
Well, I do think the thundebird team should investigate and fix this. But it is almost impossible to fix a bug you can't reproduce and have no clue why it might be happening.
> But it is almost impossible to fix a bug you can't reproduce and have no clue why it might be happening.
No, not at all. It's very easy.
This bug involves taking an inappropriate action under corrupted conditions. You don't need to know how those conditions arose. All you have to do is check whether they currently obtain, and - if so - refrain from taking the inappropriate action.
For this bug, that looks like this:
1. When we're executing a "move"...
2. Before deleting the original messages...
3. Check whether the copies are identical to the originals...
4. And if not, delete the copies instead of the originals.
At this point, the bug can't occur. The "root cause" bug, where your buggy logic says that you copied a bunch of messages even though you didn't, can still occur, but it can no longer delete any messages.
So…do it. Sounds like it’d make a great case study that would get a person tons of attention and praise on HN, a real feather to put in one’s cap.
Literally nothing stopping anyone in this thread from opening a PR with this reportedly “very easy” fix that’s eluded developers for nearly two decades, and is so terrible folks swear off Thunderbird forever because I guess for email very basic rules for backing up data don’t apply (or something?) and/or Gmail and Outlook are implicitly trustworthy?
> and is so terrible folks swear off Thunderbird forever because I guess for email very basic rules for backing up data don’t apply (or something?)
Well, this bug literally causes Thunderbird to delete your original copies of data during the backup process, so I'm not sure why backing up your data is supposed to be the solution.
One of the many comments on the issue notes that although the bug has reoccurred in every version of Windows, it might not get much attention from developers because it is catalogued as something specific to Windows XP.
Nobody in the intervening nine years followed up by updating the bug's metadata, though. It's still "Windows XP only".
I try to never underestimate the incompetence/lack of concern people can have when it comes to addressing major product issues, but if this has been open for 17 years and is so widely known, somebody has surely looked into it and determined it’s not so easy.
and then they simultaneously determined "yeah, we might eat your data. Lets not warn anyone about that AT ALL, lets keep the feature activated and let them users lose their data". This behavior ought to be criminal.
> Lets not warn anyone about that AT ALL, lets keep the feature activated and let them users lose their data
How did you conclude this?
IDK why the assumption is that safety measures haven't been created. You wouldn't mark the bug as resolved if you put in safety features, right? You *ONLY MARK AS RESOLVED* after reproducing the bug and *VERIFYING* that it won't happen again. Right? Dear god I hope this is what you do, because otherwise you are prematurely closing bugs.
I'd agree with you that the fact that the bug is still open after 17 years isn't the problem, but the issue is that people are still (as of 10 months ago) running into the issue of their mail being deleted. If they'd secretly implemented "safety measures" as you suggest that wouldn't be happening.
Looking at the timeline, it's possible that they've addressed a few of the bugs that result in data loss several years ago, and it's possible that the latest guy who ran into the problem within the last year triggered it in new ways or under new conditions but it's clear that the problem of thunderbird deleting messages from the server when copies haven't successfully been saved during a move operation wasn't solved by any "safety measures" 9 months ago and it's doubtful that it's been solved now.
My guess is that because thunderbird ultimately doesn't bother to make sure that messages are successfully and accurately copied before it removes them from the server it'll only be a matter of time before someone else stumbles on some other set of circumstances which results in data loss when messages are being moved.
Reading the bug report it is unclear to me if the newest one is the same bug. There are also other bugs referenced that look to be fixed.
> If they'd secretly implemented "safety measures" as you suggest that wouldn't be happening.
But we can *VERIFY* that measures were taken. In fact, easily! We can look at the references at the very top of the bug report!
- Title: move/copying multiple imap messages to local folder bypasses offline store and redownloads messages. Need to preflight the move/copy.
Status: RESOLVED FIXED
https://bugzilla.mozilla.org/show_bug.cgi?id=505456
There are others that need to be hunted for but this one was trivial to find and was implemented pretty quickly. There are also other similar bugs that weren't marked as dupes. Some of these have been marked as resolved and fixed. That leads me to believe that they just don't know what exactly this bug is because they can't reproduce. It may very well have been resolved and new issues might be completely new bugs. I mean... it has been 17 years... and TB has undergone significant rewriting. Don't you think that the software changed quite a bit in that time?
Which all I'm trying to argue is that they didn't just sit on their asses and do nothing for 17 years
> But we can *VERIFY* that measures were taken. In fact, easily! We can look at the references at the very top of the bug report!
>> Title: move/copying multiple imap messages to local folder bypasses offline store and redownloads messages. Need to preflight the move/copy.
>> Status: RESOLVED FIXED
This might be a more compelling observation if the bug was related to data loss. This just says "if you have a local copy of something, read from that instead of reading from the remote server".
It addresses the specific observation made in the thread that you can encounter the data loss bug even if you already have local copies of the messages, because Thunderbird ignores those, redownloads from the server, fails, and then deletes everything. Now, if you have local copies, Thunderbird won't try to redownload them from the server and the fact that the data loss bug isn't fixed won't matter to you.
You could apply this same approach to the entire bug, by guarding the "delete all of the user's emails" action instead of the "move emails that already exist locally" action. But they don't.
are you being for real? did you see anything as such in the bug listing? but even IF they did put safeguards in place, the fact that this is SEVENTEEN YEARS, no warning, functionality still enabled without ANY WARNING losing people data. unforgivable.
How can you possibly justify this behavior? I understand they dont owe the world any software, fine, but dont knowingly publish stuff that KILLS PEOPLES DATA without atleast a warning
> did you see anything as such in the bug listing?
Yes
> but even IF they did put safeguards in place, the fact that this is SEVENTEEN YEARS, no warning, functionality still enabled without ANY WARNING losing people data. unforgivable.
The software has change a ton in 17 years. Right? We can agree on this? (I mean it underwent a major revision in 2018, getting a lot of the codebase rewritten (like Firefox Quantum).
So let's consider a hypothetical situation. Suppose the problem was resolved in the almost 2 decades of rewriting BUT you still do not know what caused the bug in the first place and, consequently, can't reproduce it.
Do you mark the bug as resolved?
Now let's not sit in the hypothetical setting and act as developers. Some safeguards have been put in place (you can verify by looking at referenced issues). You've solved similar, but are unable to determine if these are the same problems or different problems (again, see referenced or use the search).
Do you mark the bug as resolved?
Your sibling commenter implied they would. Personally, I wouldn't. Marking as resolved is a promise to the user that it is fixed. But I can't make such a promise. I can't make any strong statement until I can reproduce. So yeah, it seems appropriate to me that it is marked as "unresolved" with steps "needs reproduction." That is an entirely appropriate status to me. You try as hard as you can and you implement as many safety features as you can, but you don't mark as resolved until you can verify. Unfortunately, this means issues go stale. Hell, there'll even be some noise like if a hacker or even just your dog deleted everything. We wouldn't want to assume the user is dumb and lull ourselves into a false sense of security, right? But you can only do so much.
*YOU CANNOT CLOSE A BUG REPORT IF YOU CANNOT VERIFY THE BUG*. That's the policy they are using. You may use a different policy, but that's the one they are using.
> YOU CANNOT CLOSE A BUG REPORT IF YOU CANNOT VERIFY THE BUG. That's the policy they are using. You may use a different policy, but that's the one they are using.
and then I would say: YOU DO NOT STOP WARNING PEOPLE UNLESS YOU CAN VERIFY ITS FIXED
(which ofc assume you bothered warning people to begin with)
We must be talking past one another. I'm (and others) are assuming they can't reproduce the bug. Assuming they aren't lying when they say so and assuming they've tried.
I mean let's take the trivial case. Assume user is dumb, deleted the files, made a bug report. Devs will never be able to reproduce unless user tells them they deleted everything 'on purpose'. That ends up with a permanently opened bug report no matter how much time you spend trying to fix the issue and no matter how many safety features you build in, right?
Okay, then yes I misunderstood you. I mostly agree but it's also been 17 years and what are the odds that the offending code still exists? What are the odds that it's TB's fault?
I know people report the issue but googling I can find similar complaints across all major mail clients.
I just don't think there's enough information to make strong conclusions and I don't think California cancer warning labels work. I think they teach people to ignore warnings instead.
Make no mistake - I am not absolving them of leaving this issue unaddressed lol just saying if it was easy they’d likely have handled it. It’s probably difficult or they just don’t know, so they keep putting it off and decided that not enough users are affected for real consequences (which is wrong to do)
nobody should fault the person who have coded the bug, unless someone can prove it was done on purpose. What I am suggesting is that the project as a whole has the responsibility to not just sit on data losing bugs for 17 years without warning users.
the fact that they choose not to, makes me perfectly OK with them being held criminally liable.
I would not want my email client to be relying on such brittle and incorrect heuristics.
A better workaround would be to keep deleted emails around for some time so users have the option to restore them if the bug triggers. But this has drawbacks such as potential privacy breakage (you meant to delete mails you don't want the chance that anybody sees it) or free disk space management (your local drive is overloaded and you want to urgently free up space) or ux confusion (this is a de facto trash but Thunderbird already has such a feature)
Ultimately, what needs to be done is make the code robust, make sure there are no race conditions, etc.
> Well, would you rather have a brittle heuristic lose all of your mail?
That's not what's happening. I wouldn't expect such an heuristic to be currently present. There is a bug, not something intentional.
> almost certainly better than doing nothing
No, because with such an heuristic, you add behavior that's difficult for the user to understand well and to work with. With such an heuristic, you will lose some mails and at some point the process stops in the middle. Which mails have you lost? What is "many" mails? 10? 100? What if my computer is fast and is deleting 100s of mails per seconds, losing all the mails anyway? What if it is slow and never triggers the heuristic?
If the heuristic does trigger, you end up with a mixed situation where you still have lost some stuff, but not all, and it'll be impossible to understand which ones. It doesn't fix the issue (you still lose email), just makes it even more difficult to understand even for the devs when they inevitable need to track down related issues. You really don't want to willingly add mechanisms that feel like they are non-deterministic: they are hard to debug, and hard for the users to grasp.
A way better solution is backups anyway: if you care not to lose your emails, you should be backing them up. From the beginning, your local TB mails are not a proper backup of your IMAP account because it's two-way synchronized so you need a backup somewhere else.
A still better workaround is disabling the move to local folder feature and make people copy and then manually delete mails.
Not saying your heuristic is not a good idea or clever (it is clever and could lead to further good ideas), just that after reflection, it should probably not be implemented. It barely starts to address the issue and adds complexity for everyone involved.
Except the bug was filed in 2008. Back then, Rust was Graydon Hoare's personal project that Mozilla wouldn't start funding until a year later. Rust was written in OCaml and the famed borrow checker wouldn't be in place until 2010. The first public release was v0.1 in 2012 and the first stable release 1.0 wouldn't happen till 2015. The language was very different back then with sigils, garbage collection and green threading as language features. So this bug was already bugging people when Rust was just an embryo that was still years away from birth.
Now even if we neglect the timeline, Rust only guarantees memory safety. If TB is deleting mails on the server too, then the corruption is happening over IMAP connections as well. Does that sound like a memory safety bug to you? Perhaps it is. But how do we eliminate the possibility of a logical bug that Rust won't protect you against, when nobody has any clue even now? And all that aside, if you're going to rewrite it in Rust, you might as well start a new project in Rust instead of porting an old design that may potentially contain a language-agnostic logical Heisenbug.
I'm not trying to be hostile here. I started using Rust in 2013 (I have 12 years of experience in a 10 year old language, and a bunch of repos that I can't compile anymore unless I compile the compiler from old commits somehow!). I wouldn't use C or C++ for any of these applications - I simply don't have enough competence to avoid the kind of bugs that Rust protects me from (despite being a hardware engineer with more knowledge about memory management than about type system theory). Despite all that, statements like this will only cause an unwanted backlash against Rust. Not that you're entirely wrong, but some people are so offended by such suggestions for reasons that are still under investigation, that they start a crusade against Rust [1].
You counter the facetiousness in a way it stops spreading and possibly even spark a constructive discussion is how I understand it (ESL though). I certainly observed this phenomenon myself (although as the person being facetious, I often feel like "I was joking, I actually agree, that's indeed what I was actually implying, but good you made it clear and explicit I guess")
I guess you'd disarm the person being facecious rather than the facetiousness, like you'd disarm someone about to cast you a magic spell.
At this point, answering to a "rewrite it in Rust" comment which doesn't go into details is a cultural faux pas, you just smile or roll your eyes and move on :-)
Looking at the various issues reported in this thread, it honestly seems that burning the entire codebase and rewriting it would be the best choice. Bonus points for using a modern systems programming language.
A better approach might be to feed all of this into an LLM to have it figure it out. If it finds a bug and has a fix, reproducing it might be easier and a test could potentially be written.
I don’t think LLMs are the answer to everything, but this would be a good test for newer generations of LLMs as they’re developed.
Worst case- it deletes all of your emails, but that would’ve happen anyway, right? =)
Reproducing bugs is a luxury and not even close to required for analyzing and fixing issues. Even if the issue is external (hardware, antivirus, etc.), the code can be changed to be more defensive and only ever delete the original when the new data has been successfully written and verified.
The problem is you can never close the bug report if you can't reproduce. I guess, you could, as the other commenter suggests, mathematically prove that it can't happen, but otherwise you're prematurely closing it.
How do you differentiate that you solved the bug and not a similar looking bug?
> the code can be changed to be more defensive and only ever delete the original when the new data has been successfully written and verified.
But this doesn't solve the problem.
- What if it is an upstream issue? They have to be connected, since they are deleting data. Maybe it is completely a bug on their end? Doesn't matter how defensive you are if the bug was "anytime an email has 'man man' and is pulled between 00:00-00:04 everything deletes" then what can you do?
- What if the user was hacked and the hacker just deleted all the data?
- What if the user was just dumb and deleted the data themselves. Either not knowingly or were embarrassed to say anything.
- What if it is another program on the user's computer that is deleting the data because of some weird unexpected collision?
I'm sure you can think of more situations that still won't solve the problem.
How do you close the report if you can not make strong guarantees that it is resolved?
A luxury? Not even close to required? You are not afraid of words! I'm not looking forward to receive a bug report from you!
Yeah, reproducing is not theoretically mathematically necessary. In theory you could prove your code is correct with formal methods¹. Now, nobody does this because it is impractical (borderline impossible), reproducing is in practice so useful as to be almost essential:
- it lets you study how your code behave in the problematic case and identify what's causing the exact issue the user is seeing
- it lets you check that your fix does indeed address the bug
I have indeed already fixed trivial bugs without reproduction cases from a vague description of a bug because I'm intimately familiar with the code and it immediately rings a bell: the cause is immediately obvious. But that's not the usual case.
> the code can be changed to be more defensive and only ever delete the original when the new data has been successfully written and verified.
What if the code is already designed like this (and I sure do hope it is currently written like that, because that's almost common sense, if not the only sensible way of moving something) but somehow fails for some currently inexplicable reason? It smells race condition to me.
In the case of the discussed bug, users have described a reproduction case that's not 100%. But someone will need to find a 100% reproduction case. Users, or devs. It will not be optional. You can't play a guessing game, attempt to fix the code and hope for the best. You might be able to actually fix the bug, but without much confidence. Best case, you'll be able to find a reproduction case after fixing the bug (that you'll probably use as a functional test), to prove you fixed the bug for this specific case you found. You'll not be 100% sure you addressed the user's case.
A bug can hide another one, so you could find and fix a bug, but the issue is still present in the user's case. You can only be sure with their reproduction case.
But I agree that it is hard to reproduce a race condition.
¹ which in practice applies to code of trivial size (static analysis), or consists in checking a model but not the actual implementation (model checking), or does apply useful checks but is not exhaustive and has false positives / negatives (static analysis), or does apply useful exhaustive checks but only on a limited number of executions (runtime verification, and we do have functional tests that serve a similar purpose in practice - and you'll actually need the reproduction case here so you have the right execution to check), or requires you to write your code in a specific language (stuff like coq) and you cross your fingers that this specific language's implementation is itself correct. In short: not applicable here.
> it is almost impossible to fix a bug you can't reproduce
It's also impossible to mark a bug report as resolved if you can't reproduce it.
You could have fixed the bug (especially since a lot of TB was rewritten) but if you can't reproduce the bug you wouldn't know it was solved only that people stopped reporting it. This is actually a common occurrence with long standing bugs.
I've updated my comment for clarity. The bug (which I've never encountered in more than 20 years as a Thunderbird user) is that users move messages to a local email folder, but the messages are deleted from the server without actually downloading them. At a minimum they should disable that operation. The guy that originally reported it worked at Sun and lost hundreds of work messages as a result of this bug. AFAICT the user wouldn't be affected if they did a copy of the messages and then manually deleted them from the server folder after confirming the copy was successful.
A very small number of users have this bug (and tbf, it's a really bad bug), and are unable to consistently reproduce it and it seems none of the developers have been able to (the seemingly random nature of the bug occurring is not helping). How is it supposed to be fixed?
You add more and more diagnostics (e.g. logging) in that area till you manage to track down the bug. Over several years this should be possible.
At that point you can either fix the bug directly or do it properly by first reproducing the bug (in a test) and then fixing it.
Said another way - If they can't reproduce it, they can't close it.
They may well have fixed it already, but without a way to reproduce it the only prudent behavior is to leave it open and wait for the next diagnostic file to be uploaded.
The way I've dealt with that in the past is putting into into Review or whatever the equivalent is, make a note ("cannot repro, but attempted potential fix in version XXXX, moving to review, please reopen if anyone reports this again) and then if nobody reports it still happening for x amount of time (e.g. 12 months), close it. Can always reopen it if it gets reported again beyond that.
That's not the only prudent behaviour, as the OP said, the prudent behaviour is to add more diagnostics and guards against the conditions that lead up to the bug.
Okay, let's assume more diagnostics and guards were added.
Now re-answer the above questions with these assumptions.
- How do you fix a bug you can't reproduce?
- How do you *close* a bug report when you can't reproduce?
Being generous here, we're assuming there's 17 years worth of diagnostics and safety guards added but through that time the bug still isn't reproducible. Let's try to answer the questions under these assumptions.
If you've added guards and diagnostics, then you close it until someone else files a follow-up, then it can be re-opened. There's no sense keeping it open unless there are ongoing reports of the issue.
> There's no sense keeping it open unless there are ongoing reports of the issue.
I think you've misunderstood. There's other options.
Let's consider this from a failure analysis standpoint. Here's our options
- You have incorrectly marked issue as solved
- You have incorrectly left the issue marked as unsolved
*Which error case would you rather have?*
The classic example of this design choice is with a safe. Let's imagine you are building a safe. If the safe fails, would you prefer that it fails into a state that is unlocked or into a state that is locked? The answer isn't so obvious, as it actually depends on how it fails, right?
A very common example is when designing skyscrapers. The choice is that when a skyscraper fails, there is a strong preference that it falls in on itself (think 9/11). Why? Because if it falls to the side then it takes out other buildings and can create a chain reaction (a related famous example being housing in Industrial Revolution London and fire...)
Your action is a valid option, but it is not the option that I would chose. I think what they did was perfectly fine. They left it open (to avoid tricking anyone to thinking it is solved when the status of solved is actually unknown) and marked with additional information about lack of verification/reproducibility. Essentially, it is marked as stale.
So we're back to the earlier question:
- How do you *close* a bug report when you can't reproduce?
Or we can frame differently: "How do you close a bug report if you have no indication that the bug was resolved nor exists?"
I don't think one more user report is going to be the difference that pushes them over the finish line after two decades. Let's not pretend the developers have been taking this bug seriously.
They still have it marked as unreproducible. What do you expect them to do if they can't reproduce?
So yeah, I do think more user reports can help. At worse, it will make them take it more seriously if there are more reports.
You also are falling to observation bias. You can see linked in the issue as well as by searching that there are similar issues that were resolved and marked solved. So I don't think they were just doing nothing as everyone seems to be assuming.
I'm rather surprised by the comments responding to this. A bit by the comment itself.
Why I'm surprised is... well... this is HN. We know that a bug like this is very rare, right? I mean otherwise who would ever use TB, right? But if it's rare, it's really hard to track down. There years of comments without people including system information. The reproduction steps themselves are "sometimes." It's HN, so we can assume users here program, right? How would you solve this use?
FWIW, I've used TB on Linux and OSX for years and never faced an issue like this. The only one I've faced is sometimes not being able to connect to the server and having to resend an email.
On the other hand, when using Apple Mail:
- messages routinely doesn't show me messages I can see in TB.
- Frequently sending messages from my phone doesn't go through or ends up double sending.
- Searching will pull up emails from a year ago, prioritizing them over the email I got this week and was actually looking for (e.g. searching foo@bar.com).
- I can't even tag emails!?!?
- Do filters even work? Holy cow how do people live without filters!? How do you deal with spam? How do you deal with all those noisy needless messages and newsletter type of stuff that won't let you unsubscribe or comes from domains or addresses you can't block because emails you need come from the same addresses?
- It straight up renders PDFs inline with no warning, helping spammers.
- There's no folders and everything is just all jumbled together in a mess. How does anyone find anything?
Idk, this is an annoying problem but I'd be surprised if I lost all my emails. I can recover deleted emails in Gmail and Outlook. Annoying, but recovering these (go to trash, click "restore") is far less time than what I'm saving on a weekly basis with TB.
I know these problems aren't on all platforms but TB IME has saved me a ton of time compared to using Gmail, Outlook, or Apple Mail. Hell, fucking Neomutt is a better experience than those three, which is insane. Trying to use them is like trying to use the internet without an ad blocker. How are we so bad at email?
I had email service expire on a domain and moved it to fastmail. Fastmail, obviously, did not have copies of the email I received before the move. But my phone did.
When I updated the configuration in K-9, it contacted the fastmail server, found that the mail it had locally wasn't also present there, and immediately deleted all my local copies.
That's not a "bug" in the sense of unintended behavior of the software, but it certainly seems like the software designer's goal is to hurt the user. I obviously didn't want that to happen. There is no scenario where I would want that to happen.
Email clients make some strange assumptions about what kind of actions make sense under what conditions.
I'd wager that this is marked as "by design" because it technically follows some IMAP spec. What the app does, purely on a technical level, is correct.
I've so often had debates and threads in issues where a developer entrenched in a domain has so much domain-knowledge (ie. tunnel vision) that "technically correct" or "by the spec" is the only correct way. I've been that developer in many cases too, in hindsight.
I got also bitten by this. While IMAP would allow for syncing, most MUAs don't have a local mailbox. Instead they have a cache and the offline mode means to put as much as possible in to the cache. But if you want an actual local mail storage, you will eventually have merge conflicts, because how do you deal with a message that is present locally and was on the server, but is no longer? Do you assume the user wants it deleted, or that it should be reuploaded to the server? Either way will be wrong. (Also if you reupload, it will get a new UID, so another MUA will again reupload it, i.e. you will get a copy per MUA.)
So if you want a mailbox sync tool, use a proper program for that like mbsync/isync. (But this can't cope with cross mailbox moves besides (not) propagating them.)
Yes, a spec is a technicality that, ideally, should be abstracted away completely (and alas, all abstractions are leaky somewhat).
It's another thing that got me interested in DDD. Where the user, domain, business and such define what things are called, how they operate, what events they undergo or emit etc. And not a spec, language or framework
And where e.g. "the IMAP spec" is a clear bounded domain, probably a service, an adapter or even library. Within that domain, "The Spec" dictates all the naming, conventions, logic etc, but where the border of this domain is another language. E.g. in a "MessageAdapterImap" something is called "EXPUNGE" with all the intricacies of what this means in IMAP. But in the outside it's e.g. part of a "cleanup()" interface, or whatever the domain calls it when it removes messages.
You make a good point but this is not a "strange assumption" by any stretch. You see Thunderbird has a "move" action. It allows you to move emails from a folder to another. Now somehow, this is apparently NOT implemented as:
1. Copy from source to destination
2. Verify copy has completed without issue
3. Delete from source
but... some other way? So when you try to move from a server folder to a local client folder by an innocent looking drag an drop, combine this with a poor network connection, a garbage tier legacy protocol like IMAP and decade old C++ spaghetti code, and you get this textbook 17 year old severity 1 bug that will never get fixed.
Of course, it isn't; they're relying on an unstable proxy for "copy has completed without issue" in preference to just checking whether that happened or not. Several rather angry users have pointed this out. It doesn't seem to have sunk in.
It's like a car whose engine randomly shuts down with a very low reproduction rate. Except with cars when this happened GM has recalled 30 million cars and paid billions of fines.
Emails to email client is an engine to the car. It is pointless without one and it is THE purpose of it. All the rest of functionality like fancy UI, filter, notifications, editor is meaningless if your emails were deleted without recovery. Even car without engine is more useful than email client with empty DB.
The big difference is a car with an engine that randomly shuts down is a life-and-limb safety issue. An email client that corrupts the database is extremely unlikely to cause a loss of life, even if the consequences are costly.
That said, even if the bug is impossible to isolate, it sounds like the chain of events that leads to it is known. They probably should disable the feature until someone is motivated to fix or replace the code. I'm sure that would anger a lot of people, but someone angry about the loss of a feature is probably better than someone who is angry at the loss of data. Especially given that the feature seems to be something someone would use to archive their mail.
That may be but i immediately uninstalled Thunderbird from all my devices upon seeing that its low priority and unassigned.
I wont be using any email client that can break and delete all my emails from local and the server. Why would i? It may be a lottery but it isnt one i want to play.
The fact that they see this as low priority shows theyre morons.
Who would say 'yes please' to an email client that might permanently destroy some of your most important data at random?
When i say they're morons, i mean it in terms of them not understanding the reputational and trust damage this can cause, via the thread, the low priority, lack of assignment, or word of mouth.
Far too focused on the engineering POV than the optics and trust/reputation damage. My kind of moronic, but still moronic.
It happens to me regularly. You can fix it by redownloading the message from the server using the "repair folder" feature, and I have backup, but it IS infuriating.
I have no good alternative to thunderbird, it does so much of what I want. But this bug is awful.
Note that this is why you use copy, check, then delete, instead of just "move" data, whenever it's important that the process works correctly
Even if the software doesn't have known bugs, I do it if the data is important enough and especially if I were to not have a backup (for example, because the storage provider takes care of backups and redundancy. I personally like to have another copy that I manage myself, but how many people have their IMAP emails or Spotify playlist data backed up for example? I do, but not many people I think)
I have been using TB on all operating systems with 8 or 9 users since 2006 and I never even once encountered this issue.
As a software developer fixing stuff like this is only possible if you can reproduce it or otherwise get logs, telemetry and similar things, otherwise it is pretty much just guesswork.
Granted given the severity of the consequences I would've chosen a more defensive move-strategy (e.g. one that deletes mails only once they have been copied verifiably), but that would have significant performance impacts in the 99.99% of cases where it works, so finding the real problem is preferable.
The truth is that if this happens to you regularly, that you are probably the prime person to gather more data on this. Call it giving back to Open Source software.
> As a software developer fixing stuff like this is only possible if you can reproduce it or otherwise get logs, telemetry and similar things, otherwise it is pretty much just guesswork.
As a software developer you should be able to reason about your code and work backwards from the observed result to investigate possible causes.
When a plane crashes or bridge collapses the engineers tasked with finding the cause don't just throw up their hands if they can't make it happen again.
Oh, wow. When I have to use Thunderbird, I never move emails. I manually copy emails to a folder and delete the emails from the old folder after that. I forgot why I have to do this. Now I know again. A lot of people here are speculating that this bug must be very rare. I maintained like 30 Thunderbird installations for other people. This bug bit me at least twice. It can't be that rare.
> On a several occasions (most recently today), Thunderbird has "lost" my mail messages that are in my inbox when I move them to a local folder. Effectively it corrupts the messages - they appear in the local folder as 1 KB messages with no subject or sender info. They are empty messages.
Apple's Mail app has had a virtually identical bug since Catalina; Michael Tsai's article on the issue currently has 636 comments:
After witnessing the bug myself, migrated to Thunderbird with Maildir enabled[1] for long-term storage; have yet to experience the issue despite a large database (>300,000 emails) and daily IMAP import to local folders.
I've been amazed over the years this has never been fixed -- it's very hard not to make jokes about the standard lifestyle of open-source programmers, that they don't consider this a priority (note: that's a joke, I consider myself an open-source programmer. I would hope that's obvious, but someone just bothered to sent me a mean anonymous message)
Indeed most of the time I already know the exact word I'm looking for; and most of the time I get non-exact hits making it so much more difficult to find the actual message.
Perhaps there could be an option to disable stemming completely from the inverted index, which would be probably easier to implement than a post-search filter (which in itself doesn't sound very complicated..).
But of course, it's open source, anyone could contribute :D.
The search in thunderbird is terrible compared to what we are used to today. Same for k9 (now thunderbird for android?).
Not only is the UX a horror, its results rely on all sorts of technicalities. I, as a software engineer, can understand that a mail has to be downloaded in entirety locally in order to have it indexed and then show up in the results. And I understand that sub-sub directories aren't really a thing in IMAP, so searching this-dir-and-everything below is hard/impossible and so on.
But mostly the search algorithms are poor. So much so, that I often rely on (rip)grep to find mails. Or in a few occasions wrote a quick bash/python horror to push all my mail into a meilisearch instance and then use this search engine to get the lists and filters that I would expect thunderbird to have.
Yes. It's open source. So "go fix it" is a proper reply. But that doesn't make a complaint about the state of the search feature invalid.
I don't know why you're getting downvoted for this. That seems like a pretty frustrating bug when generalised to other word stems. It's also pretty standard to prioritise exact matches when ordering search results so, again, frustrating.
One of my biggest bugbears with Microsoft Outlook has always been that its search function is terrible. If you can't find an email then it may as well not exist, and that's been a real problem on a regular basis during my career - particularly latterly when I was in leadership and necessarily lived in my email and calendar.
It's disappointing that Thunderbird has similar issues with such a fundamental function.
That is annoying. I wish I could advance search or better, use regex. Luckily there are plugins.
Worse though, in Apple Mail I'll search an email address because I got an email earlier in the week and the first thing it'll show me is an email I got from that person 3 years ago with the correct result a few down. I really need a better email client for my phone...
The filter/search feature in Thunderbird does not appear to have a way to search for exact matches. You want exact matches. First, identify if it can do exact matches and if so, expose to the user. Else, who wants to touch that code?
Nitpick: not all bugs have to be reproducible to be taken seriously. Defensive programming, and adding extra logging could be a mitigation to avoid future problems, or to help fixing them in the future.
Imagine you're writing trading software, you have an algo go haywire and it machine guns the whole order book, and then you refuse to put a "max order size" outside of the algo to stop it from happening again because you can't figure out why it happened in the first place.
Try telling a regulator or your boss that was your reasoning.
How many one-off band aids do you think should be applied for rare, never reproduced problems before you slap a “100% safe” label on it and ship it with the confidence of a bloated, cruft-ridden job well done?
Are you arguing in bad faith, or do you just not have any practical experience dealing with complex systems?
Even if the bug can't be reproduced, on the basis of multiple user reports the first step absolutely should be to add some assertions and logging around email deletion.
The point is not to give it a "100% safe" label, the point is to start narrowing down possible root causes. If the problem recurs again, you'll have assertions ruling out certain possible culprit code paths as well as logs displaying the values of relevant variables.
Kinda off topic, but I've been searching for good introduction and best practises for defensive programming, but never really found much. Any recommendations?
I don’t know of any real posts on it, it just ends up being kind of a “assume it’ll go wrong,” then figure out how you know something has gone wrong and track it down. Your starting point is, after an issue is reported, add a load of logs around places that seem like candidates for the flow. Over time, you get a sense of where things can break and you add that telemetry ahead of time.
I feel like this is sort of like reading a book to get better at self defense. Yeah, you'll probably pick up a few interesting things that may be of questionable use. But when you train in martial arts, you often get to go through the motions and put the moves into practice. Even then "real" fights will feel quite different and a lot of the stuff you've learned will likely fly out the window. If you've been in real fights a lot, you've begun to internalize your training and your moves become more like instinct. It's quite difficult to go from book knowledge to instinct without getting beat up a lot in between I think. The real valuable lessons come from building something that breaks and getting to fix it yourself.
This issue comes up in my role a lot, where I am often dealing with various environmental conditions and human factors, plus multiple integration points between various software and hardware systems.
The answer is that you keep working at it iteratively using a combination of logging, reporting, and defensive programming to systematically narrow down the possible causes. Sometimes you never arrive at a true root cause, but you get close enough that you can mitigate the problem and finally close the ticket out. At the end of the day, the customer/user doesn't care as long as it works.
However, what will really piss them off is telling them your hands are tied until they can reliably reproduce the issue for you. It's important they understand that you are working on it, and typically they will go out of their way to help solve the problem when they feel taken care of.
Why do you think it needs reproducible steps? It is obvious that the bug is still active, so in a way it is reproducible, just not in a systematic way.
This happens more often, for example when many services work together in an asynchronous way, and in some very rare situation, unwanted behavior occurs. To fix that, it is often easier to reason through the entire process, and to identify weak spots. It might even be a good idea to switch to a different paradigm to avoid certain bugs altogether.
For this particular bug, I would start by reading a lot, and ensurong that the bug is indeed not easily reproducible (by trying to make it reproducible of course). If that fails, I would continue to think about root causes for the bug, and possible workarounds that would work in theory. Then I would try to estimate the amount of work required, and the risk of breaking other things, and report that to those who like to decide on further actions.
And of course, as I know very little about the inner workings of ThunderBird, I would simply ask ChatGPT o3 or similar for advice. It comes up with a plan that seems reasonable.
No it doesn't. If I waited every time for obscure production issue to be reproduced in lower envs I would be fired... many times for clear and obvious incompetence.
Sometimes, you can add some additional steps, logging, change behavior in corner case a bit, either to get more understanding next time it happens or even mitigate it. Sometimes, you have plenty of tools and ways to act. In my experience, that sometimes is basically always if one cares enough.
What developers should do on such a critical and long standing issue is to offer an extension that victims can install to volunteer to track the bug. So they can click a button when things are fine to take a snapshot, and click another one when they encounter it.
If it was me running the project there's enough information in that thread to piece together an exploratory testing plan around the issue that might allow us to isolate it, and I'd set aside some time for the team to do that.
Whilst obviously not lethal, this Thunderbird bug sort of reminds me of the Therac-25 incidents in the 1980s. Very occasionally the machine would give patients massive overdoses of radiation. This bug wasn't easy to reproduce (thankfully) and turned out to be due to a race condition.
But of course, you can't find a problem if you don't investigate, and if it's a serious problem that's been documented then, as engineers, we can't just hide behind non-reproducibility as if it's some sort of magic shield. We have a responsibility to investigate and isolate the problem ourselves. If we don't do that we are effectively washing our hands of our own creations.
Not only that. Often mitigations can be placed even if the actual bug cannot be reproduced. Like many others in the thread suggested.
I've encountered several impossible to reproduced bugs in the past. And what I (or my team) would then do, is re-architecture (refactor) some pieces of software so that we could reproduce it. Like e.g. better logging, specialized layers/adapters/services, simpler logic, and -above all- better testability.
I explicitly do not, which is why my first response spells out that it’s hard to reproduce a bug when all your data is gone. If it is the case that the bug can be reproduced without user data (as suggested by the person I responded to, not me), then the developers should be able to do that better than users can.
You’re assuming users affected by this bug have control over the VM running their mail server. I won’t argue that it can’t be done, but it’s probably harder than we think.
I've been using TB for personal and work since it's first day and never hit the bug. I've never known any co-workers to hit the bug.
I'm sure plenty of other software that we use every day has similar severe bugs that occur just as infrequently.
I'll keep using TB. I'll also make sure to look both ways when crossing streets and won't assume that cars are going to stop for red lights because my chance of getting hit crossing a street is more likely than getting hit by this bug.
Yikes! I recently tried Thunderbird again because I was annoyed with gmail pushing AI subscription crap in the web UI. Guess I'll take that over this bug for now.
I was a thunderbird user many years ago. Seeing the article made me want to reinstall, and then this comment instantly changed my mind. Insane bug for an email client to have…
A useful use of AI might be to simulate thousands/millions of user sessions (via generating mouse and keyboard inputs), with instrumentation/logging switched on. Run them in various shapes of VMs until you hit the problem. Fuzz testing, basically.
Could they just make it not suck? Like the search system falls apart if you have more than a few thousand messages in a folder, not all that many by today's standards. The address book doesn't let you sort the addresses by most recently added, which is important if you reply to craigslist posts which use numeric forwarding addresses. So once you have more than a handful of them the are impossible to tell apart. It automatically makes new archive folders by year (2023, 2024, 2025...) which is kind of nice, except it shows them oldest first instead of newest first, so you have to scroll way down to get to the current year. The progress bar on the bottom looks like there is constantly something going on, and maybe there is, but it never finishes. Messages sometimes fall through cracks so you can't find them in any folder but you can sometimes find them with global search. And on and on. Stop adding new features or messing up the UI further until basic functionality like this works.
> Like the search system falls apart if you have more than a few thousand messages in a folder, not all that many by today's standards.
My Thunderbird installation tends a 20 year old work mailbox with tens of thousands of messages, and the search works the way I want even though I don't download the messages themselves to save some disk space.
If you are using your installation for a very long time, your local caches might have broken at some point, because Thunderbird was bad at that kind of thing, but now it's not.
For folder order, I can't tell anything about it, but 13 years of folders are just a wrist-flick distance on a 2K display, and shouldn't be much worse at an 1080p one, either. So, it might be fair criticism, but it's nitpicking.
I never experienced "lost messages" for a very long time, and my progress bar is currently sitting empty, despite that installation is handling 5 busy mailboxes.
You may need to delete some cache and local MBOX files and restart your Thunderbird, it seems.
> Like the search system falls apart if you have more than a few thousand messages in a folder
I'm in the inbox, I see an email with 'word' in the Subject in some of the most recent emails.
I type 'word' in the search box and TB finds some emails from the years ago.
It's even worse if it is 'word and some another word', in this case it doesn't even find anything.
It's like the developers... aren't dogfooding their own product?
Oh, yeah, we do now have TWO search boxes. Because that makes sense. And if you disable the topmost one, there is now 30px of wasted space you cannot reclaim. Because you definitely NEED that hamburger menu on the RIGHT side. On the desktop. On the 4k+ monitor. Riiight.
The two search boxes is bizarre. It feels like two rival programmers each wrote a half-baked search feature and rather than management telling them "Unify your two approaches", instead they said "Just throw them both in there and let the user figure out which one they want."
And if there were two driving wheels in your car, a one for turning right and an other one for turning left you would say there is no two driving wheels in your car.
A filter is different from searching. It only works on the current directory, it alters the view after it has been generated. You can also use it on a search.
Don't know about others, but I find the functionality useful and use them for different purposes. Searching is when I want to find random messages, where I don't know where or from when there are, the filter is for bulk processing and narrowing the current working set, beside the conversation level.
It is more like the steering wheel and choosing forward/reverse, sure both are for choosing the driving direction, but they operate at different levels and are used in different situations. I mean you could use the steering wheel for forward/backward if you want to. Using the gear to change the direction less than 180° is quite difficult, but not impossible.
Thing is, the 'filter' box can work as a filter and as a search box. It's even a simple heuristic if it should behave as a filter or switch to the search - if there is no result for the text entered in the textbox then switch to the search.
There is zero need to have two search boxes, it's just Mozilla wanted to copy-paste the idiotic solution of MS Office with a top-most search function. That's all.
Do you ever only use one of find and grep? I think they are very similar as the search and the filter bar. I mean you can replace find with tree | grep, not sure about the other way around, but it's probably also possible.
> There is zero need
I do, so it is not exactly zero and I would be annoyed to have them gone, because it is a huge time saver when handling thousands of messages.
> if there is no result for the text entered in the textbox then switch to the search
If the filter starts to draw in messages from other directories, that would be stupid and kind of defeats the point of having a filter in a first place. If you want that why don't you use the search?
> it's just Mozilla wanted to copy-paste the idiotic solution of MS Office with a top-most search function
I don't care where the search bar is placed and I think that functionality did already exist before the current UI, either via ^K or in a menu. I (maybe) do agree with you, in that I don't like putting widgets in window frames (that's for the WM) and prefer classical (CUA-like) menubars.
Can you please criticize the functionality itself? I can't comprehend why you don't see the point of a separate filter. Do you mostly keep messages in the INBOX?
Maybe my original word choice wasn't optimal, because you can consider filtering a subset of searching, but I do consider them to be different. If you rather you use a different terminology, that's fine, but I don't think it will change my point.
It's not a CLI. More so, redundant functions eats the screen real estate, which isn't getting taller on a non-mobile platforms.
> I do, so it is not exactly zero and I would be annoyed to have them gone, because it is a huge time saver when handling thousands of messages.
You sounds like I'm advocating to removal of both the search and the filter boxes.
> If the filter starts to draw in messages from other directories
sigh
You input something in the combined search|filter box:
If you got the result you need from this folder then you just do your thing.
If you did not got the result you need then press Enter which would start the search in the whole mailbox, just like the search textbox works now.
> I don't care where the search bar is placed
Great for you, but I care. TB interface was already far from understandable by both computer illiterate and computer literate and this is just another illogical placement what doesn't add functionality, yet wastes the space.
BTW, did you provided the support to anyone by the phone? Can you be sure what the person on the other side inputs in the right textbox? I can, somewhat, if there is only one. If there are two then 70% of time they would use the wrong one even if telling you it's the right one. I provided enough L1/L2 to know it well.
> Can you please criticize the functionality itself
Yes, there is no functionality need in the two separate textboxes for, essentially, one function: searching.
> Do you mostly keep messages in the INBOX?
Thanks, no.
> because you can consider filtering a subset of searching, but I do consider them to be different
Yes, they both are the methods to find some message/s what you can't just scroll to. And those 'quick filter' buttons near the current filter textbox are quite nice, btw.
My problem is what that search textbox is a clear import from the MS Outlook[0] and it was did only to mimic the other product, without a second of actually thinking if this is even needed.
Just imagine: what if instead of that search box that space would be used for... a filter/search combo textbox, along with a quickfilter buttons, just like today, but not wasting the space for nothing in the window titlebar.
Also I finally noticed what there is even a special combo to invoke the filter so it also can be used to differentiate the usage right away: ctrl+shift+k - filtering, ctrl+shift+f - searching the mailbox.
Just for the sake of it I did a poor man's mock-up:
And, uh, just one more thing: when you do search in TB you are brought to a separate tab with the search result. There is zero need to the search input to stay in the current search box. It's literally useless.
[0] if never even saw it then just search for the screenshots.
EDIT: and about 'heuristic' - there also two ways to do it:
1. just have a toogle buried somewhere, to enable/disable autosearch
2. just do the search automatically, with a low priority and find a way to notify the user what this are results from the other folder. Can be as simple as '--- results from the other folders ---' line.
It is not about the invocation, search and filter bar differ in the same way as find and grep. Even if they are similar, they are still different enough to not benefit from unifying.
>> I don't care ...
I mean that as: I don't object to a different placement of the global search bar.
> My problem is what that search textbox is a clear import from the MS Outlook
I don't know the history and which program's search box predates the other. Note, that the search bar predates the current UI change, see below.
> not wasting the space for nothing in the window titlebar
As I have written earlier, I also don't like UI in the titlebar. But neither do I like yet another omnibar.
I think I should start again with describing how I perceive the functionality:
There is a global (across accounts, folders) search UI, which is a whole different "window"/tab, with different kinds of logical search parameters. The result view is displayed paged, with time, account and folder graphs, but can be converted to a standard message list view.
This can be used when you have no clue and just focus completely on searching random content. The global search bar is just a "button" to open this UI and prefill the search box.
Suppose you have an already existent curated working set of messages. Then you want to select a few and operate on them. This is what the filter bar is for. You don't need to change your focus to a different UI element, it is just a way to pre-select your working set or temporarily restrict your view to focus on just some messages.
Note, how a lot of functionality is in adjusting the UI to support the state of mind of the user.
Enhancing the filter to work across folders is maybe a feature, I don't have a use for that yet. It doesn't makes sense with the current placement, because that indicates, that it is in the current folder frame. I wouldn't implement it like you, I would probably add a checkbox, but that's an implementation detail. But then getting rid of the search bar/functionality is just that, removing functionality.
The alternative way seams to be to merge the filter into the search bar, but that either amounts to the same or means adding a filter to the search to limit it to a specific folder, but this already exists.
> You sounds like I'm advocating to removal of both the search and the filter boxes.
That's because trying to merge them and removing the other, results in getting rid of one of two useful UI-flows. Currently it is also possible to first search and then use the filter on that. This also won't be possible when you merge them.
> Did you provided support to anyone by the phone?
Not yet for TB, but I give you that this might result in confusion. I don't think dumbing down the UI to solely improve tech support over the phone seams worthwhile.
> ctrl+shift+f - searching the mailbox.
That's yet another thing entirely. This invokes a server-side search as opposed to the two client side functionalities we are discussing now.
Interestingly the height is less then any of your mockups. Maybe that is, because I don't have any scaling factor. My display is 1366x768, that results in a maximized window size of 1365x707. So this amounts to 32.5%, yes that is quite some space. I think in practice I tend to just mentally fade out anything above the menubar.
As I got curious I reinstalled version 102. I remember feeling disappointed about the upgrade, because there was suddenly a lot of useless whitespace, but I didn't remember anything concrete. Here is how it looks: https://ibb.co/n8P2CjB4
That only occupies 25.5%, which seams better. I am surprised how you can now select more then one item in listviews for example in the folder pane and the subscription window. This is a huge deal, because selecting hundreds of folders individually to subscribe to them is just really annoying. I think I definitely like this UI more and don't know why there was this huge UI regression. It also seams to startup faster.
How are the numbers on your computer, as it seams even worse then on mine? Do you still have the same objections to the old UI?
The search is really limited by the storage backend Thunderbird is using. Would really love to see something with full text search support, like sqlite.
My workaround for Thunderbird search is to open the Outlook web client, search for what I need, find it in a fraction of a second, do what I need to do, and close the web client. Terrible "solution" but the only one that works.
Basically a cross-platform Thunderbird replacement whose sole goal is to "not suck". Full-text search is entirely client side (not via IMAP) and returns results in single-digit ms.
>Full-text search is entirely client side (not via IMAP)
Setting up server-side Xapian full-text search and disabling the crap client-side one in Thunderbird was one of the best improvements I made to my email usability. What makes your client-side search better? It's usually not speed I'm looking for, but rather precision, such as double quoted phrases (sorely missing from Thunderbird's client-side search), filtering by a mixture of things, etc.
I wish more clients had an option for server-side-only search (looking at you, iOS Mail.app) and/or had a nice UI for it (ctrl+shift+f dialog in Thunderbird is janky but gets results)
The fastmail web client is actually decent as such things go, and its search works ok. When I have trouble with Thunderbird search I sometimes log into Fastmail and use their web client.
My thoughts exactly. I used to use Thunderbird back in the day and I would like to be able to go back to it. I can’t even remember anymore what turned me away at the time. I’m always curious to see how it’s progressing though, and screenshots of a modern UI would probably get me to download.
When I see a website advertising a product without actual screenshots, I usually assume the product is absolute garbage. But that's for commercial products normally, not free software like Thunderbird
«Manual Folder Sorting» — first, they broke 3rd party plugin for that. Next, author (not member of official Thunderbird team or employee of Mozilla) of this plugin spent more than 1 year pushing this functionality into base.
Now they highlight it as big deal in new release without mention volunteer author of this BASIC feature which should be in mail client FROM VERSION 0.0.1!
It is pity, that Google Mail is «good enough» and it killed development of good desktop e-mail clients.
Thunderbird is best what we have (Cross-platform), but still very bad, and after killing off XUL plugins cannot be easily modified.
They exists for 21 year and now announce manual folder sorting! There is no support for Sieve (3rd party plugin? Dead after removing XUL)! There is no way to store folder settings as IMAP properties, and if I have two installations (on laptop and desktop, for example) I need repeat same setting or folders again and again — including selection of identity per-folder (again, not native functionality but 3rd party plugin, thanks, it is alive now!). No true message templates (per-folder, per-action, per-identity), only lousy "signature", broken in-line quoting in plain text messages, etc, etc, etc.
> It is pity, that Google Mail is «good enough» and it killed development of good desktop e-mail clients.
You have to remember that when Gmail was launched it was considerably better than most desktop mail clients at the time.
It had auto-complete for who you wanted to email (prior you had to manually type their email address).
It came with an eye watering amount of storage (1 GB).
Worked from any computer (when POP was common and downloaded the emails locally to that desktop computer).
And more.
So it wasn’t so much that Gmail is “good enough”. It was more like desktop clients saw how much better Gmail was and didn’t think they could compete - also given that Google provided the hosting as well which allowed for tighter integration - something a desktop app alone could ever do.
Note: I'm not saying I think Gmail is a great experience. For web, I personally really enjoy Fastmail and for desktop - I surprisingly have grown to like Outlook. What I am saying is that when Gmail was launched, it took a lot of wind out of the sails of desktop mail app creators.
> You have to remember that when Gmail was launched it was considerably better than most desktop mail clients at the time.
It was not better for me than old FIDONet GoldEd 2.8x! It didn't (and doesn't) support proper threads, it supports effectively only top-quoting, it didn't (and doesn't) understand mailing lists in any way, it didn't support forward-as-attachment in both ways (now it supports it, though). Its filtering is still much more cumbersome than even Thunderbird one, not to say Sieve, and can be done only from web, but not from Android client. It doesn't support any crypto natively, both PGP or S/MIME.
Their are all features which I'm using daily (maybe, crypto is not daily, but still use sometimes).
Only good thing is labels, which is more flexible than tree folder structure. And, yes, full text search, obviously, as it is Google product.
As far as I remember, Thunderbird was not much worse than it is now, and it is supports most of this (though, quoting was and still is very weak, problem solved in FIDONet in 1990s!).
To be honest, I don't remember what was situation with address book and address autocompletion from it in Thundrbird before GMail, maybe there was none (but I will surprised, as, again, it worked in old TUI-based FIDONet client for DOS and OS/2), but this feature is trivial to implement in desktop app, and it could use LDAP or another centralized directory, not only addresses collected from your mail.
It was better than any web-mail, for sure, but better than desktop client? It is debatable.
1GB of storage is question of hosting, not client.
Update: Add to it modern gmail hate to self-hosting mail domains, and I could say that Google kills email as federated, free, non-vendor-dependent system. It is not surprise to me, of course, but still.
How do you do Gmail style threading view in thunderbird ? They changed the game wrt email display and 20 years later I still don’t know how to get thunderbird to do it.
Gmail:
- see all email bodies for a single conversation in one long list , like a DM in a messenger, with smart hiding of quoted text so you only see new content
- in your inbox / archive view, mix both sent and incoming emails in such conversations, so I don’t have to toggle between Sent and INBOX or Archive
I would be happy with just one of these two but I genuinely can’t hack it.
I would personally go as far as to say: any email client which doesn’t do this, is wrong.
> How do you do Gmail style threading view in thunderbird ? They changed the game wrt email display and 20 years later I still don’t know how to get thunderbird to do it.
I hate it. It hides texts, and I lost answers in this view more often than I want to admit. If it is not ping-pong conversation (I wrote you, you answer, I answer at your last answer, etc), but discussion between 3+ people where different people answer to different messages, gmail view is total mess when you cannot understand who answer to what. As I said, it doesn't support threads, only messenger-like conversations.
Any e-mail client which doesn't support tree view for threads is wrong.
You can put answers to same folder that message your answer in (any?) sane e-mail client, Thunderbird is not exclusion.
Update:
> smart hiding of quoted text so you only see new content
I've missed text hidden by mistake due to some formatting quirks more than once. It is solution in search of problem: proper quoting doesn't need any magic.
> How do you do Gmail style threading view in thunderbird ?
I used an extension once but it broke at some point.
> - see all email bodies for a single conversation in one long list , like a DM in a messenger, with smart hiding of quoted text so you only see new content
Or not so smart hiding of "repeated" content like say an image with a different URL but hey the rest of the <img> tag is the same so close enough for Gmail.
You have to remember that when Gmail was launched it was considerably better than most desktop mail clients at the time.
There was never a time when GMail was better than plain old Outlook, but this is coming from someone to whom IMAP has always seemed like a really terrible solution in search of a nonexistent problem. My email database is important to me, and worth managing locally, as this thread more than adequately demonstrates.
Boss at the time: "You should quit using that old POP3 crap, and switch to IMAP. It's awesome." Boss a half-dozen times over the next few years: "Hey, can you forward me a copy of that email we got from XYZ a couple of years ago?"
If you're going to keep them all locally anyway, what's the point of IMAP?
(Admittedly my judgement was formed at a time when one user, one device was the rule. I suppose if mobile access to email is important, there's a good argument for keeping the data server-side. I solve that problem with VNC.)
I’m curious, do you log onto your computer from your smartphone in order to access your email?
Usually. If I'm going to be gone for more than a few days, though, I'll shut down the main PC and run Outlook from my laptop, which is set up to leave the messages on the POP3 server so they'll get copied into my master .PST file when I get back.
20 years means that either you maintain your own IMAP server and do a good job of it, or someone else does. In my previous company, there was always some reason why people couldn't put their hands on older emails. Meanwhile, my current .PST file goes back to 2007.
> It is pity, that Google Mail is «good enough» and it killed development of good desktop e-mail clients.
Microsoft Outlook has a very large market share in the business world. There is an old and a new GUI design version, and you can run the app, or use it online.
I don't like the presentation of the individual emails especially, I find the thread-view hard to understand, especially on mobile, but it works. Personally, I would have preferred the older folder presentation designs of 20+ years ago, for me this app is trying to be too clever - in both the old and the new GUI version. However, it is just so very widespread. I have to use it because everybody else in the company uses it.
They support a huge amount of scenarios and edge cases that many businesses now depend on, combined with all the Microsoft server side and infrastructure stuff they have of which the emails are just a very small part now.
I hadn't really used Gmail or Google products much, until I started at my last job, which was balls deep in the ecosystem. I loathed Gmail. One of the worst email "clients" I've used. After toggling a load of stuff in its settings it was usable, but dealing with email was a low point of my work day.
New job is Microsoft based, so Outlook, and I haven't used that in 20 years, so it will be interesting to see how enshittified it has become. I will have to run Windows on my work pc, which I'm not looking forward to.
I’ve been using Thunderbird more and more over the past few months. I’m glad it’s finally getting some decent attention. I’m especially curious about the new account management in 140. I couldn’t add my iCloud calendar easily before, hope this rectifies it.
If you haven’t given Thunderbird a shot yet, you should.
I've been using a fork of Thunderbird called Betterbird (https://www.betterbird.eu/) on Linux, mostly because I want to be able to minimize it to a systray icon. I know there are extensions like systray-x and birdtray, but I was having issues with these on Wayland. I wonder if this new version of Thunderbird finally added systray support on Linux/Wayland.
That's... not a bad thing, though? Terry was an extremely competent engineer and programmer who designed his software to be as user-friendly, well-documented, and performant as possible.
I have conversed with Jörg, and he is blunt and fair in a good way (code itself is emotionless, after all). And, of course, he is highly competent. I have also conversed with several Mozilla teams, including Thunderbird, and the experiences were universally horrible, as in they lacked core competency. Naturally, YMMV.
There is no mention of sync functionality. I regularly use 3 different PCs and I cannot sync settings easily. It means I've give up using Thunderbird on all but one of the PCs.
They've also made the usability worse in recent versions and are copying the insanely annoying context menus in Windows 11, which cannot be reverted.
You need to export the profile and re-import on each machine. If you make any changes on one machine you want to see it reflected on the others.
The profile import is a bit iffy and there was some odd issues with downloading profiles over 2GB IIRC, the last time I did it (which was over 2 years ago).
There seems to be a lot of focus on features that IMO that I couldn't care less about and some outright stupid UI decisions like the context menus being changed after 20 years for god knows what reasons.
The result was that I just gave up and use Thunderbird on one machine and web-mail on all the others. I suspect I will just drop Thunderbird as a result.
I guess they mean that they want their accounts to be synced (setup is annoying tbh), but also things like signatures and so on.
I normally just manage it myself and I'm extremely happy to do so, as I consider it like my dotfiles, but I understand where the parent is coming from - settings sync is becoming common. (Chrome is a good example).
Also gave up Thunderbird years ago because of the same reason. Just wanted something stable and chose Spark. Works on every device, not a problem for years.
> While we can’t change the universe, you can now get the latest Thunderbird features as they land, instead of once a year. Switch to Thunderbird Release and enjoy monthly updates with the same dependable stability.
Does this mean anything or is it some sort of marketing gobbledygook? We can now get features faster by using the latest release rather than the ESR – but surely non-ESR releases have always been available, so this was always the case, not only now suddenly?
Also, the "dependable stability" we enjoy with the ESR release comes precisely from the software not constantly changing underneath us, i.e. from not getting new features every month.
I have not used Thunderbird in 15 years, but I'm desperate for a decent email client. I've used Spark, Mailspring, Airmail...but I keep coming back to the MacOS Mail app. Any active users of Thunderbird who chose it over the default Mac mail client? Does it have a unified inbox for all your accounts? Dark mode looks neat, at least.
That's good to know. The Mail app shortcut keys don't make a lick of sense, but I don't mind that as much as the inability to zoom in on images in a message. No pinch and zoom on an image is diabolical in the MacOS ecosystem. Do you miss anything about Mail now that you're Thunderbird full-time? Anything you prefer in Thunderbird over Mail?
Is Oauth accounts with an authenticator working yet? I desperately want to use it at work, but we have O365 with Okta and Yubikeys in front of it, and Thunderbird can handle the Okta but won't prompt for a PIN for the Yubikeys.
The only feature I am missing in Thunderbird is “group by sender, sort groups by latest receive date in group”. I don’t remember what client I used that had this (outlook, perhaps?) but for me it works so much better than other arrangements:
You still see all the latest correspondence, but also immediately all previous correspondence from the same sender (if you expand the group) whether or not it’s a reply thread.
No thanks. We're still sticking with version 102, the last release before the ruinous "Supernova" redesign which nobody asked for, when it became apparent the project was being abused by "UX" kiddies looking to bloat their Github resumes. We're just thankful that some wiser developer had previously added the "allow-downgrade" option.
(The download link is easily found there, as well as git repository and forum links.)
It's based on UXP (the Unified XUL Platform) and is thus related to the Pale Moon browser (which doesn't bother me). I've been using it on Linux as a way to have an "older Thunderbird" look and feel, e.g., I have real scrollbars, and the "Send" button didn't mysteriously vanish from the Compose window with no way to get it back upon some "from the ground up redesign" upgrade.
Whenever Thunderbird makes its way to the front page of Hacker News, I always re-download it and hope that I can use it.
Every time I've ever tried it (spanning around 30 installs over the last 15 years), I've uninstalled within a week to a month, due to sluggish UI, phantom unread emails, crashes, and text formatting issues.
I do it because I believe that one day Thunderbird could be good. Today could be the day - I've installed it, added my accounts, and it looks like the developers have made some significant improvements. I'm not talking about fancy new features, instead I'm talking about the small nitpicky problems I've had whenever I've tried to use it.
For example, this time I installed, I didn't have to go into a hidden settings menu (here be dragons) to make new emails default to the top of lists. My replies are now made above the original message. Fastmail doesn't throw a wobbly when trying to add email, calendar and contacts with the same password.
Maybe today is the last time I install Thunderbird?
I don't have any of those issues, besides perhaps crashes but the last one must be two years ago (I remember because we're always watching for exploits coming in). Maybe nobody else has these issues you mention either. If you want them to be fixed by the next time you install, have you considered reporting the issue and seeing if there is a volunteer is willing to fix it for you?
I have used Thunderbird in the past, but ultimately gave up.
I am currently on google for my private email, and for other reasons tied into MS / Office365 anyway for my business so decided after having my business email at my internet provider initially, it all was just not worth the hassle.
95% of my business dealings is with companies that are on office 365, and especially the calendaring and RSVP'ing just kind of works in outlook.
I am still keeping an eye out and hope to be able to move to some solution which unifies it all, preferably on a nice open standards, open source solution for email, calendaring, and contacts.. but the fact is that customers pay my bills, and I grew tired of all the account issues, syncing issues etc with trying to have it all in Thunderbird.
I find it a sad state of affairs though, the amount of engineering time, energy, and money spent on building semi-walled gardens and at the same time building ladders to climb those same walls, all while never achieving an actually smooth experience between my various email accounts, my calendars, on my laptop and phone alike.
> Don’t like the order for your custom folders? Just click and drag to arrange them exactly how you want.
At last. Thank you.
I've been using an add on for that for a long time. It stopped working about one year ago because of some change in TB. I managed to survive but I really look forward to the update to 140.
Thunderbird is still the only calendar software I'm aware of with a "Multiweek" view instead of the awful "Month" view all others provide. The only calendar to have caught up to 20th century technology (Apple almost gets it, but not quite).
The person in question has a relatively rare medical condition, for most people dark mode reduces readability as a darker screen leads to more pupil dilation which causes halation. (which you can test out yourself if you stare at dark mode text and then look at a bright surface, you'll likely literally see a halo of the text).
This is worse in people with astigmatism, which is about 35-50% of the population. Dark mode defaults, as on that website, need to die. Most of the time they're used because people use their digital devices like goblins in a cave and don't light their rooms properly, or configure their brightness settings correctly.
Surely this can't be that universal, right? I will have to do this test at some point. I have astigmatism but I find the default bright version of websites frequently painful to look at. I have no clue why but I need the dark versions.
My strategy has been to use light mode all around but I have f.lux set to about 20% strength all day long. I also have my monitors dimmed a fair amount unless I want to display HDR. It also helps to have a bias light behind your screens if you can.
My goal was to get rid of the 2pm eye twitch and I've mostly got it.
If websites are generally too bright, you can save energy as part of increasing comfort by configuring your display to put out fewer nits (reduce its brightness setting). Usually people have the opposite problem, especially if there's direct sunlight on or near the screen, so that's probably what the factory default optimises for
First time I hear someone describe nausea from dark mode. Quickly looked astigmatism up on Wikipedia - isn't that something glasses fully correct? I think I've got this as well, but not sure, I've just always had glasses and take whatever they measure to be the best possible lens
(Of course I critically evaluate the measurement, like one time I actually couldn't read faraway text with what they were proposing whereas I could with my old glasses. But I don't know the exact values or terms for the different defects, I think my eyes have at least three different issues including something about rotation as astigmatism apparently means)
I guess what I'm asking is why you don't have glasses. Are they too expensive in your area, or the defect only very minor so it doesn't impede safety when driving even on highways? (Then I'm surprised you get nauseous though, since I don't when I read anything without glasses, regardless of dark or light mode.) Or if you do have glasses, is this still an issue while wearing them? If so, any idea why?
I have glasses. They greatly ameliorate the issue, but not completely. My prescription is a single number which I don’t believe has the necessary granularity (I think, intervals of 0.25) to express the exact prescription I need. I also suspect that astigmatism is a deformation of parts of the eye that cannot be expressed with a single number. It’s possible I should have gone to an ophthalmologist instead of an optician in a mall but that’s what I did.
Also I generally don’t wear the glasses unless I’m working (with a computer of course) or driving. I also have myopia, but both my astigmatism and my myopia are mild. The problem is much more severe when it’s dark, so I always wear my glasses when it’s dark and I very rarely wear them during the day. I must always wear them if I intend to use the computer for a long time, though. Especially if I’m staring at a terminal or whatever else with white letters on a black background. But I don’t need them to read (black on white, not too far away) or to use my mobile (always closer to my face than my monitor).
Judging the distance/speed of other cars during the night without glasses is simply impossible despite my mild prescription.
This is very interesting, thanks for sharing details. A friend with strong corrections in their glasses always mentions they feel like they can't see much in the dark, not as much as other people anyway, but we've never been able to quantify it (that they don't see something that I do). That you always wear them in the dark sounds to me like it's indeed more important to correct this effect for dark backgrounds, which I had no idea about
Another comment I saw in the meantime, https://news.ycombinator.com/item?id=44520306, proposes a mechanism for why one might have what I'd call ghosting if it were a computer screen (apparently it's called halation for eyes). That that can lead to nausea or generally feeling like things swim together and you can't see as well makes sense, this might explain a lot
I'll mention this to the friend and maybe we can do some tests in the dark with moving objects rather than just "can you see that thing there". Maybe after all these years we can get to the bottom of this issue they've had all these years :D
It’s not ghosting, it’s halation as that bloke said. Bright things do not leave a trail, instead they are just blurry.
If I see a white LED in the dark, the LED shows some sort of smear at a certain angle and with a certain length. The length of the smear decreases the closer I get to the LED. It doesn’t change ever, even if days pass, because it’s a static deformation inside my eye. It does not leave a trail if I look around or if I move the object with the LED.
This also applies to white letters on a black screen. They are smeared at an angle. If I’m far away enough and/or the letters are small enough the smear is so large that they make it hard to read and make me nauseous. That’s why I ended up buying the glasses.
Oh! I see, I guess the "then look at a bright surface" part of that other post made me think of that an image stays with you for a short time (a ghost image), but I get what you mean now
Technically it’s not really hypocritical because the author never claimed that a lack of light mode is an accessibility problem.
I think it’s also notable that websites being accessible isn’t really about being tied to a specific theme, it’s about being compatible with accessibility tooling and standards (screen readers as an example). There are plenty of CSS manipulation tools that can make a website look whatever way you want.
Then all that'd apply to sites not having a dark theme, undercutting the author's point because he could just use stylus to.make his own dark theme for sites.
I love Thunderbird, but the compose message window is just shit. It allows to sslect text type like body, paragraph and so forth - but it always resets to paragraph for me, which leads to weird spacing between lines.
I tried to add a new mail account to Thunderbird after upgrading to version 140. Unfortunately, it shows an error message after merely asking for my name and my email address and then hangs in an endless animation.
Since some months somehow the windows are weirdly aligned inside Thunderbird, like the attachment bar is cut off at the bottom.
I might be connected to my Awesome WM but I haven't changed anything on this side.
So we have "OS-native notifications" now. Does that mean we finally get a tray icon? Or do I still need to keep Thunderbird sitting in the taskbar for that?
If not, I guess I'll be keeping birdtray installed for now.
I used TB for a decade or more, then in the end quit, because it was bloating too much. It was a browser doing email, not an email client.
I then used Claws for a while, but came to really dislike it - lots of small UI issues.
Then I wrote my own email client in Python, Postgres for store, Apache/HTML front-end. That's been fantastic. Python does all the heavy lifting, you need to design a decent database.
Now I add features as I need them - few days I added the ability to specify how many times an email should be sent, when you need to spam the recipient for some reason (say, a company which is spamming you and is not responding in a reasonable or timely manner to GDPR requests).
The basic client design I've not seen elsewhere - but I've not used many clients so it may very well exist. There's a single inbox of email, and you define sets, and a set defines what is shown. So you don't move emails around between folders, you define what's shown, and you can have multiple sets concurrently - so for example, "inbound", "last 24 hours".
There are also a bunch of other small features which I've had in time for a long time but have never seen. For example, the from/to addresses have the localpart and domain separately, so you can order by domain. There's immediate in-page filtering, too, for each column, so you can just enter a few letters of what you know is the origin domain and bingo, there you go.
Apple Mail. It covers the bases, doesn’t try to cram too much into a single app, and doesn’t lean into badly aging UI trends.
I’ve tried Thunderbird a few times over the years (including post-redesign) and it’s always felt clunky and kinda awkward. Firefox somewhat outgrew that but Thunderbird never did.
If I were to use something else, it’d probably be MailMate which is a lot like Apple Mail but with even fewer frills and more optimization.
I wanted to love Thunderbird, used it for years then a bug [0] literally deleted all my emails. I regularly see updates of people understandably raging on the ticket :( It's a bug that literally deletes user data from both the server and the client without warning. It's been open and confirmed for 17 years straight. It could happen to you. How is it not top 1 priority to fix it?
[0] https://bugzilla.mozilla.org/show_bug.cgi?id=462156
I too think they should drop everything else and work on this bug. But an example of how these kinds of bugs are tricky:
I have a similar bug at my job: Sometimes browsers delete our extension's database, or otherwise corrupt it. It's been an issue for years, but no one has been able to reproduce it. It's probably a 1 in 10 million bug.
I think it's a hardware bug. My "fix" was to backup a small, but key, part of the database to a separate storage mechanism browsers let us access. When the issue arises we can now try to detect the missing data and restore part of the db.
BUT! If this is actually a hardware bug, there is a chance that this additional database write will cause this big to occur even more often, as we now have to write to storage twice as often!
> Sometimes browsers delete our extension's database ... but no one has been able to reproduce it.
Are any of the bug reporters using Vivaldi? As for some reason that browser allows (and enables by default) clearing extension storage when clearing history/cookies via Delete Browsing Data.
This is something the Stylus addon dev noted when a user was reporting the addon wasn't remembering their settings and it was because the user had unwittingly wiped the extension storage due to the browser defaults.
(I actually use Vivaldi myself but virtually never use that feature so was unaware of the behavior until reading about the bug report)
"Delete" was an over simplification. The database seems to be there, but the data isn't. Dozens of engineers over the years have tried to find a way we could have accidentally cleared the data, but not the keys.
No user that has reported it has been willing to share their database with us (chrome stores it in a standard leveldb), as it contains private information.
But good to know that about Vivaldi! I didn't know that before, thanks!
Thanks for linking that. I've tried Thunderbird a couple of times in the past and quite liked it, but that thread has put me off using it forever.
Even if the bug is fiendishly hard to track down and reproduce, you'd think there would be some additional safety checks they could add that would at least let it fail with an error message instead of actual data loss.
Its not unlikely that similar problems exist with other mail programs but since they are closed source you dont see it
People would still complain about them on forums, often ones run by the company who makes the client! I'm often reading threads of issues on Apple's public support forums. Being open or closed source has nothing to do with hearing about problems.
Closed software doesn't have open bug trackers, so there's no systematic way to find out.
An acquaintance of mine were twice hit with a bug that corrupted Word documents stored on iCloud if editing on her iPad. Searching online yielded others with the same problem from more than one year ago...
I was able to find complaints fairly easily. I had them listed but HN ate my comment. Search "Missing emails" instead of "delete all emails" as the latter tends to provide instructions about how to bulk delete.
Also, pay attention to observation bias and userbase bias.If my dad faced this issue, he'd never post online. He'd call me or go to a computer repair shop. That's what your average user will do.
Open Source users tend to be a bit more tech savvy. There's that famous article about Linux gamers reporting way more bugs than average users and how it can be accidentally misinterpreted as "why develop for linux?" These frequency biases are a big part of this. Pluus, OSS tends to do better bug tracking.
I think you've just made an assumption about a bug that was reported 17 years ago. Assuming nothing has been done since. It looks like they can't reproduce it, *making it impossible to mark as fixed* even if it was. But I wouldn't assume nothing was done.
Also remember that Gmail, Outlook, and others are in play here. They also maintain trashed items for 30 days, making it easy to recover. As the provider, they shouldn't make it easy to mass delete things either, right? TB is just the interface, frankly, I'm not sure I know how to permanently delete emails with it. I'm not sure I can. But the interaction here should result in multiple lines of defense.
It's not just one report from 17 years ago, it's 194 comments with the most recent one from nine months ago. It doesn't seem like mitigation steps have been implemented.
See, you don't understand. Fixing the bug before reproducing it would violate the process.
Well, I do think the thundebird team should investigate and fix this. But it is almost impossible to fix a bug you can't reproduce and have no clue why it might be happening.
> But it is almost impossible to fix a bug you can't reproduce and have no clue why it might be happening.
No, not at all. It's very easy.
This bug involves taking an inappropriate action under corrupted conditions. You don't need to know how those conditions arose. All you have to do is check whether they currently obtain, and - if so - refrain from taking the inappropriate action.
For this bug, that looks like this:
1. When we're executing a "move"...
2. Before deleting the original messages...
3. Check whether the copies are identical to the originals...
4. And if not, delete the copies instead of the originals.
At this point, the bug can't occur. The "root cause" bug, where your buggy logic says that you copied a bunch of messages even though you didn't, can still occur, but it can no longer delete any messages.
So…do it. Sounds like it’d make a great case study that would get a person tons of attention and praise on HN, a real feather to put in one’s cap.
Literally nothing stopping anyone in this thread from opening a PR with this reportedly “very easy” fix that’s eluded developers for nearly two decades, and is so terrible folks swear off Thunderbird forever because I guess for email very basic rules for backing up data don’t apply (or something?) and/or Gmail and Outlook are implicitly trustworthy?
> and is so terrible folks swear off Thunderbird forever because I guess for email very basic rules for backing up data don’t apply (or something?)
Well, this bug literally causes Thunderbird to delete your original copies of data during the backup process, so I'm not sure why backing up your data is supposed to be the solution.
Thunderbird stores mail locally on disk.
If you're keeping backups of your disk, then this bug is not unrecoverable.
But keep in mind, that this is a cache. An UIDVALIDITY change will wipe everything out.
Did a developer ever try? Reading the issue, found only one person asking for test cases and trying to close it.
One of the many comments on the issue notes that although the bug has reoccurred in every version of Windows, it might not get much attention from developers because it is catalogued as something specific to Windows XP.
Nobody in the intervening nine years followed up by updating the bug's metadata, though. It's still "Windows XP only".
I try to never underestimate the incompetence/lack of concern people can have when it comes to addressing major product issues, but if this has been open for 17 years and is so widely known, somebody has surely looked into it and determined it’s not so easy.
and then they simultaneously determined "yeah, we might eat your data. Lets not warn anyone about that AT ALL, lets keep the feature activated and let them users lose their data". This behavior ought to be criminal.
IDK why the assumption is that safety measures haven't been created. You wouldn't mark the bug as resolved if you put in safety features, right? You *ONLY MARK AS RESOLVED* after reproducing the bug and *VERIFYING* that it won't happen again. Right? Dear god I hope this is what you do, because otherwise you are prematurely closing bugs.
I'd agree with you that the fact that the bug is still open after 17 years isn't the problem, but the issue is that people are still (as of 10 months ago) running into the issue of their mail being deleted. If they'd secretly implemented "safety measures" as you suggest that wouldn't be happening.
Looking at the timeline, it's possible that they've addressed a few of the bugs that result in data loss several years ago, and it's possible that the latest guy who ran into the problem within the last year triggered it in new ways or under new conditions but it's clear that the problem of thunderbird deleting messages from the server when copies haven't successfully been saved during a move operation wasn't solved by any "safety measures" 9 months ago and it's doubtful that it's been solved now.
My guess is that because thunderbird ultimately doesn't bother to make sure that messages are successfully and accurately copied before it removes them from the server it'll only be a matter of time before someone else stumbles on some other set of circumstances which results in data loss when messages are being moved.
Reading the bug report it is unclear to me if the newest one is the same bug. There are also other bugs referenced that look to be fixed.
But we can *VERIFY* that measures were taken. In fact, easily! We can look at the references at the very top of the bug report! There are others that need to be hunted for but this one was trivial to find and was implemented pretty quickly. There are also other similar bugs that weren't marked as dupes. Some of these have been marked as resolved and fixed. That leads me to believe that they just don't know what exactly this bug is because they can't reproduce. It may very well have been resolved and new issues might be completely new bugs. I mean... it has been 17 years... and TB has undergone significant rewriting. Don't you think that the software changed quite a bit in that time?Which all I'm trying to argue is that they didn't just sit on their asses and do nothing for 17 years
> But we can *VERIFY* that measures were taken. In fact, easily! We can look at the references at the very top of the bug report!
>> Title: move/copying multiple imap messages to local folder bypasses offline store and redownloads messages. Need to preflight the move/copy.
>> Status: RESOLVED FIXED
This might be a more compelling observation if the bug was related to data loss. This just says "if you have a local copy of something, read from that instead of reading from the remote server".
It addresses the specific observation made in the thread that you can encounter the data loss bug even if you already have local copies of the messages, because Thunderbird ignores those, redownloads from the server, fails, and then deletes everything. Now, if you have local copies, Thunderbird won't try to redownload them from the server and the fact that the data loss bug isn't fixed won't matter to you.
You could apply this same approach to the entire bug, by guarding the "delete all of the user's emails" action instead of the "move emails that already exist locally" action. But they don't.
are you being for real? did you see anything as such in the bug listing? but even IF they did put safeguards in place, the fact that this is SEVENTEEN YEARS, no warning, functionality still enabled without ANY WARNING losing people data. unforgivable.
How can you possibly justify this behavior? I understand they dont owe the world any software, fine, but dont knowingly publish stuff that KILLS PEOPLES DATA without atleast a warning
So let's consider a hypothetical situation. Suppose the problem was resolved in the almost 2 decades of rewriting BUT you still do not know what caused the bug in the first place and, consequently, can't reproduce it.
Do you mark the bug as resolved?
Now let's not sit in the hypothetical setting and act as developers. Some safeguards have been put in place (you can verify by looking at referenced issues). You've solved similar, but are unable to determine if these are the same problems or different problems (again, see referenced or use the search).
Do you mark the bug as resolved?
Your sibling commenter implied they would. Personally, I wouldn't. Marking as resolved is a promise to the user that it is fixed. But I can't make such a promise. I can't make any strong statement until I can reproduce. So yeah, it seems appropriate to me that it is marked as "unresolved" with steps "needs reproduction." That is an entirely appropriate status to me. You try as hard as you can and you implement as many safety features as you can, but you don't mark as resolved until you can verify. Unfortunately, this means issues go stale. Hell, there'll even be some noise like if a hacker or even just your dog deleted everything. We wouldn't want to assume the user is dumb and lull ourselves into a false sense of security, right? But you can only do so much.
*YOU CANNOT CLOSE A BUG REPORT IF YOU CANNOT VERIFY THE BUG*. That's the policy they are using. You may use a different policy, but that's the one they are using.
> YOU CANNOT CLOSE A BUG REPORT IF YOU CANNOT VERIFY THE BUG. That's the policy they are using. You may use a different policy, but that's the one they are using.
and then I would say: YOU DO NOT STOP WARNING PEOPLE UNLESS YOU CAN VERIFY ITS FIXED
(which ofc assume you bothered warning people to begin with)
Yes?
Aren't we saying the same thing then?
We must be talking past one another. I'm (and others) are assuming they can't reproduce the bug. Assuming they aren't lying when they say so and assuming they've tried.
I mean let's take the trivial case. Assume user is dumb, deleted the files, made a bug report. Devs will never be able to reproduce unless user tells them they deleted everything 'on purpose'. That ends up with a permanently opened bug report no matter how much time you spend trying to fix the issue and no matter how many safety features you build in, right?
no, I am saying that I agree that you shouldnt mark it fixed until you know its fixed.
I am also saying that if they dont know for a fact its fixed, they should WARN PEOPLE IT MAY EAT DATA.
its 17 years!
Okay, then yes I misunderstood you. I mostly agree but it's also been 17 years and what are the odds that the offending code still exists? What are the odds that it's TB's fault?
I know people report the issue but googling I can find similar complaints across all major mail clients.
I just don't think there's enough information to make strong conclusions and I don't think California cancer warning labels work. I think they teach people to ignore warnings instead.
Make no mistake - I am not absolving them of leaving this issue unaddressed lol just saying if it was easy they’d likely have handled it. It’s probably difficult or they just don’t know, so they keep putting it off and decided that not enough users are affected for real consequences (which is wrong to do)
i fully understand it might be very hard to fix, but to know about it for that long, and not warn people or disable the functionality is unforgivable
Totally agree
It's not criminal, but you're entitled to a full refund of Thunderbird in the event it happens.
This line of reasoning will eventually cause it to be treated as criminal, or at least as a civil tort. Then we will all be worse off.
Neither lack of payment nor the liability disclaimers in the license absolve the developers of liability for malicious actions or gross negligence.
Just because something is free certainly does not make it ethical, and it doesn't even mean it should be legal.
No, but they're rather limited in ways to reimburse you or offer "justice". Putting the Thunderbird team in jail doesn't help you out.
Hell, what if the offending commit was 2 decades ago by someone who's cut off all contact regarding code since?
nobody should fault the person who have coded the bug, unless someone can prove it was done on purpose. What I am suggesting is that the project as a whole has the responsibility to not just sit on data losing bugs for 17 years without warning users.
the fact that they choose not to, makes me perfectly OK with them being held criminally liable.
an option I will be making use of now.
And I know its not criminal, im saying it SHOULD be criminal not to warn people about this. its more than a decade
if (!user_requested_mass_delete && delete_requests_past_second > 10) throw(“we sure seem to be deleting a lot of stuff from the server”)
I would not want my email client to be relying on such brittle and incorrect heuristics.
A better workaround would be to keep deleted emails around for some time so users have the option to restore them if the bug triggers. But this has drawbacks such as potential privacy breakage (you meant to delete mails you don't want the chance that anybody sees it) or free disk space management (your local drive is overloaded and you want to urgently free up space) or ux confusion (this is a de facto trash but Thunderbird already has such a feature)
Ultimately, what needs to be done is make the code robust, make sure there are no race conditions, etc.
Well, would you rather have a brittle heuristic lose all of your mail?
My point wasn’t that this is a great solution, just that it is very easy and almost certainly better than doing nothing for almost two decades.
> Well, would you rather have a brittle heuristic lose all of your mail?
That's not what's happening. I wouldn't expect such an heuristic to be currently present. There is a bug, not something intentional.
> almost certainly better than doing nothing
No, because with such an heuristic, you add behavior that's difficult for the user to understand well and to work with. With such an heuristic, you will lose some mails and at some point the process stops in the middle. Which mails have you lost? What is "many" mails? 10? 100? What if my computer is fast and is deleting 100s of mails per seconds, losing all the mails anyway? What if it is slow and never triggers the heuristic?
If the heuristic does trigger, you end up with a mixed situation where you still have lost some stuff, but not all, and it'll be impossible to understand which ones. It doesn't fix the issue (you still lose email), just makes it even more difficult to understand even for the devs when they inevitable need to track down related issues. You really don't want to willingly add mechanisms that feel like they are non-deterministic: they are hard to debug, and hard for the users to grasp.
A way better solution is backups anyway: if you care not to lose your emails, you should be backing them up. From the beginning, your local TB mails are not a proper backup of your IMAP account because it's two-way synchronized so you need a backup somewhere else.
A still better workaround is disabling the move to local folder feature and make people copy and then manually delete mails.
Not saying your heuristic is not a good idea or clever (it is clever and could lead to further good ideas), just that after reflection, it should probably not be implemented. It barely starts to address the issue and adds complexity for everyone involved.
Just do a complete rewrite in rust, that will solve all the issues
Except the bug was filed in 2008. Back then, Rust was Graydon Hoare's personal project that Mozilla wouldn't start funding until a year later. Rust was written in OCaml and the famed borrow checker wouldn't be in place until 2010. The first public release was v0.1 in 2012 and the first stable release 1.0 wouldn't happen till 2015. The language was very different back then with sigils, garbage collection and green threading as language features. So this bug was already bugging people when Rust was just an embryo that was still years away from birth.
Now even if we neglect the timeline, Rust only guarantees memory safety. If TB is deleting mails on the server too, then the corruption is happening over IMAP connections as well. Does that sound like a memory safety bug to you? Perhaps it is. But how do we eliminate the possibility of a logical bug that Rust won't protect you against, when nobody has any clue even now? And all that aside, if you're going to rewrite it in Rust, you might as well start a new project in Rust instead of porting an old design that may potentially contain a language-agnostic logical Heisenbug.
I'm not trying to be hostile here. I started using Rust in 2013 (I have 12 years of experience in a 10 year old language, and a bunch of repos that I can't compile anymore unless I compile the compiler from old commits somehow!). I wouldn't use C or C++ for any of these applications - I simply don't have enough competence to avoid the kind of bugs that Rust protects me from (despite being a hardware engineer with more knowledge about memory management than about type system theory). Despite all that, statements like this will only cause an unwanted backlash against Rust. Not that you're entirely wrong, but some people are so offended by such suggestions for reasons that are still under investigation, that they start a crusade against Rust [1].
[1] https://fosstodon.org/@goku12/114077011555069124
The op is being facetious
Sometimes, treating a facetious/sarcastic request seriously helps disarm the facetiousness. Other times, it does not.
English is my first language but I don’t understand this use of “disarm”.
You counter the facetiousness in a way it stops spreading and possibly even spark a constructive discussion is how I understand it (ESL though). I certainly observed this phenomenon myself (although as the person being facetious, I often feel like "I was joking, I actually agree, that's indeed what I was actually implying, but good you made it clear and explicit I guess")
I guess you'd disarm the person being facecious rather than the facetiousness, like you'd disarm someone about to cast you a magic spell.
> I guess you'd disarm the person being facecious rather than the facetiousness
No, you disarm the facetiousness, the same way you'd disarm a trap. Disarming the person wouldn't make sense.
https://en.wiktionary.org/wiki/disarm
> 2. (transitive) To deprive of the means or the disposition to harm; to render harmless or innocuous.
> [quotations] to disarm a man's wrath
Interesting, in French, you can both disarm someone or a gun.
https://fr.m.wiktionary.org/wiki/d%C3%A9sarmer
You can disarm a person in English, but you can't disarm them of their mood.
In French neither, I took this as a figure of speech where facetiousness is likened to a weapon.
At this point, answering to a "rewrite it in Rust" comment which doesn't go into details is a cultural faux pas, you just smile or roll your eyes and move on :-)
I really can't tell them apart. My fault. But people also get too passionate about it sometimes.
Is whichever part of Mozilla that runs Thunderbird going to rehire the rust team now?
Honestly? It might.
Only by being a statistically different code base, unless you think this is a memory safety bug?
Looking at the various issues reported in this thread, it honestly seems that burning the entire codebase and rewriting it would be the best choice. Bonus points for using a modern systems programming language.
Safety in rufst is not only about memory safety. It’s also about avoiding unpredictable behavior.
reading through the report, it's not unlikely to be a race condition
A better approach might be to feed all of this into an LLM to have it figure it out. If it finds a bug and has a fix, reproducing it might be easier and a test could potentially be written.
I don’t think LLMs are the answer to everything, but this would be a good test for newer generations of LLMs as they’re developed.
Worst case- it deletes all of your emails, but that would’ve happen anyway, right? =)
Reproducing bugs is a luxury and not even close to required for analyzing and fixing issues. Even if the issue is external (hardware, antivirus, etc.), the code can be changed to be more defensive and only ever delete the original when the new data has been successfully written and verified.
You're right, but you're also wrong.
The problem is you can never close the bug report if you can't reproduce. I guess, you could, as the other commenter suggests, mathematically prove that it can't happen, but otherwise you're prematurely closing it.
How do you differentiate that you solved the bug and not a similar looking bug?
But this doesn't solve the problem. I'm sure you can think of more situations that still won't solve the problem.How do you close the report if you can not make strong guarantees that it is resolved?
A luxury? Not even close to required? You are not afraid of words! I'm not looking forward to receive a bug report from you!
Yeah, reproducing is not theoretically mathematically necessary. In theory you could prove your code is correct with formal methods¹. Now, nobody does this because it is impractical (borderline impossible), reproducing is in practice so useful as to be almost essential:
- it lets you study how your code behave in the problematic case and identify what's causing the exact issue the user is seeing
- it lets you check that your fix does indeed address the bug
I have indeed already fixed trivial bugs without reproduction cases from a vague description of a bug because I'm intimately familiar with the code and it immediately rings a bell: the cause is immediately obvious. But that's not the usual case.
> the code can be changed to be more defensive and only ever delete the original when the new data has been successfully written and verified.
What if the code is already designed like this (and I sure do hope it is currently written like that, because that's almost common sense, if not the only sensible way of moving something) but somehow fails for some currently inexplicable reason? It smells race condition to me.
In the case of the discussed bug, users have described a reproduction case that's not 100%. But someone will need to find a 100% reproduction case. Users, or devs. It will not be optional. You can't play a guessing game, attempt to fix the code and hope for the best. You might be able to actually fix the bug, but without much confidence. Best case, you'll be able to find a reproduction case after fixing the bug (that you'll probably use as a functional test), to prove you fixed the bug for this specific case you found. You'll not be 100% sure you addressed the user's case.
A bug can hide another one, so you could find and fix a bug, but the issue is still present in the user's case. You can only be sure with their reproduction case.
But I agree that it is hard to reproduce a race condition.
¹ which in practice applies to code of trivial size (static analysis), or consists in checking a model but not the actual implementation (model checking), or does apply useful checks but is not exhaustive and has false positives / negatives (static analysis), or does apply useful exhaustive checks but only on a limited number of executions (runtime verification, and we do have functional tests that serve a similar purpose in practice - and you'll actually need the reproduction case here so you have the right execution to check), or requires you to write your code in a specific language (stuff like coq) and you cross your fingers that this specific language's implementation is itself correct. In short: not applicable here.
You could have fixed the bug (especially since a lot of TB was rewritten) but if you can't reproduce the bug you wouldn't know it was solved only that people stopped reporting it. This is actually a common occurrence with long standing bugs.
You know what else they could do? They could disable a feature that deletes large volumes of email the user doesn't intend to delete.
I don’t remember the last time I deleted an email. I’ve marked things as spam, archived things but not deleted in a long while.
I delete email everyday.
Sometimes you want to delete a whole bunch of mails, don't you?
I've updated my comment for clarity. The bug (which I've never encountered in more than 20 years as a Thunderbird user) is that users move messages to a local email folder, but the messages are deleted from the server without actually downloading them. At a minimum they should disable that operation. The guy that originally reported it worked at Sun and lost hundreds of work messages as a result of this bug. AFAICT the user wouldn't be affected if they did a copy of the messages and then manually deleted them from the server folder after confirming the copy was successful.
How do you fix a bug you can't reproduce?
It's a genuine question because I'm puzzled here.
A very small number of users have this bug (and tbf, it's a really bad bug), and are unable to consistently reproduce it and it seems none of the developers have been able to (the seemingly random nature of the bug occurring is not helping). How is it supposed to be fixed?
You add more and more diagnostics (e.g. logging) in that area till you manage to track down the bug. Over several years this should be possible. At that point you can either fix the bug directly or do it properly by first reproducing the bug (in a test) and then fixing it.
How do you close a bug you cannot reproduce?
Said another way - If they can't reproduce it, they can't close it.
They may well have fixed it already, but without a way to reproduce it the only prudent behavior is to leave it open and wait for the next diagnostic file to be uploaded.
The way I've dealt with that in the past is putting into into Review or whatever the equivalent is, make a note ("cannot repro, but attempted potential fix in version XXXX, moving to review, please reopen if anyone reports this again) and then if nobody reports it still happening for x amount of time (e.g. 12 months), close it. Can always reopen it if it gets reported again beyond that.
That's not the only prudent behaviour, as the OP said, the prudent behaviour is to add more diagnostics and guards against the conditions that lead up to the bug.
Okay, let's assume more diagnostics and guards were added.
Now re-answer the above questions with these assumptions.
Being generous here, we're assuming there's 17 years worth of diagnostics and safety guards added but through that time the bug still isn't reproducible. Let's try to answer the questions under these assumptions.If you've added guards and diagnostics, then you close it until someone else files a follow-up, then it can be re-opened. There's no sense keeping it open unless there are ongoing reports of the issue.
Let's consider this from a failure analysis standpoint. Here's our options
*Which error case would you rather have?*The classic example of this design choice is with a safe. Let's imagine you are building a safe. If the safe fails, would you prefer that it fails into a state that is unlocked or into a state that is locked? The answer isn't so obvious, as it actually depends on how it fails, right?
A very common example is when designing skyscrapers. The choice is that when a skyscraper fails, there is a strong preference that it falls in on itself (think 9/11). Why? Because if it falls to the side then it takes out other buildings and can create a chain reaction (a related famous example being housing in Industrial Revolution London and fire...)
Your action is a valid option, but it is not the option that I would chose. I think what they did was perfectly fine. They left it open (to avoid tricking anyone to thinking it is solved when the status of solved is actually unknown) and marked with additional information about lack of verification/reproducibility. Essentially, it is marked as stale.
So we're back to the earlier question:
Or we can frame differently: "How do you close a bug report if you have no indication that the bug was resolved nor exists?"There are users in the comments here reporting the issue affects them.
Would some noble purpose be served by closing the existing issue in the hope that they'll complain via more official channels?
Hopefully those people will report the issue in the bug report and try to help the devs reproduce the issue. Especially since it is linked.
I don't think one more user report is going to be the difference that pushes them over the finish line after two decades. Let's not pretend the developers have been taking this bug seriously.
They still have it marked as unreproducible. What do you expect them to do if they can't reproduce?
So yeah, I do think more user reports can help. At worse, it will make them take it more seriously if there are more reports.
You also are falling to observation bias. You can see linked in the issue as well as by searching that there are similar issues that were resolved and marked solved. So I don't think they were just doing nothing as everyone seems to be assuming.
Have the been any potential fixes made since those reports?
Given there are people in the comments here indicating the issue still exists, there haven’t been any actual fixes made.
For starters, put a lot more effort into reproducing it.
- You can try harder to reproduce it.
- You can extend logging to gather additional information to reproduce it.
- You can try to reason about the code and figure out possible causes.
- You can attempt to formally verify the correctness of the code.
- You can put guards into the code against unexpected states and actions.
- You can verify the correct result of previous actions before any destructive actions.
- If all fails you can scrap the piece of code in question since it seems to be beyond your ability to maintain.
> How do you fix a bug you can't reproduce?
You strangle it from the edges.
I'm rather surprised by the comments responding to this. A bit by the comment itself.
Why I'm surprised is... well... this is HN. We know that a bug like this is very rare, right? I mean otherwise who would ever use TB, right? But if it's rare, it's really hard to track down. There years of comments without people including system information. The reproduction steps themselves are "sometimes." It's HN, so we can assume users here program, right? How would you solve this use?
FWIW, I've used TB on Linux and OSX for years and never faced an issue like this. The only one I've faced is sometimes not being able to connect to the server and having to resend an email.
On the other hand, when using Apple Mail:
Idk, this is an annoying problem but I'd be surprised if I lost all my emails. I can recover deleted emails in Gmail and Outlook. Annoying, but recovering these (go to trash, click "restore") is far less time than what I'm saving on a weekly basis with TB.I know these problems aren't on all platforms but TB IME has saved me a ton of time compared to using Gmail, Outlook, or Apple Mail. Hell, fucking Neomutt is a better experience than those three, which is insane. Trying to use them is like trying to use the internet without an ad blocker. How are we so bad at email?
I had email service expire on a domain and moved it to fastmail. Fastmail, obviously, did not have copies of the email I received before the move. But my phone did.
When I updated the configuration in K-9, it contacted the fastmail server, found that the mail it had locally wasn't also present there, and immediately deleted all my local copies.
That's not a "bug" in the sense of unintended behavior of the software, but it certainly seems like the software designer's goal is to hurt the user. I obviously didn't want that to happen. There is no scenario where I would want that to happen.
Email clients make some strange assumptions about what kind of actions make sense under what conditions.
I'd wager that this is marked as "by design" because it technically follows some IMAP spec. What the app does, purely on a technical level, is correct.
I've so often had debates and threads in issues where a developer entrenched in a domain has so much domain-knowledge (ie. tunnel vision) that "technically correct" or "by the spec" is the only correct way. I've been that developer in many cases too, in hindsight.
I got also bitten by this. While IMAP would allow for syncing, most MUAs don't have a local mailbox. Instead they have a cache and the offline mode means to put as much as possible in to the cache. But if you want an actual local mail storage, you will eventually have merge conflicts, because how do you deal with a message that is present locally and was on the server, but is no longer? Do you assume the user wants it deleted, or that it should be reuploaded to the server? Either way will be wrong. (Also if you reupload, it will get a new UID, so another MUA will again reupload it, i.e. you will get a copy per MUA.)
So if you want a mailbox sync tool, use a proper program for that like mbsync/isync. (But this can't cope with cross mailbox moves besides (not) propagating them.)
Some developers incorrectly think a spec defines what your program should do instead how to do what your users want.
Another example is HTTP Strict-Transport-Security which specifies that browsers should take control away from users.
Yes, a spec is a technicality that, ideally, should be abstracted away completely (and alas, all abstractions are leaky somewhat).
It's another thing that got me interested in DDD. Where the user, domain, business and such define what things are called, how they operate, what events they undergo or emit etc. And not a spec, language or framework
And where e.g. "the IMAP spec" is a clear bounded domain, probably a service, an adapter or even library. Within that domain, "The Spec" dictates all the naming, conventions, logic etc, but where the border of this domain is another language. E.g. in a "MessageAdapterImap" something is called "EXPUNGE" with all the intricacies of what this means in IMAP. But in the outside it's e.g. part of a "cleanup()" interface, or whatever the domain calls it when it removes messages.
You make a good point but this is not a "strange assumption" by any stretch. You see Thunderbird has a "move" action. It allows you to move emails from a folder to another. Now somehow, this is apparently NOT implemented as:
1. Copy from source to destination
2. Verify copy has completed without issue
3. Delete from source
but... some other way? So when you try to move from a server folder to a local client folder by an innocent looking drag an drop, combine this with a poor network connection, a garbage tier legacy protocol like IMAP and decade old C++ spaghetti code, and you get this textbook 17 year old severity 1 bug that will never get fixed.
Well, interestingly, Thunderbird insists that that is exactly the implementation they're already using.
(see https://bugzilla.mozilla.org/show_bug.cgi?id=462156#c69 )
Of course, it isn't; they're relying on an unstable proxy for "copy has completed without issue" in preference to just checking whether that happened or not. Several rather angry users have pointed this out. It doesn't seem to have sunk in.
Oof that is bad.
> How is it not top 1 priority to fix it?
Maybe because it is very rare? I have been using thunderbird for 10 years now on various OSes and never had issues.
It's like a car whose engine randomly shuts down with a very low reproduction rate. Except with cars when this happened GM has recalled 30 million cars and paid billions of fines.
Emails to email client is an engine to the car. It is pointless without one and it is THE purpose of it. All the rest of functionality like fancy UI, filter, notifications, editor is meaningless if your emails were deleted without recovery. Even car without engine is more useful than email client with empty DB.
The big difference is a car with an engine that randomly shuts down is a life-and-limb safety issue. An email client that corrupts the database is extremely unlikely to cause a loss of life, even if the consequences are costly.
That said, even if the bug is impossible to isolate, it sounds like the chain of events that leads to it is known. They probably should disable the feature until someone is motivated to fix or replace the code. I'm sure that would anger a lot of people, but someone angry about the loss of a feature is probably better than someone who is angry at the loss of data. Especially given that the feature seems to be something someone would use to archive their mail.
A loss of life is also just a monetary amount when it comes to liability.
That may be but i immediately uninstalled Thunderbird from all my devices upon seeing that its low priority and unassigned.
I wont be using any email client that can break and delete all my emails from local and the server. Why would i? It may be a lottery but it isnt one i want to play.
The fact that they see this as low priority shows theyre morons.
Who would say 'yes please' to an email client that might permanently destroy some of your most important data at random?
When i say they're morons, i mean it in terms of them not understanding the reputational and trust damage this can cause, via the thread, the low priority, lack of assignment, or word of mouth.
Far too focused on the engineering POV than the optics and trust/reputation damage. My kind of moronic, but still moronic.
It happens to me regularly. You can fix it by redownloading the message from the server using the "repair folder" feature, and I have backup, but it IS infuriating.
I have no good alternative to thunderbird, it does so much of what I want. But this bug is awful.
> You can fix it by redownloading the message from the server
But OP said it also deletes the message in the server, so it may be a different bug, right?
Note that this is why you use copy, check, then delete, instead of just "move" data, whenever it's important that the process works correctly
Even if the software doesn't have known bugs, I do it if the data is important enough and especially if I were to not have a backup (for example, because the storage provider takes care of backups and redundancy. I personally like to have another copy that I manage myself, but how many people have their IMAP emails or Spotify playlist data backed up for example? I do, but not many people I think)
No. The bug happens with copying.
The bug may happen there but the data loss happens when deleting the original without verifying the copy.
I have been using TB on all operating systems with 8 or 9 users since 2006 and I never even once encountered this issue.
As a software developer fixing stuff like this is only possible if you can reproduce it or otherwise get logs, telemetry and similar things, otherwise it is pretty much just guesswork.
Granted given the severity of the consequences I would've chosen a more defensive move-strategy (e.g. one that deletes mails only once they have been copied verifiably), but that would have significant performance impacts in the 99.99% of cases where it works, so finding the real problem is preferable.
The truth is that if this happens to you regularly, that you are probably the prime person to gather more data on this. Call it giving back to Open Source software.
> As a software developer fixing stuff like this is only possible if you can reproduce it or otherwise get logs, telemetry and similar things, otherwise it is pretty much just guesswork.
As a software developer you should be able to reason about your code and work backwards from the observed result to investigate possible causes.
When a plane crashes or bridge collapses the engineers tasked with finding the cause don't just throw up their hands if they can't make it happen again.
> I have been using TB on all operating systems with 8 or 9 users since 2006 and I never even once encountered this issue.
Same but I never move my emails to local folders.
I have the same infuriating issue. Still using thunderbird because of principles, etc, etc.
But this does seem to be a different issue from the one OP mentioned. Seems to be actually this one: https://connect.mozilla.org/t5/discussions/thunderbird-searc... (with suggested solution)
It's amazing that thread seemed to take 5 years before someone mentioned their IMAP server and basic configuration info.
Most users don't administer their IMAP server or know much about it.
Oh, wow. When I have to use Thunderbird, I never move emails. I manually copy emails to a folder and delete the emails from the old folder after that. I forgot why I have to do this. Now I know again. A lot of people here are speculating that this bug must be very rare. I maintained like 30 Thunderbird installations for other people. This bug bit me at least twice. It can't be that rare.
> On a several occasions (most recently today), Thunderbird has "lost" my mail messages that are in my inbox when I move them to a local folder. Effectively it corrupts the messages - they appear in the local folder as 1 KB messages with no subject or sender info. They are empty messages.
Apple's Mail app has had a virtually identical bug since Catalina; Michael Tsai's article on the issue currently has 636 comments:
https://mjtsai.com/blog/2019/10/11/mail-data-loss-in-macos-1...
After witnessing the bug myself, migrated to Thunderbird with Maildir enabled[1] for long-term storage; have yet to experience the issue despite a large database (>300,000 emails) and daily IMAP import to local folders.
[1] https://tinyapps.org/blog/202207100700_thunderbird_mbox_to_m...
I do hope that Thunderbird really fixes this issue really.
It really is just bad rep and like the severity of this is pretty bad.
Email is a really critical protocol so even if this is happening to only some people, it should still be fixed asap.
Because it has to be reproducible. Help make it reproducible and show that to the developers.
How about this bug, which I submitted 13 years ago and still isn't fixed. You can't search for "wedding" : https://bugzilla.mozilla.org/show_bug.cgi?id=752844
I've been amazed over the years this has never been fixed -- it's very hard not to make jokes about the standard lifestyle of open-source programmers, that they don't consider this a priority (note: that's a joke, I consider myself an open-source programmer. I would hope that's obvious, but someone just bothered to sent me a mean anonymous message)
Indeed most of the time I already know the exact word I'm looking for; and most of the time I get non-exact hits making it so much more difficult to find the actual message.
Perhaps there could be an option to disable stemming completely from the inverted index, which would be probably easier to implement than a post-search filter (which in itself doesn't sound very complicated..).
But of course, it's open source, anyone could contribute :D.
The search in thunderbird is terrible compared to what we are used to today. Same for k9 (now thunderbird for android?).
Not only is the UX a horror, its results rely on all sorts of technicalities. I, as a software engineer, can understand that a mail has to be downloaded in entirety locally in order to have it indexed and then show up in the results. And I understand that sub-sub directories aren't really a thing in IMAP, so searching this-dir-and-everything below is hard/impossible and so on.
But mostly the search algorithms are poor. So much so, that I often rely on (rip)grep to find mails. Or in a few occasions wrote a quick bash/python horror to push all my mail into a meilisearch instance and then use this search engine to get the lists and filters that I would expect thunderbird to have.
Yes. It's open source. So "go fix it" is a proper reply. But that doesn't make a complaint about the state of the search feature invalid.
I don't know why you're getting downvoted for this. That seems like a pretty frustrating bug when generalised to other word stems. It's also pretty standard to prioritise exact matches when ordering search results so, again, frustrating.
One of my biggest bugbears with Microsoft Outlook has always been that its search function is terrible. If you can't find an email then it may as well not exist, and that's been a real problem on a regular basis during my career - particularly latterly when I was in leadership and necessarily lived in my email and calendar.
It's disappointing that Thunderbird has similar issues with such a fundamental function.
That is annoying. I wish I could advance search or better, use regex. Luckily there are plugins.
Worse though, in Apple Mail I'll search an email address because I got an email earlier in the week and the first thing it'll show me is an email I got from that person 3 years ago with the correct result a few down. I really need a better email client for my phone...
The filter/search feature in Thunderbird does not appear to have a way to search for exact matches. You want exact matches. First, identify if it can do exact matches and if so, expose to the user. Else, who wants to touch that code?
[flagged]
Nitpick: not all bugs have to be reproducible to be taken seriously. Defensive programming, and adding extra logging could be a mitigation to avoid future problems, or to help fixing them in the future.
Yeah, parent comment is deeply unserious.
Imagine you're writing trading software, you have an algo go haywire and it machine guns the whole order book, and then you refuse to put a "max order size" outside of the algo to stop it from happening again because you can't figure out why it happened in the first place.
Try telling a regulator or your boss that was your reasoning.
How many one-off band aids do you think should be applied for rare, never reproduced problems before you slap a “100% safe” label on it and ship it with the confidence of a bloated, cruft-ridden job well done?
Are you arguing in bad faith, or do you just not have any practical experience dealing with complex systems?
Even if the bug can't be reproduced, on the basis of multiple user reports the first step absolutely should be to add some assertions and logging around email deletion.
The point is not to give it a "100% safe" label, the point is to start narrowing down possible root causes. If the problem recurs again, you'll have assertions ruling out certain possible culprit code paths as well as logs displaying the values of relevant variables.
Kinda off topic, but I've been searching for good introduction and best practises for defensive programming, but never really found much. Any recommendations?
I don’t know of any real posts on it, it just ends up being kind of a “assume it’ll go wrong,” then figure out how you know something has gone wrong and track it down. Your starting point is, after an issue is reported, add a load of logs around places that seem like candidates for the flow. Over time, you get a sense of where things can break and you add that telemetry ahead of time.
This is something where modern chatbots will probably be very helpful. From the top of my head:
1. Validate input, expect all external input (both human and machine generated) to be completely bogus.
2. Fail fast and early. If something seems off, crash straight away, and do not expect things to magically repair itself at a later stage.
3. Use pre- and post-conditions where appropriate.
I'm not sure about the exact definitions of defensive programming, but static type checking, and possibly unit testing, might also be part of it.
I feel like this is sort of like reading a book to get better at self defense. Yeah, you'll probably pick up a few interesting things that may be of questionable use. But when you train in martial arts, you often get to go through the motions and put the moves into practice. Even then "real" fights will feel quite different and a lot of the stuff you've learned will likely fly out the window. If you've been in real fights a lot, you've begun to internalize your training and your moves become more like instinct. It's quite difficult to go from book knowledge to instinct without getting beat up a lot in between I think. The real valuable lessons come from building something that breaks and getting to fix it yourself.
How do you fix a bug you can't reproduce?
This issue comes up in my role a lot, where I am often dealing with various environmental conditions and human factors, plus multiple integration points between various software and hardware systems.
The answer is that you keep working at it iteratively using a combination of logging, reporting, and defensive programming to systematically narrow down the possible causes. Sometimes you never arrive at a true root cause, but you get close enough that you can mitigate the problem and finally close the ticket out. At the end of the day, the customer/user doesn't care as long as it works.
However, what will really piss them off is telling them your hands are tied until they can reliably reproduce the issue for you. It's important they understand that you are working on it, and typically they will go out of their way to help solve the problem when they feel taken care of.
That specific bug needs reproducible steps. How would you try to work it out if it does not happen on your setup?
Why do you think it needs reproducible steps? It is obvious that the bug is still active, so in a way it is reproducible, just not in a systematic way.
This happens more often, for example when many services work together in an asynchronous way, and in some very rare situation, unwanted behavior occurs. To fix that, it is often easier to reason through the entire process, and to identify weak spots. It might even be a good idea to switch to a different paradigm to avoid certain bugs altogether.
For this particular bug, I would start by reading a lot, and ensurong that the bug is indeed not easily reproducible (by trying to make it reproducible of course). If that fails, I would continue to think about root causes for the bug, and possible workarounds that would work in theory. Then I would try to estimate the amount of work required, and the risk of breaking other things, and report that to those who like to decide on further actions.
And of course, as I know very little about the inner workings of ThunderBird, I would simply ask ChatGPT o3 or similar for advice. It comes up with a plan that seems reasonable.
No it doesn't. If I waited every time for obscure production issue to be reproduced in lower envs I would be fired... many times for clear and obvious incompetence.
Sometimes, you can add some additional steps, logging, change behavior in corner case a bit, either to get more understanding next time it happens or even mitigate it. Sometimes, you have plenty of tools and ways to act. In my experience, that sometimes is basically always if one cares enough.
We don't know how to make it reproducible.
What developers should do on such a critical and long standing issue is to offer an extension that victims can install to volunteer to track the bug. So they can click a button when things are fine to take a snapshot, and click another one when they encounter it.
I would install that and be part of the solution.
If it was me running the project there's enough information in that thread to piece together an exploratory testing plan around the issue that might allow us to isolate it, and I'd set aside some time for the team to do that.
Whilst obviously not lethal, this Thunderbird bug sort of reminds me of the Therac-25 incidents in the 1980s. Very occasionally the machine would give patients massive overdoses of radiation. This bug wasn't easy to reproduce (thankfully) and turned out to be due to a race condition.
But of course, you can't find a problem if you don't investigate, and if it's a serious problem that's been documented then, as engineers, we can't just hide behind non-reproducibility as if it's some sort of magic shield. We have a responsibility to investigate and isolate the problem ourselves. If we don't do that we are effectively washing our hands of our own creations.
Not only that. Often mitigations can be placed even if the actual bug cannot be reproduced. Like many others in the thread suggested.
I've encountered several impossible to reproduced bugs in the past. And what I (or my team) would then do, is re-architecture (refactor) some pieces of software so that we could reproduce it. Like e.g. better logging, specialized layers/adapters/services, simpler logic, and -above all- better testability.
Hard to do when all your data is chilling in oblivion.
It doesn’t have to be reproduce with real data.
Then the developers can do it
So you expect the developer to create data ex-nihilo for a bug they don't know how to trigger ?
I explicitly do not, which is why my first response spells out that it’s hard to reproduce a bug when all your data is gone. If it is the case that the bug can be reproduced without user data (as suggested by the person I responded to, not me), then the developers should be able to do that better than users can.
You can take snapshots of the VM with the mail server. When the bug happens, identify the snapshot. Bingo.
You’re assuming users affected by this bug have control over the VM running their mail server. I won’t argue that it can’t be done, but it’s probably harder than we think.
I've been using TB for personal and work since it's first day and never hit the bug. I've never known any co-workers to hit the bug. I'm sure plenty of other software that we use every day has similar severe bugs that occur just as infrequently.
I'll keep using TB. I'll also make sure to look both ways when crossing streets and won't assume that cars are going to stop for red lights because my chance of getting hit crossing a street is more likely than getting hit by this bug.
Yikes! I recently tried Thunderbird again because I was annoyed with gmail pushing AI subscription crap in the web UI. Guess I'll take that over this bug for now.
6 years between the initial bug report and someone from mozilla joining the thread, wow.
I got bit by this a long time ago. Will never trust Thunderbird again.
I was a thunderbird user many years ago. Seeing the article made me want to reinstall, and then this comment instantly changed my mind. Insane bug for an email client to have…
Hopefully this prompted you to check your backups?
Can't even make a backup in the first place if they get deleted while you download them from gmail.
It bypassed Gmail's trash folder?
Yup. "Move to trash" is a gmail thing, Thunderbird "move" uses IMAP directly.
Backups should not be your first lone of defense.
[flagged]
A useful use of AI might be to simulate thousands/millions of user sessions (via generating mouse and keyboard inputs), with instrumentation/logging switched on. Run them in various shapes of VMs until you hit the problem. Fuzz testing, basically.
Which might hallucinate some more problems which doesn't exist in the first place?
Or it might find it. You don't know until you try, but for a bug of this severity it's worth a shot!
Could they just make it not suck? Like the search system falls apart if you have more than a few thousand messages in a folder, not all that many by today's standards. The address book doesn't let you sort the addresses by most recently added, which is important if you reply to craigslist posts which use numeric forwarding addresses. So once you have more than a handful of them the are impossible to tell apart. It automatically makes new archive folders by year (2023, 2024, 2025...) which is kind of nice, except it shows them oldest first instead of newest first, so you have to scroll way down to get to the current year. The progress bar on the bottom looks like there is constantly something going on, and maybe there is, but it never finishes. Messages sometimes fall through cracks so you can't find them in any folder but you can sometimes find them with global search. And on and on. Stop adding new features or messing up the UI further until basic functionality like this works.
> Like the search system falls apart if you have more than a few thousand messages in a folder, not all that many by today's standards.
My Thunderbird installation tends a 20 year old work mailbox with tens of thousands of messages, and the search works the way I want even though I don't download the messages themselves to save some disk space.
If you are using your installation for a very long time, your local caches might have broken at some point, because Thunderbird was bad at that kind of thing, but now it's not.
For folder order, I can't tell anything about it, but 13 years of folders are just a wrist-flick distance on a 2K display, and shouldn't be much worse at an 1080p one, either. So, it might be fair criticism, but it's nitpicking.
I never experienced "lost messages" for a very long time, and my progress bar is currently sitting empty, despite that installation is handling 5 busy mailboxes.
You may need to delete some cache and local MBOX files and restart your Thunderbird, it seems.
> Like the search system falls apart if you have more than a few thousand messages in a folder
I'm in the inbox, I see an email with 'word' in the Subject in some of the most recent emails.
I type 'word' in the search box and TB finds some emails from the years ago.
It's even worse if it is 'word and some another word', in this case it doesn't even find anything.
It's like the developers... aren't dogfooding their own product?
Oh, yeah, we do now have TWO search boxes. Because that makes sense. And if you disable the topmost one, there is now 30px of wasted space you cannot reclaim. Because you definitely NEED that hamburger menu on the RIGHT side. On the desktop. On the 4k+ monitor. Riiight.
The two search boxes is bizarre. It feels like two rival programmers each wrote a half-baked search feature and rather than management telling them "Unify your two approaches", instead they said "Just throw them both in there and let the user figure out which one they want."
There aren't two search boxes. There is a search box in/below the titlebar and a filter for the current folder.
And if there were two driving wheels in your car, a one for turning right and an other one for turning left you would say there is no two driving wheels in your car.
A filter is different from searching. It only works on the current directory, it alters the view after it has been generated. You can also use it on a search.
Don't know about others, but I find the functionality useful and use them for different purposes. Searching is when I want to find random messages, where I don't know where or from when there are, the filter is for bulk processing and narrowing the current working set, beside the conversation level.
It is more like the steering wheel and choosing forward/reverse, sure both are for choosing the driving direction, but they operate at different levels and are used in different situations. I mean you could use the steering wheel for forward/backward if you want to. Using the gear to change the direction less than 180° is quite difficult, but not impossible.
You are just trying to confirm your beliefs.
Thing is, the 'filter' box can work as a filter and as a search box. It's even a simple heuristic if it should behave as a filter or switch to the search - if there is no result for the text entered in the textbox then switch to the search.
There is zero need to have two search boxes, it's just Mozilla wanted to copy-paste the idiotic solution of MS Office with a top-most search function. That's all.
Ok?
Do you ever only use one of find and grep? I think they are very similar as the search and the filter bar. I mean you can replace find with tree | grep, not sure about the other way around, but it's probably also possible.
> There is zero need
I do, so it is not exactly zero and I would be annoyed to have them gone, because it is a huge time saver when handling thousands of messages.
> if there is no result for the text entered in the textbox then switch to the search
If the filter starts to draw in messages from other directories, that would be stupid and kind of defeats the point of having a filter in a first place. If you want that why don't you use the search?
> it's just Mozilla wanted to copy-paste the idiotic solution of MS Office with a top-most search function
I don't care where the search bar is placed and I think that functionality did already exist before the current UI, either via ^K or in a menu. I (maybe) do agree with you, in that I don't like putting widgets in window frames (that's for the WM) and prefer classical (CUA-like) menubars.
Can you please criticize the functionality itself? I can't comprehend why you don't see the point of a separate filter. Do you mostly keep messages in the INBOX?
Maybe my original word choice wasn't optimal, because you can consider filtering a subset of searching, but I do consider them to be different. If you rather you use a different terminology, that's fine, but I don't think it will change my point.
> Do you ever only use one of find and grep?
It's not a CLI. More so, redundant functions eats the screen real estate, which isn't getting taller on a non-mobile platforms.
> I do, so it is not exactly zero and I would be annoyed to have them gone, because it is a huge time saver when handling thousands of messages.
You sounds like I'm advocating to removal of both the search and the filter boxes.
> If the filter starts to draw in messages from other directories
sigh
You input something in the combined search|filter box:
If you got the result you need from this folder then you just do your thing.
If you did not got the result you need then press Enter which would start the search in the whole mailbox, just like the search textbox works now.
> I don't care where the search bar is placed
Great for you, but I care. TB interface was already far from understandable by both computer illiterate and computer literate and this is just another illogical placement what doesn't add functionality, yet wastes the space.
BTW, did you provided the support to anyone by the phone? Can you be sure what the person on the other side inputs in the right textbox? I can, somewhat, if there is only one. If there are two then 70% of time they would use the wrong one even if telling you it's the right one. I provided enough L1/L2 to know it well.
> Can you please criticize the functionality itself
Yes, there is no functionality need in the two separate textboxes for, essentially, one function: searching.
> Do you mostly keep messages in the INBOX?
Thanks, no.
> because you can consider filtering a subset of searching, but I do consider them to be different
Yes, they both are the methods to find some message/s what you can't just scroll to. And those 'quick filter' buttons near the current filter textbox are quite nice, btw.
My problem is what that search textbox is a clear import from the MS Outlook[0] and it was did only to mimic the other product, without a second of actually thinking if this is even needed.
Just imagine: what if instead of that search box that space would be used for... a filter/search combo textbox, along with a quickfilter buttons, just like today, but not wasting the space for nothing in the window titlebar.
Also I finally noticed what there is even a special combo to invoke the filter so it also can be used to differentiate the usage right away: ctrl+shift+k - filtering, ctrl+shift+f - searching the mailbox.
Just for the sake of it I did a poor man's mock-up:
https://ibb.co/JjXwxhhB
And, uh, just one more thing: when you do search in TB you are brought to a separate tab with the search result. There is zero need to the search input to stay in the current search box. It's literally useless.
[0] if never even saw it then just search for the screenshots.
EDIT: and about 'heuristic' - there also two ways to do it:
1. just have a toogle buried somewhere, to enable/disable autosearch
2. just do the search automatically, with a low priority and find a way to notify the user what this are results from the other folder. Can be as simple as '--- results from the other folders ---' line.
> It's not a CLI
It is not about the invocation, search and filter bar differ in the same way as find and grep. Even if they are similar, they are still different enough to not benefit from unifying.
>> I don't care ...
I mean that as: I don't object to a different placement of the global search bar.
> My problem is what that search textbox is a clear import from the MS Outlook
I don't know the history and which program's search box predates the other. Note, that the search bar predates the current UI change, see below.
> not wasting the space for nothing in the window titlebar
As I have written earlier, I also don't like UI in the titlebar. But neither do I like yet another omnibar.
I think I should start again with describing how I perceive the functionality:
There is a global (across accounts, folders) search UI, which is a whole different "window"/tab, with different kinds of logical search parameters. The result view is displayed paged, with time, account and folder graphs, but can be converted to a standard message list view. This can be used when you have no clue and just focus completely on searching random content. The global search bar is just a "button" to open this UI and prefill the search box.
Suppose you have an already existent curated working set of messages. Then you want to select a few and operate on them. This is what the filter bar is for. You don't need to change your focus to a different UI element, it is just a way to pre-select your working set or temporarily restrict your view to focus on just some messages.
Note, how a lot of functionality is in adjusting the UI to support the state of mind of the user.
Enhancing the filter to work across folders is maybe a feature, I don't have a use for that yet. It doesn't makes sense with the current placement, because that indicates, that it is in the current folder frame. I wouldn't implement it like you, I would probably add a checkbox, but that's an implementation detail. But then getting rid of the search bar/functionality is just that, removing functionality.
The alternative way seams to be to merge the filter into the search bar, but that either amounts to the same or means adding a filter to the search to limit it to a specific folder, but this already exists.
> You sounds like I'm advocating to removal of both the search and the filter boxes.
That's because trying to merge them and removing the other, results in getting rid of one of two useful UI-flows. Currently it is also possible to first search and then use the filter on that. This also won't be possible when you merge them.
> Did you provided support to anyone by the phone?
Not yet for TB, but I give you that this might result in confusion. I don't think dumbing down the UI to solely improve tech support over the phone seams worthwhile.
> ctrl+shift+f - searching the mailbox.
That's yet another thing entirely. This invokes a server-side search as opposed to the two client side functionalities we are discussing now.
I uploaded a screenshot of how TB (115) currently looks for me: https://ibb.co/FbsKYF1H
Interestingly the height is less then any of your mockups. Maybe that is, because I don't have any scaling factor. My display is 1366x768, that results in a maximized window size of 1365x707. So this amounts to 32.5%, yes that is quite some space. I think in practice I tend to just mentally fade out anything above the menubar.
As I got curious I reinstalled version 102. I remember feeling disappointed about the upgrade, because there was suddenly a lot of useless whitespace, but I didn't remember anything concrete. Here is how it looks: https://ibb.co/n8P2CjB4 That only occupies 25.5%, which seams better. I am surprised how you can now select more then one item in listviews for example in the folder pane and the subscription window. This is a huge deal, because selecting hundreds of folders individually to subscribe to them is just really annoying. I think I definitely like this UI more and don't know why there was this huge UI regression. It also seams to startup faster.
How are the numbers on your computer, as it seams even worse then on mine? Do you still have the same objections to the old UI?
The search is really limited by the storage backend Thunderbird is using. Would really love to see something with full text search support, like sqlite.
My workaround for Thunderbird search is to open the Outlook web client, search for what I need, find it in a fraction of a second, do what I need to do, and close the web client. Terrible "solution" but the only one that works.
Check out what we're building: https://marcoapp.io
Basically a cross-platform Thunderbird replacement whose sole goal is to "not suck". Full-text search is entirely client side (not via IMAP) and returns results in single-digit ms.
>Full-text search is entirely client side (not via IMAP)
Setting up server-side Xapian full-text search and disabling the crap client-side one in Thunderbird was one of the best improvements I made to my email usability. What makes your client-side search better? It's usually not speed I'm looking for, but rather precision, such as double quoted phrases (sorely missing from Thunderbird's client-side search), filtering by a mixture of things, etc.
I wish more clients had an option for server-side-only search (looking at you, iOS Mail.app) and/or had a nice UI for it (ctrl+shift+f dialog in Thunderbird is janky but gets results)
We're using Orama for client-side search, which is best in class as far as we can tell, after quite an extensive period of research.
It is able to use BM25, QPS, or PT15.
We're still playing around with various weights/settings, but have seen fantastic results so far.
What do you mean by "double quoted phrases"? Do you mean the ability to search for an _exact_ term?
It needs to be open source. If it's not open source, it's a trap.
>not suck
>web-tech
Pick one.
I couldn't find any info on whether this is FOSS or what license it uses.
The fastmail web client is actually decent as such things go, and its search works ok. When I have trouble with Thunderbird search I sometimes log into Fastmail and use their web client.
Why instead of actual screenshots someone would use those abstract things?
My thoughts exactly. I used to use Thunderbird back in the day and I would like to be able to go back to it. I can’t even remember anymore what turned me away at the time. I’m always curious to see how it’s progressing though, and screenshots of a modern UI would probably get me to download.
My thought exactly. But I gave up on Mozilla for a long time. So I guess I am not as surprised and raged about it.
When I see a website advertising a product without actual screenshots, I usually assume the product is absolute garbage. But that's for commercial products normally, not free software like Thunderbird
Maybe there’s not enough workforce to do them… /s
«Manual Folder Sorting» — first, they broke 3rd party plugin for that. Next, author (not member of official Thunderbird team or employee of Mozilla) of this plugin spent more than 1 year pushing this functionality into base.
Now they highlight it as big deal in new release without mention volunteer author of this BASIC feature which should be in mail client FROM VERSION 0.0.1!
It is pity, that Google Mail is «good enough» and it killed development of good desktop e-mail clients.
Thunderbird is best what we have (Cross-platform), but still very bad, and after killing off XUL plugins cannot be easily modified.
They exists for 21 year and now announce manual folder sorting! There is no support for Sieve (3rd party plugin? Dead after removing XUL)! There is no way to store folder settings as IMAP properties, and if I have two installations (on laptop and desktop, for example) I need repeat same setting or folders again and again — including selection of identity per-folder (again, not native functionality but 3rd party plugin, thanks, it is alive now!). No true message templates (per-folder, per-action, per-identity), only lousy "signature", broken in-line quoting in plain text messages, etc, etc, etc.
And it is best what I can use cross-platform :-(
21 years of progress and now we are here.
> It is pity, that Google Mail is «good enough» and it killed development of good desktop e-mail clients.
You have to remember that when Gmail was launched it was considerably better than most desktop mail clients at the time.
It had auto-complete for who you wanted to email (prior you had to manually type their email address).
It came with an eye watering amount of storage (1 GB).
Worked from any computer (when POP was common and downloaded the emails locally to that desktop computer).
And more.
So it wasn’t so much that Gmail is “good enough”. It was more like desktop clients saw how much better Gmail was and didn’t think they could compete - also given that Google provided the hosting as well which allowed for tighter integration - something a desktop app alone could ever do.
Note: I'm not saying I think Gmail is a great experience. For web, I personally really enjoy Fastmail and for desktop - I surprisingly have grown to like Outlook. What I am saying is that when Gmail was launched, it took a lot of wind out of the sails of desktop mail app creators.
> You have to remember that when Gmail was launched it was considerably better than most desktop mail clients at the time.
It was not better for me than old FIDONet GoldEd 2.8x! It didn't (and doesn't) support proper threads, it supports effectively only top-quoting, it didn't (and doesn't) understand mailing lists in any way, it didn't support forward-as-attachment in both ways (now it supports it, though). Its filtering is still much more cumbersome than even Thunderbird one, not to say Sieve, and can be done only from web, but not from Android client. It doesn't support any crypto natively, both PGP or S/MIME.
Their are all features which I'm using daily (maybe, crypto is not daily, but still use sometimes).
Only good thing is labels, which is more flexible than tree folder structure. And, yes, full text search, obviously, as it is Google product.
As far as I remember, Thunderbird was not much worse than it is now, and it is supports most of this (though, quoting was and still is very weak, problem solved in FIDONet in 1990s!).
To be honest, I don't remember what was situation with address book and address autocompletion from it in Thundrbird before GMail, maybe there was none (but I will surprised, as, again, it worked in old TUI-based FIDONet client for DOS and OS/2), but this feature is trivial to implement in desktop app, and it could use LDAP or another centralized directory, not only addresses collected from your mail.
It was better than any web-mail, for sure, but better than desktop client? It is debatable.
1GB of storage is question of hosting, not client.
Update: Add to it modern gmail hate to self-hosting mail domains, and I could say that Google kills email as federated, free, non-vendor-dependent system. It is not surprise to me, of course, but still.
How do you do Gmail style threading view in thunderbird ? They changed the game wrt email display and 20 years later I still don’t know how to get thunderbird to do it.
Gmail:
- see all email bodies for a single conversation in one long list , like a DM in a messenger, with smart hiding of quoted text so you only see new content
- in your inbox / archive view, mix both sent and incoming emails in such conversations, so I don’t have to toggle between Sent and INBOX or Archive
I would be happy with just one of these two but I genuinely can’t hack it.
I would personally go as far as to say: any email client which doesn’t do this, is wrong.
> How do you do Gmail style threading view in thunderbird ? They changed the game wrt email display and 20 years later I still don’t know how to get thunderbird to do it.
I hate it. It hides texts, and I lost answers in this view more often than I want to admit. If it is not ping-pong conversation (I wrote you, you answer, I answer at your last answer, etc), but discussion between 3+ people where different people answer to different messages, gmail view is total mess when you cannot understand who answer to what. As I said, it doesn't support threads, only messenger-like conversations.
Any e-mail client which doesn't support tree view for threads is wrong.
You can put answers to same folder that message your answer in (any?) sane e-mail client, Thunderbird is not exclusion.
Update:
> smart hiding of quoted text so you only see new content
I've missed text hidden by mistake due to some formatting quirks more than once. It is solution in search of problem: proper quoting doesn't need any magic.
> How do you do Gmail style threading view in thunderbird ?
I used an extension once but it broke at some point.
> - see all email bodies for a single conversation in one long list , like a DM in a messenger, with smart hiding of quoted text so you only see new content
Or not so smart hiding of "repeated" content like say an image with a different URL but hey the rest of the <img> tag is the same so close enough for Gmail.
Context menu > Show message in conversation
You have to remember that when Gmail was launched it was considerably better than most desktop mail clients at the time.
There was never a time when GMail was better than plain old Outlook, but this is coming from someone to whom IMAP has always seemed like a really terrible solution in search of a nonexistent problem. My email database is important to me, and worth managing locally, as this thread more than adequately demonstrates.
Boss at the time: "You should quit using that old POP3 crap, and switch to IMAP. It's awesome." Boss a half-dozen times over the next few years: "Hey, can you forward me a copy of that email we got from XYZ a couple of years ago?"
I don’t see how IMAP would prevent you from having old emails
If you're going to keep them all locally anyway, what's the point of IMAP?
(Admittedly my judgement was formed at a time when one user, one device was the rule. I suppose if mobile access to email is important, there's a good argument for keeping the data server-side. I solve that problem with VNC.)
I’m not going to keep all of them locally, but that doesn’t mean I lose access to any of them. I can instantly access all my emails from 20 years ago.
As you mentioned I do access my email from several different devices, and each one having a different subset of my emails would be absolute hell.
I’m curious, do you log onto your computer from your smartphone in order to access your email?
I’m curious, do you log onto your computer from your smartphone in order to access your email?
Usually. If I'm going to be gone for more than a few days, though, I'll shut down the main PC and run Outlook from my laptop, which is set up to leave the messages on the POP3 server so they'll get copied into my master .PST file when I get back.
20 years means that either you maintain your own IMAP server and do a good job of it, or someone else does. In my previous company, there was always some reason why people couldn't put their hands on older emails. Meanwhile, my current .PST file goes back to 2007.
> It is pity, that Google Mail is «good enough» and it killed development of good desktop e-mail clients.
Microsoft Outlook has a very large market share in the business world. There is an old and a new GUI design version, and you can run the app, or use it online.
I don't like the presentation of the individual emails especially, I find the thread-view hard to understand, especially on mobile, but it works. Personally, I would have preferred the older folder presentation designs of 20+ years ago, for me this app is trying to be too clever - in both the old and the new GUI version. However, it is just so very widespread. I have to use it because everybody else in the company uses it.
They support a huge amount of scenarios and edge cases that many businesses now depend on, combined with all the Microsoft server side and infrastructure stuff they have of which the emails are just a very small part now.
Outlook is more groupware client, than e-mail. Also, to-quoting only (AFAIK, it is THE place where top-quoting was invented).
Also, when I was forced to use it (to be honest, about 10 years ago) it works terrible with IMAP (as opposite to Exchange) servers.
>Google Mail is «good enough»
I hadn't really used Gmail or Google products much, until I started at my last job, which was balls deep in the ecosystem. I loathed Gmail. One of the worst email "clients" I've used. After toggling a load of stuff in its settings it was usable, but dealing with email was a low point of my work day.
New job is Microsoft based, so Outlook, and I haven't used that in 20 years, so it will be interesting to see how enshittified it has become. I will have to run Windows on my work pc, which I'm not looking forward to.
What was so bad about GMail? I’ve worked at some companies that use it and I liked it much more than Outlook.
I’ve been using Thunderbird more and more over the past few months. I’m glad it’s finally getting some decent attention. I’m especially curious about the new account management in 140. I couldn’t add my iCloud calendar easily before, hope this rectifies it.
If you haven’t given Thunderbird a shot yet, you should.
I've been using a fork of Thunderbird called Betterbird (https://www.betterbird.eu/) on Linux, mostly because I want to be able to minimize it to a systray icon. I know there are extensions like systray-x and birdtray, but I was having issues with these on Wayland. I wonder if this new version of Thunderbird finally added systray support on Linux/Wayland.
I just switched away from it again after it got delisted from nixpkgs due to lack of development[0][1]
[0] https://search.nixos.org/packages?channel=25.05&from=0&size=...
[1] Should be this one https://github.com/NixOS/nixpkgs/pull/351205
>due to lack of development
???
https://github.com/Betterbird/thunderbird-patches/commits/ma...
> I wonder if this new version of Thunderbird finally added systray
I'm waiting for this feature since when I used Thunderbird in Windows XP. At the time I used the MinimizeToTray addon...
I won’t switch to BetterBird because the person behind it seems off.
Feels a bit like switching to TempleOS.
Honestly I don't see the Terry vibes. It's just someone who's really, really into email clients lol.
>Feels a bit like switching to TempleOS.
That's... not a bad thing, though? Terry was an extremely competent engineer and programmer who designed his software to be as user-friendly, well-documented, and performant as possible.
I have conversed with Jörg, and he is blunt and fair in a good way (code itself is emotionless, after all). And, of course, he is highly competent. I have also conversed with several Mozilla teams, including Thunderbird, and the experiences were universally horrible, as in they lacked core competency. Naturally, YMMV.
There is no mention of sync functionality. I regularly use 3 different PCs and I cannot sync settings easily. It means I've give up using Thunderbird on all but one of the PCs.
They've also made the usability worse in recent versions and are copying the insanely annoying context menus in Windows 11, which cannot be reverted.
I covered that and the alternative in my Register piece. You might find that useful.
https://www.theregister.com/2025/07/09/new_thunderbird_esr_i...
Thank you. I will take a look this evening.
Sync? Just connect to your accounts on each machine? Or are you using POP3 and want that to sync?
You need to export the profile and re-import on each machine. If you make any changes on one machine you want to see it reflected on the others.
The profile import is a bit iffy and there was some odd issues with downloading profiles over 2GB IIRC, the last time I did it (which was over 2 years ago).
There seems to be a lot of focus on features that IMO that I couldn't care less about and some outright stupid UI decisions like the context menus being changed after 20 years for god knows what reasons.
The result was that I just gave up and use Thunderbird on one machine and web-mail on all the others. I suspect I will just drop Thunderbird as a result.
I guess they mean that they want their accounts to be synced (setup is annoying tbh), but also things like signatures and so on.
I normally just manage it myself and I'm extremely happy to do so, as I consider it like my dotfiles, but I understand where the parent is coming from - settings sync is becoming common. (Chrome is a good example).
All I need out of it is a slightly sensible file based config scheme. Syncthing will do the rest.
Sync could be implemented using special email and IMAP servers for storage...
Also gave up Thunderbird years ago because of the same reason. Just wanted something stable and chose Spark. Works on every device, not a problem for years.
> Spark: AI mail.
To the hell with AI. I just need a stable email client.
Thanks for the suggestion.
No Linux client.
> While we can’t change the universe, you can now get the latest Thunderbird features as they land, instead of once a year. Switch to Thunderbird Release and enjoy monthly updates with the same dependable stability.
Does this mean anything or is it some sort of marketing gobbledygook? We can now get features faster by using the latest release rather than the ESR – but surely non-ESR releases have always been available, so this was always the case, not only now suddenly?
Also, the "dependable stability" we enjoy with the ESR release comes precisely from the software not constantly changing underneath us, i.e. from not getting new features every month.
I have not used Thunderbird in 15 years, but I'm desperate for a decent email client. I've used Spark, Mailspring, Airmail...but I keep coming back to the MacOS Mail app. Any active users of Thunderbird who chose it over the default Mac mail client? Does it have a unified inbox for all your accounts? Dark mode looks neat, at least.
macOS Mail app is still the best native e-mail client in my experience.
I have switched to Thunderbird full-time since I switched to Linux. Can confirm it supports unified inbox.
It'll sound crazy: I've never used Macs, but the IMAP-based client was Outlook Express back in 2005-2010.
100% multi-thread download and synch of folder contents, instantaneous display of messages, super-responsive.
I've tried a lot of clients on Windows and Linux and none of them get near the experience I had 20 years ago.
That's good to know. The Mail app shortcut keys don't make a lick of sense, but I don't mind that as much as the inability to zoom in on images in a message. No pinch and zoom on an image is diabolical in the MacOS ecosystem. Do you miss anything about Mail now that you're Thunderbird full-time? Anything you prefer in Thunderbird over Mail?
try Mimestream
Is Oauth accounts with an authenticator working yet? I desperately want to use it at work, but we have O365 with Okta and Yubikeys in front of it, and Thunderbird can handle the Okta but won't prompt for a PIN for the Yubikeys.
As a workaround, consider using https://github.com/simonrob/email-oauth2-proxy
>Experimental Exchange Support Natively set up a Microsoft Exchange account in Thunderbird by enabling a preference.
Its cool that we don't need a third-party plugin for that anymore.
It's incredible that this is only arriving in 2025.
The only feature I am missing in Thunderbird is “group by sender, sort groups by latest receive date in group”. I don’t remember what client I used that had this (outlook, perhaps?) but for me it works so much better than other arrangements:
You still see all the latest correspondence, but also immediately all previous correspondence from the same sender (if you expand the group) whether or not it’s a reply thread.
Thinking of trying it, when Mozilla finally fixes the lack of XDG base directory support. There was some recent progress on that old bug.
No thanks. We're still sticking with version 102, the last release before the ruinous "Supernova" redesign which nobody asked for, when it became apparent the project was being abused by "UX" kiddies looking to bloat their Github resumes. We're just thankful that some wiser developer had previously added the "allow-downgrade" option.
(In case you haven't heard of it and it proves helpful to you and/or someone else:)
Have you heard of Epyrus?
Homepage: http://www.epyrus.org/index.html
(The download link is easily found there, as well as git repository and forum links.)
It's based on UXP (the Unified XUL Platform) and is thus related to the Pale Moon browser (which doesn't bother me). I've been using it on Linux as a way to have an "older Thunderbird" look and feel, e.g., I have real scrollbars, and the "Send" button didn't mysteriously vanish from the Compose window with no way to get it back upon some "from the ground up redesign" upgrade.
EDIT: Typographical error, phrasing.
If you want really old school Thunderbird, Seamonkey's still around.
I only use the browser portion, so I can't say how good the email is.
Whenever Thunderbird makes its way to the front page of Hacker News, I always re-download it and hope that I can use it.
Every time I've ever tried it (spanning around 30 installs over the last 15 years), I've uninstalled within a week to a month, due to sluggish UI, phantom unread emails, crashes, and text formatting issues.
I do it because I believe that one day Thunderbird could be good. Today could be the day - I've installed it, added my accounts, and it looks like the developers have made some significant improvements. I'm not talking about fancy new features, instead I'm talking about the small nitpicky problems I've had whenever I've tried to use it.
For example, this time I installed, I didn't have to go into a hidden settings menu (here be dragons) to make new emails default to the top of lists. My replies are now made above the original message. Fastmail doesn't throw a wobbly when trying to add email, calendar and contacts with the same password.
Maybe today is the last time I install Thunderbird?
I don't have any of those issues, besides perhaps crashes but the last one must be two years ago (I remember because we're always watching for exploits coming in). Maybe nobody else has these issues you mention either. If you want them to be fixed by the next time you install, have you considered reporting the issue and seeing if there is a volunteer is willing to fix it for you?
I have used Thunderbird in the past, but ultimately gave up.
I am currently on google for my private email, and for other reasons tied into MS / Office365 anyway for my business so decided after having my business email at my internet provider initially, it all was just not worth the hassle.
95% of my business dealings is with companies that are on office 365, and especially the calendaring and RSVP'ing just kind of works in outlook.
I am still keeping an eye out and hope to be able to move to some solution which unifies it all, preferably on a nice open standards, open source solution for email, calendaring, and contacts.. but the fact is that customers pay my bills, and I grew tired of all the account issues, syncing issues etc with trying to have it all in Thunderbird.
I find it a sad state of affairs though, the amount of engineering time, energy, and money spent on building semi-walled gardens and at the same time building ladders to climb those same walls, all while never achieving an actually smooth experience between my various email accounts, my calendars, on my laptop and phone alike.
Maybe some day.
From a business user perspective you need more features. From a home user I sort of want to have an even more stripped down email client.
Thunderbird does at bit to much for my liking. The UI is a little messy.
> Manual Folder Sorting
> Don’t like the order for your custom folders? Just click and drag to arrange them exactly how you want.
At last. Thank you.
I've been using an add on for that for a long time. It stopped working about one year ago because of some change in TB. I managed to survive but I really look forward to the update to 140.
Thunderbird is still the only calendar software I'm aware of with a "Multiweek" view instead of the awful "Month" view all others provide. The only calendar to have caught up to 20th century technology (Apple almost gets it, but not quite).
It really hasn't though, doesn't even have multiple time zone support for events. They really need to fix that.
God, the dark mode change reading is a blessing !
See https://drgrizz.xyz/dark-mode.html why
The person in question has a relatively rare medical condition, for most people dark mode reduces readability as a darker screen leads to more pupil dilation which causes halation. (which you can test out yourself if you stare at dark mode text and then look at a bright surface, you'll likely literally see a halo of the text).
This is worse in people with astigmatism, which is about 35-50% of the population. Dark mode defaults, as on that website, need to die. Most of the time they're used because people use their digital devices like goblins in a cave and don't light their rooms properly, or configure their brightness settings correctly.
Surely this can't be that universal, right? I will have to do this test at some point. I have astigmatism but I find the default bright version of websites frequently painful to look at. I have no clue why but I need the dark versions.
My strategy has been to use light mode all around but I have f.lux set to about 20% strength all day long. I also have my monitors dimmed a fair amount unless I want to display HDR. It also helps to have a bias light behind your screens if you can.
My goal was to get rid of the 2pm eye twitch and I've mostly got it.
If websites are generally too bright, you can save energy as part of increasing comfort by configuring your display to put out fewer nits (reduce its brightness setting). Usually people have the opposite problem, especially if there's direct sunlight on or near the screen, so that's probably what the factory default optimises for
> So please fellow developers, help spread the darkness to make the world more inclusive.
He ought to practice what he preaches. Due to a combo of shitty eyes and dyslexia, I cannot read his site's dark theme without getting a headache.
I never thought that dark mode could make things less readable. I'll lokk into it. Though I don't know what Pelican offers to switch theme live.
I’m not sure what you’re asking for that person to fix, it’s just plain text and a plain dark background.
You can also read the site in reader mode.
If you have astigmatism dark mode is hell. Should be called nausea mode.
First time I hear someone describe nausea from dark mode. Quickly looked astigmatism up on Wikipedia - isn't that something glasses fully correct? I think I've got this as well, but not sure, I've just always had glasses and take whatever they measure to be the best possible lens
(Of course I critically evaluate the measurement, like one time I actually couldn't read faraway text with what they were proposing whereas I could with my old glasses. But I don't know the exact values or terms for the different defects, I think my eyes have at least three different issues including something about rotation as astigmatism apparently means)
I guess what I'm asking is why you don't have glasses. Are they too expensive in your area, or the defect only very minor so it doesn't impede safety when driving even on highways? (Then I'm surprised you get nauseous though, since I don't when I read anything without glasses, regardless of dark or light mode.) Or if you do have glasses, is this still an issue while wearing them? If so, any idea why?
I have glasses. They greatly ameliorate the issue, but not completely. My prescription is a single number which I don’t believe has the necessary granularity (I think, intervals of 0.25) to express the exact prescription I need. I also suspect that astigmatism is a deformation of parts of the eye that cannot be expressed with a single number. It’s possible I should have gone to an ophthalmologist instead of an optician in a mall but that’s what I did.
Also I generally don’t wear the glasses unless I’m working (with a computer of course) or driving. I also have myopia, but both my astigmatism and my myopia are mild. The problem is much more severe when it’s dark, so I always wear my glasses when it’s dark and I very rarely wear them during the day. I must always wear them if I intend to use the computer for a long time, though. Especially if I’m staring at a terminal or whatever else with white letters on a black background. But I don’t need them to read (black on white, not too far away) or to use my mobile (always closer to my face than my monitor).
Judging the distance/speed of other cars during the night without glasses is simply impossible despite my mild prescription.
This is very interesting, thanks for sharing details. A friend with strong corrections in their glasses always mentions they feel like they can't see much in the dark, not as much as other people anyway, but we've never been able to quantify it (that they don't see something that I do). That you always wear them in the dark sounds to me like it's indeed more important to correct this effect for dark backgrounds, which I had no idea about
Another comment I saw in the meantime, https://news.ycombinator.com/item?id=44520306, proposes a mechanism for why one might have what I'd call ghosting if it were a computer screen (apparently it's called halation for eyes). That that can lead to nausea or generally feeling like things swim together and you can't see as well makes sense, this might explain a lot
I'll mention this to the friend and maybe we can do some tests in the dark with moving objects rather than just "can you see that thing there". Maybe after all these years we can get to the bottom of this issue they've had all these years :D
It’s not ghosting, it’s halation as that bloke said. Bright things do not leave a trail, instead they are just blurry.
If I see a white LED in the dark, the LED shows some sort of smear at a certain angle and with a certain length. The length of the smear decreases the closer I get to the LED. It doesn’t change ever, even if days pass, because it’s a static deformation inside my eye. It does not leave a trail if I look around or if I move the object with the LED.
This also applies to white letters on a black screen. They are smeared at an angle. If I’m far away enough and/or the letters are small enough the smear is so large that they make it hard to read and make me nauseous. That’s why I ended up buying the glasses.
https://pixelbuddha.net/storage/51621/how-to-create-a-motion...
This is an example. The trail is not as long but it’s brighter. (Just googled “motion blur letters” - the effect is similar)
Oh! I see, I guess the "then look at a bright surface" part of that other post made me think of that an image stays with you for a short time (a ghost image), but I get what you mean now
They could include a light theme.
It seems pretty hypocritical that they're claiming a lack of dark mode is an accessibility problem while lacking a light mode.
Technically it’s not really hypocritical because the author never claimed that a lack of light mode is an accessibility problem.
I think it’s also notable that websites being accessible isn’t really about being tied to a specific theme, it’s about being compatible with accessibility tooling and standards (screen readers as an example). There are plenty of CSS manipulation tools that can make a website look whatever way you want.
Then all that'd apply to sites not having a dark theme, undercutting the author's point because he could just use stylus to.make his own dark theme for sites.
And if I understand you right, you completely miss the point of the article.
I'm already resorting to tools and workarounds (ie Dark mode reader, invert image extensions, invert colors on phone). But
Builtin dark mode on websites and apps would just be net benefit for me for little cost.You understood them wrong I think. dangus seemed to suggest CSS manipulation tools were enough for people who wanted a light theme.
A friendly public service announcement:
From the Inbox screen on Thunderbird, hit Ctrl+Shift+F for a powerful search function
I love Thunderbird, but the compose message window is just shit. It allows to sslect text type like body, paragraph and so forth - but it always resets to paragraph for me, which leads to weird spacing between lines.
It is really rough, I wish it would get some love ( a lot of love actually). There are bugs everywhere
I love that Thunderbird is moving forward.
That said:
I tried to add a new mail account to Thunderbird after upgrading to version 140. Unfortunately, it shows an error message after merely asking for my name and my email address and then hangs in an endless animation.
I'm sure some Thunderbird devs read HN, but if you'd be interested in helping more people with this comment, I'd log it at https://bugzilla.mozilla.org/enter_bug.cgi?product=Thunderbi...
Since some months somehow the windows are weirdly aligned inside Thunderbird, like the attachment bar is cut off at the bottom. I might be connected to my Awesome WM but I haven't changed anything on this side.
Anyone else noticed something?
The only thing I noticed from the previous update was that some view settings seemed to have been reset, otherwise no layout issues that I can recall.
So we have "OS-native notifications" now. Does that mean we finally get a tray icon? Or do I still need to keep Thunderbird sitting in the taskbar for that?
If not, I guess I'll be keeping birdtray installed for now.
Any sense on how JMAP support is coming along?
I used TB for a decade or more, then in the end quit, because it was bloating too much. It was a browser doing email, not an email client.
I then used Claws for a while, but came to really dislike it - lots of small UI issues.
Then I wrote my own email client in Python, Postgres for store, Apache/HTML front-end. That's been fantastic. Python does all the heavy lifting, you need to design a decent database.
Now I add features as I need them - few days I added the ability to specify how many times an email should be sent, when you need to spam the recipient for some reason (say, a company which is spamming you and is not responding in a reasonable or timely manner to GDPR requests).
The basic client design I've not seen elsewhere - but I've not used many clients so it may very well exist. There's a single inbox of email, and you define sets, and a set defines what is shown. So you don't move emails around between folders, you define what's shown, and you can have multiple sets concurrently - so for example, "inbound", "last 24 hours".
There are also a bunch of other small features which I've had in time for a long time but have never seen. For example, the from/to addresses have the localpart and domain separately, so you can order by domain. There's immediate in-page filtering, too, for each column, so you can just enter a few letters of what you know is the origin domain and bingo, there you go.
I had to stop using Thunderbird because it's just too slow for me. And I have a pretty decent PC.
I'm pretty happy with Mimestream on MacOS.
impressive how, in 2025, thunderbird is still the best email client on osx
That’s not been my experience, but everybody’s needs are different I suppose.
What do you use?
Apple Mail. It covers the bases, doesn’t try to cram too much into a single app, and doesn’t lean into badly aging UI trends.
I’ve tried Thunderbird a few times over the years (including post-redesign) and it’s always felt clunky and kinda awkward. Firefox somewhat outgrew that but Thunderbird never did.
If I were to use something else, it’d probably be MailMate which is a lot like Apple Mail but with even fewer frills and more optimization.
[dead]
[flagged]