Steps to reproduce:

1. Send yourself an email with multiple small attachments.
2. Select a subset of these attachments, right click Save As
3. Select the destination, click Save

At this stage, Tb prompts me for each file regarding the save location. When a client sends you dozens of small files, of which you may only require a subset, that turns into a bit of a clickfest and often the only time saving approach is to Save All and then delete them in Explorer.

I can't think of a use case in which a user wants to save a subset of attachments but each into a different location, the most obvious scenario is that the files in an attachment are usually related to a task and most likely to end up in the same folder, so I suspect this is a bug rather than an enhancement.

Alfred, do you also see this on win10?

Yes, this was mentioned in bug 1565007. The complaint there is that it even loses the last directory used :-(

Fortunately on Win 10 it doesn't lose the directory i.e. it prompts me for each file but it stays within the same directory.

(In reply to Michael Bauer from comment #0)

I can't think of a use case in which a user wants to save a subset of attachments but each into a different location, the most obvious scenario is that the files in an attachment are usually related to a task and most likely to end up in the same folder, so I suspect this is a bug rather than an enhancement.

Hmmm. I wouldn't consider this a bug. It's quite easy to imagine use cases where different attached files must go into different folders, even if they belong to the same task, because that task can have logical subfolders - e.g. one project can have planning, quotations, internal-auditing, press communications, orders, etc. Furthermore, the per-attachment save-as dialog is a big advantage for users who want immediate control over the file names before saving - sender's file names and my preferences might differ. I think this is currently the only way of being asked for a file name for each attachment, so I recommend against removing this feature until we have implemented some other way of making both sorts of users happy. That said, this is a perfectly legitimate RFE and we should consider ways of enabling this. As a start, at least having bug 1565007 would go a long way, because having to adjust the desired path for each and every file is certainly annoying.

Different users, different needs. Some need control over folder and file name for every attachment. Some may need only folder control for each file, some only file name control for the same folder. Some may want to save any attachments with sender's file names into a pre-defined download folder (a feature which exists but doesn't work iirc). We should find intelligent ways of providing for some of these different needs. I have pointed out some of these problems long back on related bugs, without going too deep into solutions.

I suspect that additional context menu entries may help for some cases. Like for this bug, what if we had this:

• Save As... -> save-as dialog for each file (full folder and file name control), but probably remember the last picked folder
• Save To Folder... -> show folder picker, save all selected attachments to that folder (folder control, no file name control).
  If we want to revive the broken "fast save to default folder" feature (like the Downloads folder in FF), we'd need a third entry:
• Save to "My TB attachments" (name of the user-defined one-for-all default folder) (user-pre-defined folder, no file name control)

So the entire context menu would look like this:

Open...
Save As...
Save To Folder...
Save To "My TB attachments"
-----------------
Detach...
Delete

Imo that's totally viable, still very limited number of options, easy to understand, catering perfectly for different users with different needs.

(In reply to Michael Bauer from comment #3)

Fortunately on Win 10 it doesn't lose the directory i.e. it prompts me for each file but it stays within the same directory.

Not for me. It remembers the last used folder only for my NEXT round of saving attachments. If I change that remembered folder on the first of multiple attachments, the next attachment is back to the previous remembered folder - definitely not helpful.

I'm inclined to disagree that this change in behavior isn't a bug. If a user wants to save files to different directories, can't that be accomplished by saving individual files?

You're aware that you can drag multiple attachments into the same Windows folder?

How is that supposed to work? If I select 2 out of 3 files for saving, then Tb opens two separate windows and I cannot select or deselect attached files for drag and drop. If the suggestion is I do a split screen with Explorer and Tb to save files, then that's not practical. I rarely have the target folder open in Explorer because my workflow does not take me via Explorer other than doing a Save As, the next step is to open the program I'll be working in which usually has Open File pointed at the right directory for the files I saved in Tb (usually one level up) so I don't go via Explorer at all. I'd have to open Explorer, navigate to the right directory, pummel Win10 into doing a split screen and then drag and drop. Hardly a time saver.

I think I agree that we should prompt the user only one time if multiple attachments are selected.
If the user wants to save various attachments in different folders, he will select them accordingly, but if he selects 2 or 3 to save at once, we can safely assume that the intention is to save them all in the same directory, therefore a single file dialog should be used.

XREF: Bug 448580 which requests the opposite: Save-ALL should have a flavor of prompting with one Save-As dialog for each attachment, so as to allow user to chose different folder / file name for each attachment efficiently.

(In reply to Alessandro Castellani (:aleca) from comment #11)

I think I agree that we should prompt the user only one time if multiple attachments are selected.
If the user wants to save various attachments in different folders, he will select them accordingly, but if he selects 2 or 3 to save at once, we can safely assume that the intention is to save them all in the same directory, therefore a single file dialog should be used.

I agree with the solution proposed by Alessandro Castellani.
I just updated Thunderbird to 68.5.0 (64-bit) and there is not this suggested changed: the behavior of TB is like I described it in Bug 1606045.

(In reply to Dossi Pietro Paolo from comment #13)

I agree with the solution proposed by Alessandro Castellani.
I just updated Thunderbird to 68.5.0 (64-bit) and there is not this suggested changed: the behavior of TB is like I described it in Bug 1606045.

Hi Dossi, please don't rush to agree with specific solutions when you haven't even clarified your scenario on bug 1606045.

This is your expected result from bug 1606045, comment 0:

TB should present the save window for the first attachment; for the second attachment TB should present me the same folder I chose for first attachment.

So from that, your request appears to be simply about restoring the legacy behaviour by eliminating bug 1565007: For multiple selected attachments, you'll pick a folder in the first dialog, then just pressing Enter repeatedly will easily save all of them into the same folder, using sender's default file names. At the same time, only IF you so wish, you or other users are still free to chose a different file name and/or folder for saving each selected attachment, or some of them. The behaviour suggested by Alessandro does NOT provide your expected result ("present the same folder I chose for the first attachment...", i.e. present the save-dialog for each attachment). More so as your scenario of bug 1606045, comment 0 explicitly involves Ctrl+A to select all attachments before saving, so if you just want save all of them into the same folder with default names with only one folder-picker-dialog for all, you could just use "Save all", which already exists as a feature and works correctly.

(In reply to Alessandro Castellani (:aleca) from comment #11)

I think I agree that we should prompt the user only one time if multiple attachments are selected.

Implementing that as a new feature as described in this bug would be great. Enforcing that for everyone would be a massive loss in ux-efficiency.
Notably, users have never complained about getting one dialog for each selected attachment until the regression of bug 1565007 occured.

If the user wants to save various attachments in different folders, he will select them accordingly, but if he selects 2 or 3 to save at once, we can safely assume that the intention is to save them all in the same directory, therefore a single file dialog should be used.

What if I want to save the selected attachments into the same folder, but rename each file before saving? Sender's attachment file names may not match my needs, and having to go back to Explorer, find the same files again between dozens or hundreds of others, then rename them from there whilst in TB I have them right in front of me would be quite clumsy...

The truth is, different users have different needs, and we cannot safely assume much...
The currently intended behaviour of one consecutive "Save as..." dialog for each selected attachment (consecutively remembering the last used folder: bug 1565007) provides a very good one-for-all behaviour:

• Scenario A: save selected attachments into the same folder, using sender's file names:
  pick a folder in the first dialog, then just press Enter for each subsequent attachment - simple enough. We could make that even simpler by implementing this bug 1595732 as a separate fast-track action.
• Scenario B: save selected attachments into the same folder, but rename each file before saving - works like a charme.
• Scenario C: save selected attachments into different folders, with or without renaming files - still works like a charme.

Not sure I understand this forum. I did a search for bugs of the same likeness and the search did not reveal anything like the problem I was seeing so I started a new thread (1614721) only to see today that it got marked duplicate (and vice versa) with bug 1565007 that was posted a year ago (though my problem is much more recent), certainly identifying the same behavior on different versions. That page linked me to this page which seems the best discussion on the matter but it also mentions bug 1606045 which also sounds the same behavior. Some of the bugs are marked as "resolved" but the problem remains even though I updated to 68.5 today.

And I have no idea whether this is intentional or a bug, following the comments of this thread; but I have been using Thunderbird since it forked off the old Netscape Central (or whatever it was called when the Netscape web browser was packaged with an e-mail client, a calendar, and even an HTML editor back in the late 90s); and until very recently (the last few weeks) I cannot recall ever running into Thunderbird opening multiple save dialog boxes simultaneously; they always came at me consecutively (allowing me to select the first folder; and then I could change folders if I wanted on subsequent or just keep saving to the folder I just picked). [I note this is a long running topic as Thomas D points out 285997 was posted 15 years ago.)

As this seems the best discussion on the current matter my comments germane to this discussion--not quoting everyone as I have read the whole thread:

I like Thomas D.'s suggestion of multiple Save options (Save As, Save to Folder, Save to [pre-defined folder]). Although the previous versions really allowed both options simply by allowing me to either select one folder and hit the save button several times; or to select different folders as I moved through the files, and even allowed changing file names if needed, simply by opening each save dialog box consecutively (instead of simultaneously). While it may make sense to presume the user wants to save in the same folder for all selected attachments, sometimes I do save some to one folder then to another folder. But each time if the next dialog box starts in the folder selected in the previous dialog box this has been fine for me, to make a change and continue--as usually the difference in folders is only up or down a level in the tree structure.

However, I have to send a special thanks to Jorg K. I learned something new today. And now I may just change my own methods, at least for the larger groups of attachments. I had never even bothered to try dragging multiple attachments out of an e-mail (into a windows explorer folder). [Though it makes sense, I sometimes drag multiple attachments into an e-mail I am writing.] I almost always open the windows explorer folder I am saving to anyway to drag and drop the same multiple files (usually pictures into Photoshop) into the software I will be editing them in. That method would actually save me many clicks even if the bug is resolved (though I may have the bad habit of dragging them to my desktop which is already messy).

Thanks Jorg K! You made me a happy man today.

But I still call it a bug; because it is definitely different behavior than previous versions.

One more comment, another indicator this is a bug not a feature; is that I also note that with multiple attachments, sometimes it opens only two boxes simultaneously and the rest come consecutively; and sometimes it opens more than two save boxes simultaneously (they overlap; but I can drag them around the screen to see how many it opened any given attempt). It isn't even consistent in how many it opens up simultaneously even with the same set of attachments. So that suggests it is a bug; and that the intended behavior is to open dialog boxes consecutively.

(In reply to Nathan Tyler from comment #17)
(In reply to Nathan Tyler from comment #18)

One more comment, another indicator this is a bug not a feature; is that I also note that with multiple attachments, sometimes it opens only two boxes simultaneously and the rest come consecutively; and sometimes it opens more than two save boxes simultaneously (they overlap; but I can drag them around the screen to see how many it opened any given attempt). It isn't even consistent in how many it opens up simultaneously even with the same set of attachments. So that suggests it is a bug; and that the intended behavior is to open dialog boxes consecutively.

Thanks Nathan for sharing your use cases. Your comments are all good, but essentially they are in support of bug 1565007, which is about fixing the regression which you observed and restoring consecutive "Save as..." dialogs for each selected attachment. Your use cases aptly illustrate why we should not remove that feature.

This bug is about adding a new feature where users who do not need control over folder and file name for each attachment can just pick a folder and save selected attachments with sender's pre-defined file names.