26517 - [SM] Attachment list should show size

Status: RESOLVED FIXED

(SeaMonkey :: MailNews: Message Display, enhancement)

Description

[Henrik Gemal]

When you recieve a mail with attachment(s) the dropdown attachment list that 
appear when you press the paperclip should also show the size of the attachment.

So that entries could be:
text.txt (34 bytes)
killer.jpg (36,6 KB)

Comment 1

[Phil Peterson]

Personally, I'd prefer to keep this UI simple, and not include these details.
But since it seems valuable to you, I'll move to the helpwanted list rather than
resolve the bug.

Comment 2

[Henrik Gemal]

I think it's VERY important for us people who sit a home behind a 56K modem. 
There a big difference between downloading a 36K attachment and a 5Mb 
attachment.

Comment 3

[Henrik Gemal]

It should only show the size when the attachment is not a mail.

btw: why it this assigned to [e-mail]

Comment 4

[lchiang]

Henrik - this is a new "feature" and no one to work on it; hence the 
[e-mail] and helpwanted keyword.

Comment 5

[Henrik Gemal]

is the size of the mail available to the UI? Then it could be easy to fix this 
baby.

Perhaps some UI expert could do some magic?

Comment 6

[Blake Ross]

I'm all out of magic at the moment.

cc'ing Matthew for thoughts on whether to do this

Comment 7

[timeless]

i'd like to do it, but i'll have to research the interfaces. sspitzer do you 
know if we have what it takes?

Comment 8

[Matthew T (active 1999-2002)]

Attachments to a message should be shown in-line in the message pane, like in 
4.x. That way:
*   you can show the name and size *and* type *and* description of each
    attachment, without having to clutter a menu to doing so;
*   you can open attachment by clicking on them, open them in a new browser
    window by Command+clicking on them, save them by Option+clicking on them ...
*   you can drag the attachment to a browser window of your choice to open it, or
    to a folder in your file manager to save it, or to any other app which eats
    URLs to do whatever;
*   you can copy (for example) a reusable URL for an attachment included in a
    message which was posted to a public NNTP server.

All of these are impractical using a menu, which makes the current UI a bad 
regression from 4.x.

As an improvement over 4.x, show the attachments as rows in the same table, like 
a Finder/Explorer list view, with `Name', `Size', `Type', and `Description' 
columns.

Comment 9

[Bob Lockie]

Is it the same as http://bugzilla.mozilla.org/show_bug.cgi?id=90352

Comment 10

[Henrik Gemal]

*** Bug 90352 has been marked as a duplicate of this bug. ***

Comment 11

[[e-mail] (gone - use [e-mail] instead)]

*** Bug 173269 has been marked as a duplicate of this bug. ***

Comment 12

[Desmond Armstrong]

The requirement to show the attachment size is very important. We are used to it
with Internet Explorer and becomes therefore vital.
For those of us without broadband (the majority) this is a very important
feature in the conversion stakes.

Comment 13

[Mike Cowperthwaite]

Attachments no longer shown in a dropdown, but in their own little box.

Would a tooltip on the attachment that included the size be sufficient?

Comment 14

[Bob Lockie]

A tooltip would be nice but not ideal at all.
The size of each attachment should be listed beside the file (maybe like this:
"file (size)".

Comment 15

[Matthieu MOY]

A tooltip would be nice.

A right-click -> contextual menu -> properties

With all the information about the file would be perfect !



There is at least a case whent this would be really usefull : Under WinXP, you
can right-click -> send as email a document, and if it is an image, you can
modify its size and compress it for example. Then, the attached file is a
temporary file, and you would really want to know its size, which is far from
being obvious currently.

Comment 16

[Mike Cowperthwaite]

Attachment size in the *compose* window is bug 195702.  This bug is about 
displaying attachment size for messages in the folders.

Comment 17

[Asa Dotzler [:asa]]

*** Bug 230447 has been marked as a duplicate of this bug. ***

Comment 18

[Desmond Armstrong]

We should have a program like 'Mailwasher' for windows. This program is
extremely valuable as it shows what is sitting on server before downloading.
Then it gives options to delete bounce etc without downloading and before we
download.

Perhaps we can have a taker for such program.

Yes, I would like to see the size of the attachment.

Comment 19

[Henrik Skupin [:whimboo][⌚️UTC+2]]

*** Bug 339606 has been marked as a duplicate of this bug. ***

Comment 20

[Jon B]

(In reply to comment #1)
> Personally, I'd prefer to keep this UI simple, and not include these details.

Umm..  it should be accessible *somehow*.  It's not in the drop-down, it's not in the icon view, it's not in a tooltip, it's not in a right-click menu...  The only way to tell the size of an attachment is to download it.

Comment 21

[Sergio]

> Personally, I'd prefer to keep this UI simple, and not include these details.

The request of this bug (or requested Feature list) is very clear and logical:

When you see that you've just received an attached "PowerPoint" for instance, you want to know how many bytes you will have to download before starting the "show".

Sometimes, depending on the size of it, you prefer to give up downloading.

So it is vital. Is it possible to retrieve this information from the mail server without downloading the file ? 

My suggestion is the classic way (beside the attachment icon):
[icon] Show.pps (3.75 MB)

Comment 22

[FX]

Simple feature request, something very useful and supported in most other email clients. Yet no sign of progress for 7 years. Sad.

Comment 23

[Geert Poels]

I agree. There are dozens of these.

Comment 24

[Jon B]

Here's an extension that shows attachment sizes:

https://addons.update.mozilla.org/en-US/firefox/addon/878

Comment 25

[Vincent (caméléon)]

I think this bug should be affected to Thunderbird instead of Seamonkey for better chance to see it solve.

Comment 26

[dfghjkjhg]

Would really be a great enhancement to finally show the attachment size in the "attachment pane" of "received mails"
(as well as in the "compose window" when writing new mails).

Comment 27

[Thomas D. (:thomas8)]

Related bugs in the "Thunderbird" product:

Bug 559559  - Show the file size of attachments in attachment panel of *any* messages (received/sent/deleted etc.)
Bug 195702  - attachment size should be visible in compose window

Comment 28

[Jim Porter (:squib)]

This should be pretty trivial for anyone to fix now, since it's just a matter of porting the Thunderbird changes in the bugs in comment 27 to Seamonkey. I'd do it, but I don't have Seamonkey builds set up, so I wouldn't be able to test it.

Comment 29

[Jens Hatlak (:InvisibleSmiley)]

Attachment: patch [Checkin: comment 36]

Since bug 559559 landed, the following appears in the Error Console:

Error: [Exception... "'JavaScript component does not have a method named: "addAttachmentField"' when calling method: [nsIMsgHeaderSink::addAttachmentField]"  nsresult: "0x80570030 (NS_ERROR_XPC_JSOBJECT_HAS_NO_FUNCTION_NAMED)"  location: "<unknown>"  data: no]

So we either need to fix this bug (by porting the msgHdrViewOverlay.js changes from changeset 41df9e16a197, except the cloneAttachment change, which we don't have) or at least add a dummy function called "addAttachmentField".

Comment 30

[Philip Chee]

> Bug 559559  - Show the file size of attachments in attachment panel of *any*
> messages (received/sent/deleted etc.)
See also [Bug 516787] Message size in the main window should format large numbers (message size).

Comment 31

[Karsten Düsterloh]

Comment on attachment 501661 [details] [diff] [review]
patch [Checkin: comment 36]

>+++ b/suite/mailnews/msgHdrViewOverlay.js
>+    addAttachmentField: function(field, value)

New functions at least should follow the 'a' prefix Pattern for arguments (aField, aValue).

r=me with that.

Comment 32

[[e-mail]]

Comment on attachment 501661 [details] [diff] [review]
patch [Checkin: comment 36]

Mnyromyr, I was thinking that there were two other options to implement this:
1. Create a new XBL binding that allows us to right-align the size
2. Change the listbox into a tree so that we have two columns
   (thus you could hide the size column if you didn't want it)
I could probably whip up a patch for 1. if you want to try it out, but don't ask me for a patch for 2. unless you're really sure you want it.

>+                                                          displayName, 
Nit: trailing space

>+ * @param displayName The name to be displayed for this attachment (usually the 
Nit: trailing space

Comment 33

[Philip Chee]

A multicolumn tree sounds attractive. How much work would it take?

Comment 34

[Jim Porter (:squib)]

(In reply to comment #32)
> Comment on attachment 501661 [details] [diff] [review]
> patch
> 
> Mnyromyr, I was thinking that there were two other options to implement this:
> 1. Create a new XBL binding that allows us to right-align the size
> 2. Change the listbox into a tree so that we have two columns
>    (thus you could hide the size column if you didn't want it)
> I could probably whip up a patch for 1. if you want to try it out, but don't
> ask me for a patch for 2. unless you're really sure you want it.

It's probably worth keeping this in sync with Thunderbird, since I'm going to be updating this code further. I originally planned to do something like (2), but getting the column size right was a pain.

I'm planning on revisiting this when I update the XBL binding for the attachment pane in bug 282068, so if you'd rather wait for that, that's ok by me (preferable really, since I think it's easier to stay in sync here).

Comment 35

[Jens Hatlak (:InvisibleSmiley)]

I'm not sure waiting for bug 282068 would help us here since TB's interface is somewhat different to ours (esp. judging from the screen shots over there).

I think we should go for KISS here, which would rule out option 2 from comment 32 (esp. with comment 33 in mind). If Karsten wants Neil to try and implement comment 32 option 1, fine (I'll unassign myself then), otherwise I think we should land what we have.

Comment 36

[Jens Hatlak (:InvisibleSmiley)]

Comment on attachment 501661 [details] [diff] [review]
patch [Checkin: comment 36]

http://hg.mozilla.org/comm-central/rev/f47191dbd14b
(comment 32 addressed)

Comment 37

[Jens Hatlak (:InvisibleSmiley)]

Please take any improvement/replacement considerations to new bugs, thanks.

Comment 38

[Pulsebot]

Pushed by ffxbld-merge:
https://hg.mozilla.org/releases/mozilla-beta/rev/66d719467182
[fenix] For https://github.com/mozilla-mobile/fenix/issues/26517 - Create wallpaper v2 feature flag