Live data from Hacker News

Thunderbird 140 “Eclipse”

blog.thunderbird.net

231–240 of 297 posts

Re: Thunderbird 140 “Eclipse”

#231

Earlier quoted context omitted.

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

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

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

Re: Thunderbird 140 “Eclipse”

#232

Earlier quoted context omitted.

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

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

  > are you being for real?
Yes

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

Re: Thunderbird 140 “Eclipse”

#233
post #226

Earlier quoted context omitted.

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

> 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

Re: Thunderbird 140 “Eclipse”

#234

Earlier quoted context omitted.

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

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

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

Re: Thunderbird 140 “Eclipse”

#235

Earlier quoted context omitted.

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.

Re: Thunderbird 140 “Eclipse”

#236

Earlier quoted context omitted.

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

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

Re: Thunderbird 140 “Eclipse”

#237

Earlier quoted context omitted.

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

> are you being for real? Yes > 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 rewri…

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

Re: Thunderbird 140 “Eclipse”

#238
post #84

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

Re: Thunderbird 140 “Eclipse”

#239

Earlier quoted context omitted.

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

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

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

Re: Thunderbird 140 “Eclipse”

#240

Earlier quoted context omitted.

> are you being for real? Yes > 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 rewri…

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

  > UNLESS YOU CAN VERIFY ITS FIXED
Ummm...

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?

Post reply on HN