(In reply to Thomas D. (:thomas8) from comment #7)

We might want to use duplicate bug 1471833 to implement at least a minimal version of this until we succeed to get to the full goodness of the FF download experience in TB: Just having a dedicated toolbar button for accessing "Saved Files" directly from main 3-pane would go a long way.

FTR Bug 1471833 (originally more about implementing a Download button on 3-pane main toolbar) was morphed to implement "Open containing folder" icon for each file on Saved Files tab.

#1 in the thomas8 UX-papercuts series.

Aleca, Ryan and I agreed that this would be great to have, also wrt enterprise usage where ux-efficiency matters even more. Can we try this?
I am envisioning an exact duplicate of the FF downloads progress button. For details, see comment 0, which also has a mockup screenshot (attachment 8851924 [details]). Of course we'd now use the current FF download progress icon (including the nifty animation on there).

This is a daily nuisance: The workflow to retrieve a just-saved attachment in the target folder is broken, as there's no direct link to the Saved Files Tab, which is virtually undiscoverable (Ctrl+J can only help if you know it, and it won't help mouse users). It's so boring that we make our users search for a just-saved file with their file managers again, but Thunderbird knows where it is and could easily link up! I imagine that this happens a million times every day for Thunderbird users.

Here's a mockup featuring the FF's current Download Progress / Accessor button in Thunderbird. When you click it, you get a modernized variant of the screenshot seen in comment 0, attachment 8851924 [details].
Imo, the button should be on the Mail Toolbar:

• Always accessible, even when the current message does not have attachments.
• This will also be good for future workflows when we allow saving attachments from multiple messages.
• Similar top priority location as in Firefox - Access to Saved Files is quite important!

Indeed, this is an important feature we should aim at having it before next ESR.
Showing it beside the main app menu is a good and expected location for it.

Always accessible, even when the current message does not have attachments.
This will also be good for future workflows when we allow saving attachments from multiple messages.

Wait, I'm a bit confused. Are you proposing to always have that indicator visible?
I think it should behave as it doesn't now on Firefox, which means:

• It appears only after you saved files.
• It has a blue highlight color when a new file finishes downloading, and it remains highlighted until you click on it.
• It remains visible unless you clear your recently downloaded files list.

What should also be considered: TB forgets the downloaded files when it closes. The list is empty on next start.

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

Are you proposing to always have that indicator visible?

Yes, I think that would be helpful for easy and consistent access to Saved Files tab.

• Firefox think they can afford to hide the button because they have another one right next to it which still allows retrieving Downloads: View History, saved bookmarks, and more [incl. Downloads]. TB does not have that.
• We should provide an easy access to Saved Files tab even when the topmost entries (most recent entries) have been removed. There's a thousand reasons to look into yesterday's Saved Files which are still on the list. Having the button always available imo reduces the cognitive burden of sometimes finding Saved Files via the button, but sometimes not, which requires a totally different click pattern then.
• We should consider making Saved Files (Ctrl+J) a top-level entry in the app menu (especially if you want to hide the button). Perhaps underneath the Save As... submenu item.

(In reply to Richard Marti (:Paenglab) from comment #12)

What should also be considered: TB forgets the downloaded files when it closes. The list is empty on next start.

Is that by design? If yes, why? Shouldn't we just keep the list until the user clears it? Or some other smarter clearing which keeps things for a while?

Firefox think they can afford to hide the button because they have another one right next to it which still allows retrieving Downloads: View History, saved bookmarks, and more [incl. Downloads]. TB does not have that.

I think this is a bit of a wrong assumption.
That toolbarbutton is always visible unless the user clears all downloads. If there's nothing in the list of saved files, the button has no need of being there as accessing an empty tab is not something we should guide the user to.
That button remains visible until the list is cleared.

We should provide an easy access to Saved Files tab even when the topmost entries (most recent entries) have been removed.

This would mean having 2 completely separated and independent lists. One for recently downloaded, and one for all download files, like a persistent history.
If we do that, using 1 toolbarbutton for both lists is not a good idea.

I think we should try to keep things simple and not complicate them unnecessarily, with one "saved files" list the user can fully control. And if the user always wants that button visible, the only thing that they need to do is to not clearing the list.

(oops, I am sorry that I use Japanese locale, and so the [save] button near the lower-right corner shows 保存　instead of Save. )

|I would like to understand the proposal better.

This proposal is to add a button for download administration for all the downloads that have been done lately, and NOT for the single message's download per se. Correct?

I am asking because I have been a bit confused with the two paths for saving the attachment of a message.
See bug https://bugzilla.mozilla.org/show_bug.cgi?id=549719 (12 years ago...)
Also, it was mentioned in a post to bug 907732.
See bug 907732 Comment 9 there.
Two paths remember DIFFERENT directories for saving.

It would be great to merge the two functionalities into one, and for me, I always click on the attachment listing itself (in the lower-left corner) to save it. So the right button could be made to work like the download administrative button as proposed here. But I bet there must be people who use the save button in the lower-right corner of the message pane to save an attachment.

In a work done for this bugzilla, it would be great to see the merging or at least make the lower-corner right button to invoke the new admnistrative functionality because in my case, when I notice there is an attachment (at the lower-right corner.: I don't use full HTML mail modes often and thus inline graphics, etc. show up as attachments indicated in the lower-right corner), and thus my eyesight is near the bottom of the screen when that happens, it would be handy to be able to invoke the full download administrative feature by the existing button in the lower-right corner [the red circle in my attachment, too.]

NOTE: BTW, the default download directory rememberd by the direct interaction with the attachment name in the lower-left corner is PER MESSAGE FOLDER, and this has turned out to be VERY USEFUL. This has been like this for the last several years IIRC.
I hope this feature won't be dropped from the result of discussion.

I uploaded unmarked image. Here are circles that refer to the lower-right and lower-left key locations.

(In reply to Alessandro Castellani [:aleca] from comment #14)

Firefox think they can afford to hide the button because they have another one right next to it which still allows retrieving Downloads: View History, saved bookmarks, and more [incl. Downloads]. TB does not have that.

That toolbarbutton is always visible unless the user clears all downloads.

No. That toolbarbutton is visible until the user clears the most recent downloads, which are the only downloads shown directly from the button. The full list lives in the downloads tab and may have downloads history items even when the button is gone. Are you aware that download history can be cleared one by one?

If there's nothing in the list of saved files, the button has no need of being there as accessing an empty tab is not something we should guide the user to.

Please re-read my comment 13:

We should provide an easy access to Saved Files tab even when the topmost entries (most recent entries) have been removed. There's a thousand reasons to look into yesterday's Saved Files which are still on the list. Having the button always available imo reduces the cognitive burden of sometimes finding Saved Files via the button, but sometimes not, which requires a totally different click pattern then.

I am not talking about access to an empty tab, I am talking about access to the (All) Saved Files tab which can have dozens of entries even when the button does no longer have any entries as the user might have manually deleted the most recent entries or there are no recent entries.

This would mean having 2 completely separated and independent lists. One for recently downloaded, and one for all download files, like a persistent history. If we do that, using 1 toolbarbutton for both lists is not a good idea.

That's exactly how it works in Firefox - please look at their implementation. It's not two different lists. It's two different views on the same list.

• Button view: Most recent files only (just saved; I don't know the exact algorithm used in FF, but it's a subset of the full list based on recency).
  • Link: Button view has "Show all downloads" to go to the tab view and see all files.
• Tab view: All saved files

I think we should try to keep things simple and not complicate them unnecessarily, with one "saved files" list the user can fully control.

I am failing to see the complexity in the current Firefox UX, which has two different views on the same list, which is exactly the right thing to have. We should find out how FF handles "auto-hiding" of the recent downloads list on the button, which actually maintains the full downloads history in the All downloads tab unless deleted by user. Iow, for some time (or until closing FF or whatever), your most recent downloads are shown on the button, then later they are only available from the All downloads tab.

And if the user always wants that button visible, the only thing that they need to do is to not clearing the list.

So what's the easy way in TB to access yesterday's attachments if for some reason today's are gone?
Firefox has another pretty easy way of accessing Downloads tab, on the library button right next to the downloads progress/accessor button. Thunderbird does not have that. Implementing another button to access the TB Saved Files tab would be redundant if we can just keep the downloads progress/accessor button always available, which has a permanent menuitem to link to the Saved Files tab - hence providing a reliable access to both recent and earlier saved files.

Having the button always available imo reduces the cognitive burden of sometimes finding Saved Files via the button, but sometimes not, which requires a totally different click pattern then.

Personally, I would never hide the button - if I want to check if I still have a link to yesterday's attachment in there, I wouldn't mind even getting to an empty tab and knowing for sure. Ymmv - so if you prefer to hide the button, we could hide it when there is no history at all in the Saved Files tab. As long as there's history, the button will provide an easy access to that via the link menu item (even when there are no recent items) - see my mockup in comment 4 where this was discussed.

• Show button as long as there is any item in downloads history (Saved Files Tab, regardless if recent or not)
• Hide button when there's nothing in downloads history (Saved Files Tab).

(In reply to ISHIKAWA, Chiaki from comment #15)

Hi Chiaki, nice to hear from you and thanks for following up on things Thunderbird!

This proposal is to add a button for download administration for all the downloads that have been done lately, and NOT for the single message's download per se. Correct?

Correct, sort of. Same as in Firefox, I envision this button to show a most recently downloaded subset of your Saved Files list (which lives in a Tab [Ctrl+J], but nobody knows about that tab because it's not linked to the main UI).

I am asking because I have been a bit confused with the two paths for saving the attachment of a message.
See bug https://bugzilla.mozilla.org/show_bug.cgi?id=549719 (12 years ago...)
Also, it was mentioned in a post to bug 907732.
See bug 907732 Comment 9 there.
Two paths remember DIFFERENT directories for saving.

Totally agree that this must be looked into, but let's use your bug to fix that problem:
Bug 549719 - Unify/Merge two code paths for saving an attachment in a message (different save directory in "double click/save file" vs "context menu/save as")
Doing that might also be related to bug 539198 and bug 814000 (which needs some deep thoughts wrt UI/UX).

All of these bugs iiuc are pretty orthogonal/unrelated to what we're doing here.
Here we just want add the downloads progress/accessor button as a discoverable convenience shortcut to access most recently saved attachments in their containing folder, and the Saved Files tab with the full list (regardless how they were saved).

It would be great to merge the two functionalities into one, and for me, I always click on the attachment listing itself (in the lower-left corner) to save it. So the right button could be made to work like the download administrative button as proposed here. But I bet there must be people who use the save button in the lower-right corner of the message pane to save an attachment.

How you save your attachment should not matter for the shortcut button proposed here (see above).

In a work done for this bugzilla, it would be great to see the merging or at least make the lower-corner right button to invoke the new admnistrative functionality ... it would be handy to be able to invoke the full download administrative feature by the existing button in the lower-right corner [the red circle in my attachment, too.]

I'm not sure if I understand you correctly, but maybe you're proposing that the downloads progress/accessor button (per this bug) should be located on the attachment header bar? That is certainly worth considering as it might make a nice in-place addition. However (as I explained before), there's a fundamental disadvantage of placing the button on the attachment header bar: It will only be available for messages with attachments. So it'll become very inconvenient if you're looking for fast access to recent saved files whilst on a message without attachments. And it won't work well for future actions (save all attachments of all selected messages). See my comment 10.

NOTE: BTW, the default download directory rememberd by the direct interaction with the attachment name in the lower-left corner is PER MESSAGE FOLDER, and this has turned out to be VERY USEFUL. This has been like this for the last several years IIRC.
I hope this feature won't be dropped from the result of discussion.

No worries! We're not going to have that discussion here, that's bug 549719 and bug 539198 / bug 814000 territory.

This proposal also covers the problem underlying bug 297662 in a generic way.