User Agent: Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:14.0) Gecko/20100101 Firefox/14.0.1 Build ID: 20120713224758 Steps to reproduce: I received a message with multiple image attachments and want to save them all at once to a directory. But there is no attachments pane or menu option "save all". I can only right-click on each image one by one and save it -- tedious when there is 20 of them! Expected results: Have a menu option to "save all" This is Thunderbird 14.0 on Xubuntu 12.04 (Precise)
I should add that the message was sent with Apple Mail, and that image attachments have Content-disposition: inline, and Content-type: image/jpeg. It is not showing as having attachments in the message list. The message is on the large size: saving it produces a 6MB .eml file. I have another (smaller) message in the same account that also contains inline JPGs (but not sent from Apple Mail), and that one works just fine.
Summary: Option to save all attachments is missing → For message with inline images, option to save all attachments is missing
Davor, thanks for your feedback. Let's have a look: Generally speaking, we have 2 things here: 1) things inline, and 2) things attachment. 1) things inline, per definition, are meant to show inline. Hence they usually come with <img href="cid:partX..."> for display inside HTML part. (Without such <img> reference in the HTML code, attachments with content-disposition: inline will not show in TB's default UI). TB makes the imo reasonable assumption that things inline are primarily for inline display & printing, not for saving as files (which is more appropriate for things attachment). Hence TB currently has no option to save all inline images, nor a media browser like FF. Which might be a valid RFE, but imo this would be better realized in an addon (recommend wontfix). I suppose you could save your msg as HTML and then use FF to extract media more systematically. And there's another workaround (see below). 2) things attachment, per definition, are meant to show as file attachment. As a courtesy, TB has "Display attachments inline" which adds a preview of attached images at the end of the message body. For file attachments, there's "Save All" command to do just that. So basically, the *sender* has a choice: If sender wants you to receive file attachments for saving, he should send them accordingly (as things attachment). If sender wants you to just see beautiful things inline in your msg, he is free to send them so (as things inline), which unfortunately makes it more difficult for you to save them. So your best bet is to talk to sender and ask him to send in appropriate format (normal file attachments, multipart/mixed with content-disposition: attachment). Otherwise, here's the workaround to save "things inline" with TB all in one sweep: 1) View message with inline attachments 2) Enable View > Message body as > All body parts 3) "Save All" from attachment bar. -> all body parts (inline images, HTML parts etc.) will be saved 4) In your OS file manager, add file extensions as required (e.g. .jpg). If you don't know the correct file extension for images, you can use tools like IrfanView to find out - just open with IV and it will offer to add correct file extension. Does that solve your problem? Short summary: - not a bug, TB has correct behaviour - RFE worth exploring, but imo looks like addon-candidate (especially given the limited resources of TB, and a lot of more pressing issues with inline images). - workaround exists -> tendency for wontfix
Severity: normal → enhancement
Summary: For message with inline images, option to save all attachments is missing → For message with inline images, option to save all inline attachments is missing
(For a tl;dr, read the last paragraph.) Content-Disposition doesn't matter here (in fact, Thunderbird largely ignores it). The issue, I expect, is that the images in question are subparts of a multipart/related container. In fact, for multipart/related media, you're not *allowed* to consult Content-Disposition. RFC 2387 says: "Hence, User Agents that understand Multipart/Related shall ignore the disposition type within a Multipart/Related body part." The RFC would seem to imply that multipart/related should only be used when "proper display cannot be achieved by individually displaying the constituent body parts", which is consistent with how we do things. However, we're probably in violation of section 6.2: "The Multipart/Related media type will be used for objects that have internal linkages between the body parts. When the objects are stored the linkages may require processing by the application or its receiving agent." All this would suggest that we're displaying things correctly for multipart/related media, but that when we save the message (as HTML), we should do some special processing and handle the save like Firefox does when you choose "Web Page, complete" from the dropdown. Therefore, this probably isn't WONTFIX. It would help to see a sample message though, to make sure that all the stuff I said actually applies in this case. :)
(In reply to Jim Porter (:squib) from comment #3) > (For a tl;dr, read the last paragraph.) > > Content-Disposition doesn't matter here (in fact, Thunderbird largely > ignores it). The issue, I expect, is that the images in question are > subparts of a multipart/related container. In fact, for multipart/related > media, you're not *allowed* to consult Content-Disposition. RFC 2387 says: [snip] Jim, thanks for providing more technical details. > All this would suggest that we're displaying things correctly for > multipart/related media, but that when we save the message (as HTML), we > should do some special processing and handle the save like Firefox does when > you choose "Web Page, complete" from the dropdown. Therefore, this probably > isn't WONTFIX. It would help to see a sample message though, to make sure > that all the stuff I said actually applies in this case. :) I think "saving complete message including inline images" is Bug 164154, and it would be great to get that started. To that end, can you give feedback to Bug 164154 Comment 7? Imo this bug has a different intention, but Bug 164154 might be an acceptable workaround, depending on implementation chosen there. Reporter here is seeing a message that shows a number of inline images (probably unsuitable choice of multipart structure by apple mail and/or sender), which correctly don't show up in attachment pane. I understand he wants a TB-internal UI to extract all of these easily, something like this: - right-click on inline image - then "Save All Inline Images..." - choose target folder (local FS) - done. Similar to what we have for non-inlined attachments, your Save-All button. I think that might be a nice idea, but it's a bit too much to ask for core. And the UI would need careful consideration to avoid confusion with inline image previews of real file attachments. Hence my recommendation of "wontfix" for this, addon proof of concepts welcome.
Jim's comment 3 misunderstood this bug for what is already covered in bug 164154. So my reasons of comment 2 not to fix this in core unless someone provides an addon proof of concept are still unopposed (even reporter did not reply to question of comment 2). We need to draw a line somewhere. -> wontfix
Status: UNCONFIRMED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → WONTFIX
Whiteboard: [has workaround, comment 2][wontfix-addon-welcome]
You need to log in before you can comment on or make changes to this bug.