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)
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.
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.
It should only show the size when the attachment is not a mail. btw: why it this assigned to email@example.com
Henrik - this is a new "feature" and no one to work on it; hence the firstname.lastname@example.org and helpwanted keyword.
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?
I'm all out of magic at the moment. cc'ing Matthew for thoughts on whether to do this
i'd like to do it, but i'll have to research the interfaces. sspitzer do you know if we have what it takes?
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.
Is it the same as http://bugzilla.mozilla.org/show_bug.cgi?id=90352
*** Bug 90352 has been marked as a duplicate of this bug. ***
*** Bug 173269 has been marked as a duplicate of this bug. ***
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.
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?
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)".
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.
Attachment size in the *compose* window is bug 195702. This bug is about displaying attachment size for messages in the folders.
*** Bug 230447 has been marked as a duplicate of this bug. ***
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.
*** Bug 339606 has been marked as a duplicate of this bug. ***
(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.
> 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)
Simple feature request, something very useful and supported in most other email clients. Yet no sign of progress for 7 years. Sad.
I agree. There are dozens of these.
Here's an extension that shows attachment sizes: https://addons.update.mozilla.org/en-US/firefox/addon/878
I think this bug should be affected to Thunderbird instead of Seamonkey for better chance to see it solve.
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).
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
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.
> 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 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 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
A multicolumn tree sounds attractive. How much work would it take?
(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).
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 on attachment 501661 [details] [diff] [review] patch [Checkin: comment 36] http://hg.mozilla.org/comm-central/rev/f47191dbd14b (comment 32 addressed)
Please take any improvement/replacement considerations to new bugs, thanks.