Closed Bug 547139 Opened 16 years ago Closed 12 years ago

Would like to view *all* attached images inline, not only those with inline-deposition (Content-Type:application/octet-stream;name="xxx.JPG" is not displayed in inline)

Categories

(Thunderbird :: Message Reader UI, enhancement)

x86
Windows XP
enhancement
Not set
normal

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: hanno.falk, Unassigned)

Details

(Keywords: polish, ue)

Attachments

(1 file)

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.1.7) Gecko/20091221 Firefox/3.5.7 GTB6 Build Identifier: Version 2.0.0.23 (20090812) Outlook sends attached (jpg) images with Content-Disposition: attachment but check-marking "view/attachements inline" does not inline those pictures. It inlines only those with Content-Disposition: attachment/inline The check-box should be three state: never/inlined/always Reproducible: Always Steps to Reproduce: 1. receive a mail with a jpg as "Content-Disposition: attachment" 2. check-mark "view attachments inline" 3. visualize this mail Actual Results: The attached jpg is chown as icon in the bottom, but not added to the mail body. Every picture has to be opened manually (and leaves an orphane file in c:\temp) Expected Results: The attached picture is forced to be displayed inline, not regarding the Content-Disposition. Outlook shows all the pictures in those mails inlined by deafault.
Does Thunderbird 3.0.1 also behave the same way?
Severity: normal → enhancement
Keywords: polish, ue
Version: unspecified → 2.0
I just installed Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 No change - the newest version does not show any of those pictures either. I still have to double-click every image, to start my external viewer (IrfanView).
Johannes Falk, can you check structure of mail sent by Outlook? (Content-Type:, boundary parameter in it, boundary lines, Content-Type:/boundary etc. in each part) Can you attach(never paste if long) mail header data? Headers represent mail structure only are sufficient, if plain text mail. content-type:, content-disposition:, boundary lines. huge data lines for image data is not needed. Subject:, From:, To:, mail body data, ... are not needed. If html part is involved, keep <html>, </html>, and <img src...> lines, please.
Sorry, I deleted the pictures from all those mails already after saving them. If this remanent email here is not sufficient, I can tell my friend to send me a short test for you. This is the *complete* source output form a Ctrl-U of one of those emails: === BEG ==================================================================== From - Sun Feb 14 22:53:59 2010 X-Account-Key: account2 X-UIDL: 330e60e3ae079d34ee0daca80b3b441e X-Mozilla-Status: 0001 X-Mozilla-Status2: 10000000 X-Mozilla-Keys: Return-Path: <ing.buero.fischer@gmx.net> X-Flags: 0000 Delivered-To: GMX delivery to hanno.falk@gmx.net Received: (qmail invoked by alias); 14 Feb 2010 14:02:14 -0000 Received: from p5B25F51F.dip.t-dialin.net (EHLO vl420) [91.37.245.31] by mail.gmx.net (mp054) with SMTP; 14 Feb 2010 15:02:14 +0100 X-Authenticated: #22966450 X-Provags-ID: V01U2FsdGVkX19uSIg7/cFuUF29BpqjjmhfAX3PeMkRjroiHYjXco ZyWESU7Jk6bRP+ Message-ID: <000d01caad7d$f071fd80$2202a8c0@vl420> From: "Michael Fischer" <ing.buero.fischer@gmx.net> To: "Johannes Falk" <hanno.falk@gmx.net> Date: Sun, 14 Feb 2010 14:58:52 +0100 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0007_01CAAD86.38F9D340" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896 X-FuHaFi: 0.73999999999999999,0.75 X-GMX-Antivirus: 0 (no virus found) X-GMX-Antispam: 0 (Mail was not recognized as spam); Detail=5D7Q89H36p5xOp9NadjzZ++cYcjHi2VrT/xNuaIY6PfOvdfdeuChebqAA2DGLWAEEsym6 PaYMLENVEwSZwm2L06yROBL9e5F32ARPL6U9jGBtbmD3p4yIRDqH1Mb1kdbH3U6YxNd7Wo6av8EY e67OA==V1; X-GMX-UID: XjBKeMMzPTRsejLrxjIw7bYxc2tpZIvT This is a multi-part message in MIME format. ------=_NextPart_000_0007_01CAAD86.38F9D340 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0008_01CAAD86.38F9D340" ------=_NextPart_001_0008_01CAAD86.38F9D340 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Hanno, nochmal ich, nun verstehe ich die Welt nicht mehr. Das Ersatzteil hat = nur eine Bohrung. Den Kreuzschraubenzieher ben=F6tige ich nicht, weil = f=FCr die Schraube kein Loch da ist. Ich brauche Deine Beratung, gehe um 16:00 mit Matthi Billardspielen = f=FCr zwei Stunden. Liebe Gr=FCsse Michi ------=_NextPart_001_0008_01CAAD86.38F9D340 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META http-equiv=3DContent-Type content=3D"text/html; = charset=3Diso-8859-1"> <META content=3D"MSHTML 6.00.2800.1598" name=3DGENERATOR> <STYLE></STYLE> </HEAD> <BODY bgColor=3D#ffffff> <DIV><FONT face=3DArial>Hi Hanno,</FONT></DIV> <DIV><FONT face=3DArial>nochmal ich, nun verstehe ich die Welt nicht = mehr. Das=20 Ersatzteil hat nur eine Bohrung. Den Kreuzschraubenzieher ben=F6tige ich = nicht,=20 weil f=FCr die Schraube kein Loch da ist.</FONT></DIV> <DIV><FONT face=3DArial></FONT>&nbsp;</DIV> <DIV><FONT face=3DArial>Ich brauche Deine Beratung, gehe um 16:00 mit = Matthi=20 Billardspielen f=FCr zwei Stunden.</FONT></DIV> <DIV><FONT face=3DArial></FONT>&nbsp;</DIV> <DIV><FONT face=3DArial>Liebe Gr=FCsse Michi</FONT></DIV></BODY></HTML> ------=_NextPart_001_0008_01CAAD86.38F9D340-- ------=_NextPart_000_0007_01CAAD86.38F9D340 Content-Type: text/x-moz-deleted; name="Deleted: IMG_6176_1_1.JPG" Content-Transfer-Encoding: 8bit Content-Disposition: inline; filename="Deleted:IMG_6176_1_1.JPG" X-Mozilla-Altered: AttachmentDeleted; date="Mon Feb 15 00:28:46 2010" The original MIME headers for this attachment are: Content-Type: application/octet-stream; name="IMG_6176_1_1.JPG" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="IMG_6176_1_1.JPG" ------=_NextPart_000_0007_01CAAD86.38F9D340-- === END ====================================================================
Attached an example mailbox-file (testbox.elm) containig one email with one picture that is never visualized by the message-reader-gui. Created with Outlook Express 6 today (via "insert attachment").
Where can we see image part? application/octet-stream is for generic binary and is different from image/jpeg etc., although it can be used to attach image file to mail because image file is also a binary file. > Content-Type: application/octet-stream; name="IMG_6182_1_1.JPG" > Content-Disposition: attachment; filename="IMG_6182_1_1.JPG" Can you check next case? (Save in a new folder, Edit folder file, Rebuild-Index) > Content-Type: application/octet-stream; name="IMG_6182_1_1.JPG" > Content-Disposition: inline; filename="IMG_6182_1_1.JPG"
> Where can we see image part? I do not see anything of the image, there is only the file name shown in the attachment area at the bottom of the gui, preceded by some other icon. TB does not use my typical (IrfanView) image-icon for the attachments in those mails. When I double-click this attachment, the ui always asks me, how to open it (what application to use). I don't know why Outlook6 makes the type binary instead of image. I always tell my friend that there should be some other button to attach pictures. But then he send some strange html coded mail, that did not show the image either. > Can you check next case? Manually changing the Content-Disposition to "inline", did not change the behavior at all. But changing the image header to "Content-Type: image/jpeg;", displays this image properly inlined inside of the mail-reader-ui (centered or scaled to fit) - silently ignoring the "Content-Disposition: attachment;".
> TB does not use my typical (IrfanView) image-icon for the attachments in those emails. Sorry, this is not true anymore. Now I see the "IrfanView-Icon" in front of the attachment name - I guess this was before I updated from version 2.x to 3.0.1
(In reply to comment #9) > Now I see the "IrfanView-Icon" in front of the attachment name It's an enhancement by some quirks for application/octet-stream part. Can you compare next cases? > (a) .JPG > (a-1) Content-Type: application/octet-stream; name="img-1.JPG" > Content-Disposition: attachment; filename="img-1.JPG" (this bug) > (a-2) Content-Type: application/octet-stream; name="img-2.JPG" > Content-Disposition: inline; filename="img-2.JPG (you already checked) > (b) .TXT > (b-1) Content-Type: application/octet-stream; name="txt-1.TXT" > Content-Disposition: attachment; filename="txt-1.TXT" > (b-2) Content-Type: application/octet-stream; name="txt-2.TXT" > Content-Disposition: inline; filename="txt-2.TXT" AFAIK, at least (b-2) is displayed in inline by quirks. See Bug 538407. I dont't know about (b-1).
Note: Inline display of application/octet-stream part is possibly limited to non-binary, text attachment only.
Summary: Would like to view *all* attached images inline, not only those with inline-deposition → Would like to view *all* attached images inline, not only those with inline-deposition (Content-Type:application/octet-stream;name="xxx.JPG" is not displayed in inline)
Quirks for inline display of application/octet-stream was done by Bug 532603. I don't know Bug 532603 is only for text or for any file extenstion of inline-displayable content-type like .JPG. > Bug 532603 plain text attachment with application/octet-stream Content-Type does not shown inline
(In reply to comment #11) > Note: Inline display of application/octet-stream part is possibly limited to > non-binary, text attachment only. I hope this can be extended to all inline-displayable file-extensions.
(In reply to comment #12) > Quirks for inline display of application/octet-stream was done by Bug 532603. > I don't know Bug 532603 is only for text or for any file extenstion of > inline-displayable content-type like .JPG. > > Bug 532603 plain text attachment with application/octet-stream Content-Type does not shown inline This looks to me as if TB 3.1 will guess all types of application/octet-stream by file-extension.
(In reply to comment #10) I made the tests to answer your questions and some more, (c) and (d): (c) ordinary .TXT (check for personal interest) [NICE] TB 3.0.1 displays my attached text.txt with Content-Type: text/plain always inlined (behind a separation line) in both disposition-cases (c-2) Content-Disposition: inline and (c-1) Content-Disposition: attachment. (b) guessed .TXT (your questions) [FAILED] TB 3.0.1 currently does not display text.txt with Content-Type: application/octet-stream at all with any of the disposition-cases (b-2) inline nor (b-1) attachment. (a) guessed .JPG (this bug) [FAILED] TB 3.0.1 does not show images w/o Content-Type: image/jpeg at all with any of the disposition-cases (a-2) inline nor (a-1) attachment. (d) ordinary .JPG (checked for comparison) [NICE] TB 3.0.1 displays attached pictures with Content-Type: image/jpeg always inlined and scaled (behind a separation line) in both disposition-cases (d-2) Content-Disposition: inline and (d-1) Content-Disposition: attachment.
I also have this problem and am getting sick of it. It's been years and I still can't view simple .jpg attachments inline when I check 'show attachments inline'?
I have this problem but can tolerate it as the software is worth it. I am not sure that the "Content-Disposition:" mentioned in the first report matches my situation. Basically any .jpg remains as an attachment to an Email newsletter I receive despite 'display attachments inline' being set on. An appropriate sized empty box appears in the text. A .gif will appear in the Email. I am using Tbird 3.0.4 in Ubuntu 10.04. I have examples of the Emails if needed. Thanks.
I can see the image (in the sample e-mail as bug attachment) inline with Thunderbird 24.1.1 (Win 7). So it WORKSFORME.
I am sure, this bug has been fixed at least two years ago, shortly after sending all my test results. I have no problems viewing those attached images since than any more - inlined or not. Thanks everyone! Hanno
Status: UNCONFIRMED → RESOLVED
Closed: 12 years ago
Resolution: --- → INVALID
Resolution: INVALID → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: