Live data from Hacker News

Thunderbird 140 “Eclipse”

blog.thunderbird.net

71–80 of 297 posts

Re: Thunderbird 140 “Eclipse”

#71

Earlier quoted context omitted.

Because it has to be reproducible. Help make it reproducible and show that to the developers.

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.

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.

Re: Thunderbird 140 “Eclipse”

#72

God, the dark mode change reading is a blessing ! See https://drgrizz.xyz/dark-mode.html why

> 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.

Re: Thunderbird 140 “Eclipse”

#73
post #10
post #3

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.

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.

Re: Thunderbird 140 “Eclipse”

#75

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_…

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, b…

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.

Re: Thunderbird 140 “Eclipse”

#76
post #62
post #61

Earlier quoted context omitted.

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 a…

Just do a complete rewrite in rust, that will solve all the issues

Re: Thunderbird 140 “Eclipse”

#77

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.

Re: Thunderbird 140 “Eclipse”

#78

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_…

Hopefully this prompted you to check your backups?

Re: Thunderbird 140 “Eclipse”

#79
post #59

Earlier quoted context omitted.

Because it has to be reproducible. Help make it reproducible and show that to the developers.

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.

Re: Thunderbird 140 “Eclipse”

#80
post #59

Earlier quoted context omitted.

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.

Kinda off topic, but I've been searching for good introduction and best practises for defensive programming, but never really found much. Any recommendations?

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.

Post reply on HN