User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0 It will be nice to have possibility to configure, how Thunderbird presents list of attachments while presenting message. Something similar to 'list' vs 'icons' in MSWindows browser. Or at least, to have possibility to list attachments vertically, not horizontally. This will be useful if mail containing attachments with long file names. Reproducible: Always

Duplicate Bug 446452 attachment 330616 [details] has a mockup screenshot of how "list mode" could look like. In that bug, there are more detailed steps and further arguments why a list mode for attachment is needed, e. g.: - see long attachment file names in full (instead of hovering over each attachment just to see the name) - see file size of attachments (not possible at present) - see more attachments at once, using less screen real estate - sort attachments according to name, size, file type, date/time when added etc. (not possible at present) Furthermore, such a "list mode" or "View details" mode would also be helpful at compose time (better overview, check size, check file date etc.).

Bug 436555 (attachment presentation in received messages needs improvement) and screenshot attachment 363274 [details] therein suggest a new checkbox- and button-based layout for the attachment pane that will basically do away with the current listbox style (file icons + name). If implemented, the improvements suggested in this bug are unlikely to happen, as they build on the current listbox/explorer-like style.

Another problem with having to use tooltips to read long file names of attachments is that the tooltips time out and disappear before I have finished reading them. Bug 395668 exists for the tooltip timeouts in Firefox and has led to the development of the No Tooltip Timeout extension for Firefox (https://addons.mozilla.org/en-US/firefox/addon/11233), but AFAIK no equivalent bug nor extension exists for Thunderbird. :(

OS/Platform -> All I believe this bug is a valid request for enhancement which should be confirmed, based on the list of added value and functionality in comment #2. I know there is a competing UI plan out there (XREF bug 436555 incl. UI proposal of attachment 363274 [details]), but it can't bring the functionality that this bug suggests. Compare the list of advantages and added functionality in comment #2 with the current concept of the xref bug: it will be very hard if not impossible for bug 436555 to deliver any of these advantages using the proposed UI of attachment 363274 [details]. BTW (OT), description of possible values for "STATUS" lacks a description of what exactly "NEW" means for "enhancement" bugs (see https://bugzilla.mozilla.org/page.cgi?id=fields.html#status). My understanding of "NEW" is that it's a valid idea (which is not INVALID, WONTFIX or otherwise RESOLVED sth), but there aren't any guaranties whatsoever that this idea will actually get implemented. A better indicator for actual desires for implementation are the "wanted..." flags. So essentially, "NEW" for enhancements says "it's a valid wish / a serious idea that's worth considering if done right and approved lateron" (please correct me if I am wrong!). I conclude that it's OK to have competing ideas for enhancements and both of them can be "NEW" (and I've seen that many times in BMO). Any objections against marking this "NEW"?

Related/similar bugs - Bug 384331 - New Feature: Add "folders with all attachments (by type/date/size/from:)" to folder pane views - Bug 404186 - Preview of attachment filename and size - Bug 430288 - For composing, show additional tooltip information on mouseover of attachment filename (modify timestamp, file size) This enhancement will be of increasing importance as we are sharing more and more files via email and news (cf. bug 384331, comment #0): > Email clients are becoming more and more the main "window" to our daily work. > At the same time, emails are no more just messages but are containers for > "shared information" i.e. document, pictures, addresses, TODOs...

Is there anything in this bug that isn't covered elsewhere? It seems the only things are showing the file type (not that useful in my opinion), and sorting the attachment list (also not that useful, and potentially confusing if someone refers to "the first attachment" in the email body). Everything else is either finished (attachment size, tooltip timeouts), or has another bug filed on it (names being truncated, bug 654222).

FTR: Every day of using TB, I rejoice in the improvements that Jim has brought to the attachment pane, esp. bug 282068 and bug 630759, thank you for that!!! However... (In reply to Jim Porter (:squib) from comment #10) > Is there anything in this bug that isn't covered elsewhere? Yes, this bug is still valid. The main idea of this bug is an alternative view of attachments in a *vertical* list, with details in columns, and sortable. > sorting the attachment list (also not that useful, and potentially confusing > if someone refers to "the first attachment" in the email body). The most obvious use cases for sorting attachments (esp. received ones) are: 1) *Sort by name*: e.g. lots of attachments, and sender didn't sort them for whatever reason, but they would be a lot more meaningful to recipient if sorted by name (systematic overview, picking which of them to open/save/delete/detach) e.g. sender sends in wrong order (current view): test3.doc, test1.doc, test2.doc (suppose they were 10+, unordered) but I want (alternative details view, this bug, see ascii art below): test1.doc, test2.doc, test3.doc (and then decide what to do with them) 2) *Sort by size*: e.g. lots of attachments with various sizes, non-sorted: Current view: test1.doc 127 KB test2.mp3 2 GB test3.txt 5 bytes Problems: - for short file names, sizes are visually closer to files they don't belong to - sizes cannot easily be added, as we use bytes/KB/MB/GB depending on size of each file (which is ok for individual files in this view, but doesn't offer a systematic overview as suggested in this bug, see below) - due to horizontal multi-column format (space-efficient), esp. with many files, not easy to find the one I am looking for; depending on solution for bug 654222, this might be even more significant as no. of columns may vary for each row Expected alternative view (details view, this bug): (see mockup screenshot of attachment 330616 [details]) Name |Size ^ | --------------------+----------------+ test2.mp3 | 2.000.000 KB | test1.doc | 127 KB | test3.txt | 1 KB | The other advantage of this proposed view is that full file names can be displayed easily, even for long file names, hassle-free. To me, a list of attachments is a list of files, so basically, I expect the UX of attachment pane to be as similar as possible to the look and feel of the file manager of my OS (in my case, windows explorer).

(In reply to Thomas D. from comment #11) Your post is written well, but are you serious about a 2 /gigabyte/ attachment?! I think the largest attachment I have seen was < 20 /megabytes/. Maybe you simply wanted to see who was paying attention? ;)

(In reply to Brolin Empey from comment #12) > (In reply to Thomas D. from comment #11) > Your post is written well, but are you serious about a 2 /gigabyte/ > attachment?! I think the largest attachment I have seen was < 20 > /megabytes/. Maybe you simply wanted to see who was paying attention? ;) Sure, you passed the test ;) I confess I haven't tried the 2 GB, and I have no such intentions... :| I suppose it'll be possible in the not-too-distant future, but for now, the more realistic example should be: test1.doc 127 KB test2.mp3 2 MB test3.txt 5 bytes Name |Size ^ | --------------------+----------------+ test2.mp3 | 2.000 KB | test1.doc | 127 KB | test3.txt | 1 KB |

(In reply to Thomas D. from comment #11) > (In reply to Jim Porter (:squib) from comment #10) > > Is there anything in this bug that isn't covered elsewhere? > > Yes, this bug is still valid. The main idea of this bug is an alternative > view of attachments in a *vertical* list, with details in columns, and > sortable. [snip] If these are the only reasons, I'd probably nominate this to be WONTFIX, since the added maintenance effort for a non-default UI would overshadow the potential benefit. This really looks like the sort of thing that belongs in an add-on, especially since based on this bug there isn't much demand for it.

To support nested message/rfc822 part and its attachment parts, hiearchical display of mail and subparts is neded, if save, detach/delete etc. of attachemnts in attached email in attached email ... in attached email, is required at single attachment pain or panel of main mail. Windows Explorer Corresponding object in mail directory <===> main mail, message/rfc822 part subdirectory, if message/xxx <===> subpart in multipart/xxx file, if non message/xxx

(In reply to WADA from comment #15) > To support nested message/rfc822 part and its attachment parts, hiearchical > display of mail and subparts is neded Not really. We currently just show all nested attachments in the main attachment list without any "tree" view. It just doesn't work quite right for the case in bug 715845.

Here's the add-on, which is currently in beta and awaiting preliminary review: https://addons.mozilla.org/en-US/thunderbird/addon/attachment-tree/

(In reply to Jim Porter (:squib) from comment #17) > Here's the add-on, which is currently in beta and awaiting preliminary > review: https://addons.mozilla.org/en-US/thunderbird/addon/attachment-tree/ Whoops, meant to post this in bug 384331. Oh well...