I could be entirely facetious and tell you to buy something other than an apple product. It is a "feature" unique to them.

All you can do is change the location used to "download" your attachments.

Thunderbird > preferences> attachments > incoming and change the storage location.

Matt said

I could be entirely facetious and tell you to buy something other than an apple product. It is a "feature" unique to them. All you can do is change the location used to "download" your attachments. Thunderbird > preferences> attachments > incoming and change the storage location.

This is not helpful. Here's how I want TB to work:

1. If I want to save an attachment, ask me where.
2. If I just want to read an attachment, either don't save it anywhere or store in a location I choose and set in Preferences (e.g., Downloads or ~/tmp)

There's a difference between saving an attachment and viewing it. TB doesn't make the distinction. This is a bug, not a feature.

Gnosos said

This is not helpful. Here's how I want TB to work:

1. If I want to save an attachment, ask me where.
2. If I just want to read an attachment, either don't save it anywhere or store in a location I choose and set in Preferences (e.g., Downloads or ~/tmp)

What you want is not relevant here. Sorry. This is a support forum, not somewhere for discussion on what features should be present and what should not.

The decision was made that on Apple OSX would be different. Windows works the way you like, and does Linux.

There's a difference between saving an attachment and viewing it. TB doesn't make the distinction. This is a bug, not a feature.

Thunderbird makes the distinction on Windows and Linux.

You use an apple product where other decisions were made, so that is not how it works. It was argued at the time that that is not the expectations of the majority of OSX users, but there are technical issues with OSX as well I understand.

If you feel strongly that the behavior should be changed you might want to follow this bug https://bugzilla.mozilla.org/show_bug.cgi?id=1387292

Read comment 2 particularly.

Thanks for the link. I had no idea this problem has been an issue for so long.

I first used Unix in the 1970s. By the early 1980s, when I attended an orientation to Unix at a different institution, I knew Unix well enough to understand what the speaker meant when he said, "You can do anything you want in Unix."

In light of this, since MacOS (the OS formerly known as OSX) is based on BSD Unix, I'm unwilling to accept at face value that TB acts the way it does because "there are technical issues with OSX."

MattP's summary comment at the end of Bugzilla 1387292 says the problem is in a "library/toolkit maintained by Mozilla." But, if true, this just kicks the can down the road. Either the toolkit needs to be modified (preferred solution) or TB code should not use the toolkit for this particular purpose and work around the problem instead.

Still, having used such toolkits myself, I'm skeptical. It seems more likely that the TB programmer is using a single communications channel, for viewing and saving attachments, when two separate ones are called for.

Perhaps someone can explain the problem. After all, with open-source software this would be a first step anyone else would need to find a solution.

But from a general application architecture perspective, it's hard to imagine any technical issues that would dictate TB behaving this way. IMHO, it's simply a matter of taking the current system, which conflates viewing and saving attachments, and breaking it into two parts. One part would do what it's currently doing when viewing an attachment but let users choose where the temporary files go. The other part could separately implement a default location to save files to, although to me this seems unnecessary. For deliberately saving files, the current "Always ask me where to save files" seems sufficient.

One additional comment: I went back and reread MattP's summary in the Bugzilla record. AFAICT, he presents an actual fix for the problem.

Basically, it boils down to confusing language and option behavior on the Preferences > Attachments > Incoming page.

The page has two radio buttons, one for "Save files to ...," and one for "Always ask me where to save files." Generally radio buttons are for mutually exclusive choices, but not in this case.

If one sets the first button, "Save files to ...," to a location for storing files temporarily and then selects "Always ask me where to save files," TB will store its downloaded files for viewing in the temporary folder but still allow the user to choose where to save files when deliberately saving them.

Part of the issue is language. The term "save files" is used for each radio button, but in TB's context menus "save file" refers to deliberately saved files. The term TB uses for files that are viewed but not deliberately saved is "open."

People like myself don't learn that when they "open" files TB is actually storing temp files on their Desktop until they notice so much junk that they search for forums like this.

The other part of the issue is behavior. Ordinarily, when one deselects a radio button, it's entirely inactive and has no effect on an app's behavior. But not in this case. Instead, the location chosen while the radio button is selected will still be in effect for the "temporary" files downloaded for viewing, even when the "Save files to " button is no longer selected.

So the temporary files for viewing will continue to go to the "Save files to" location, while TB will allow the user to choose where to store deliberately downloaded files.

What part of this is not a place to discuss feature requests did you miss. I can not help you and I seriously doubt anyone but you will ever read what you have written. Good luck.

C'mon, don't be so rude.

I did get that this is not the place for feature requests. My most recent post is intended to help anyone who runs into this problem. By no stretch of the imagination is it a feature request.

Yes, it does explain why the workaround is not obvious. But explaining why a workaround works, due to an app's unexpected behavior and despite the wording of its menus, is not a feature request.

My second-to-most-recent post simply explains why I don't buy the argument that there's something about Apple OSX/MacOS that makes such behavior inevitable.

There's a fine line between a problem that many people have encountered, a workaround for the problem, an explanation for why the workaround works, and a request for eliminating the problem by slightly revising a menu's language and the app's behavior. Only the last counts as a "feature request" (or bug report), the first three items are, IMHO, very appropriate for a support forum.

And even then, if the back-and-forth on a support forum leads to the discovery of a bug, then it's perfectly legitimate for the particular thread to include suggesting the OP report the bug.

Finally, regarding my post on 5/27 when I said, "Here's how I want TB to work," would you have been happier if instead I'd said, "How does one get TB to do the following"?

You did point me in a direction that helped me work around the problem, and for that I thank you. You have been very helpful.