558128 - Multipart/related: File "attached" as "orphan" part which is not referenced from body is shown as "real" file attachment in message reader, but lost when message is forwarded inline or "edit as new"

Status: NEW

(Thunderbird :: Message Compose Window, defect)

Description

[Antal Delahaije]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; nl; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; nl; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4

After some testing i came to the conclusion it only happens to certain e-mails and i can't figure out why. The attachment normally gets included automatically when I forward an e-mail, i've got an example message which can't be forwarded including attachments.

Reproducible: Always

Steps to Reproduce:
1.Put my .eml message in a Thunderbird folder
2.Press forward
3.Tada, it doesn't attach. :-(
Actual Results:  
no attachment in e-mail

Expected Results:  
attachment in e-mail

Comment 1

[Antal Delahaije]

You can download my bugged e-mail from our website.

http://admx.nl/mail.zip

Comment 2

[Nathan Tuggy (:tuggyne)]

Bug 234449 or bug 2903 may be related, and I'd like to have that cross-checked if possible. Wada, you want to check on that?

Note that I see this behavior with Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 ID:20100317103207 -- however, I'm not sure what the cause is, whether it qualifies as a bug per se, or whether it might be a dup, so leaving UNCO for now. (And sticking in Message Compose, too.)

Comment 3

[Nathan Tuggy (:tuggyne)]

Attachment: Testcase.eml as provided by reporter in comment 1

Comment 4

[WADA:World Anti-bad-Duping Agency]

Where is ATTACHMENT part which should be attached when "fowarded in inline"?

Mail structure is as follows. Tb's behaviour for such mail.
> View/Message Body As=Original HTML/Simple HTML : text/html part is used.
>   Next part is displayed at attachment box because it's not displayed.
>     (D. data-3 in multipart/related mail. No one points it)
> View/Message Body As=Plain Text : text/plain part is used.
>   Next three parts are displayed at attachment box because they are not displayed.
>     (B. embedded data-1 in multipart/related mail. Pointed by cid:... in HTML)
>     (C. embedded data-2 in multipart/related mail. Pointed by cid:... in HTML)
>     (D. data-3 in multipart/related mail. No one points it)

I believe that "not-used part in multipart/related" can not be an *attachment* in e-mail even if "attachment" is specified in Content-Disposition: header, as "used part in multipart/related" is displayed in inline(embedded) even though "attachment" is specified in Content-Disposition: header.
If you need to forward data in such part to other people, you need to do "forward as attachment".

(Mail structure)
> Content-Type: multipart/related; boundary="_c9ed0bbe-7c07-46e9-85fe-5278a8598acc_"
>
>    (A. main mail body part of multipart/related)    
>     --_c9ed0bbe-7c07-46e9-85fe-5278a8598acc_
>     Content-Type: multipart/alternative; boundary="_f080a6b3-d381-4a04-b879-e5bb9f75943a_"
>
>        (A-1. text/plain part in multipart/alternative)
>         --_f080a6b3-d381-4a04-b879-e5bb9f75943a_
>         Content-Type: text/plain; charset="iso-8859-1"
>         Content-Transfer-Encoding: quoted-printable
>
>         (snip)
>
>        (A-2. text/html part in multipart/alternative)
>         --_f080a6b3-d381-4a04-b879-e5bb9f75943a_
>         Content-Type: text/html; charset="iso-8859-1"
>         Content-Transfer-Encoding: quoted-printable
>
>         (snip)
>         <DIV align=3Dcenter><IMG id=3DecxecxINCREDISETASATTACH border=3D0 hspace=3D=
>         0 alt=3D"" align=3Dbaseline src=3D"cid:F59E344B-F97D-4B27-B325-D258B6F0B889=
>         "></DIV></TD></TR></TBODY></TABLE></TD></TR>
>         (snip)
>         "http://www.incredimail.com/?id=3D603557&amp=3Brui=3D92333199"><SPAN><IMG b=
>         order=3D0 alt=3D"GRATIS animaties voor je e-mail - van IncrediMail! Klik hi=
>         er!" src=3D"cid:4E3B0D82-4499-4859-B98F-7B3AFCF0499D"></SPAN></A></SPAN> <B=
>         R>
>         (snip)
>
>        (End of multipart/alternative)
>         --_f080a6b3-d381-4a04-b879-e5bb9f75943a_--
>
>    (B. embedded data-1 in multipart/related mail. Pointed by cid:... in HTML)
>     --_c9ed0bbe-7c07-46e9-85fe-5278a8598acc_
>     Content-Type: image/gif
>     Content-Transfer-Encoding: base64
>     Content-ID: <F59E344B-F97D-4B27-B325-D258B6F0B889>
>     Content-Disposition: attachment; filename="051.gif"
>
>     (snip)
>
>    (C. embedded data-2 in multipart/related mail. Pointed by cid:... in HTML)
>     --_c9ed0bbe-7c07-46e9-85fe-5278a8598acc_
>     Content-Type: image/gif
>     Content-Transfer-Encoding: base64
>     Content-ID: <4E3B0D82-4499-4859-B98F-7B3AFCF0499D>
>     Content-Disposition: attachment; filename="stampa_girl_line_du.gif"
>
>     (snip)
>
>    (D. data-3 in multipart/related mail. No one points it)
>     --_c9ed0bbe-7c07-46e9-85fe-5278a8598acc_
>     Content-Type: application/vnd.ms-powerpoint
>     Content-Transfer-Encoding: base64
>     Content-Disposition: attachment; filename="Even_nadenken.pps"
>
>     (snip)
>
>    (End of multipart/related)
>     --_c9ed0bbe-7c07-46e9-85fe-5278a8598acc_--

Comment 5

[Antal Delahaije]

I think the user expects Thunderbird to automatically attach the file to the forwarded e-mail, when doing a Forward as attachment it'll be a file inside another eml file. To make it more user friendly this should be only 1 button. But that's my opinion.

Comment 6

[WADA:World Anti-bad-Duping Agency]

Currently, user need to choose at menu of Message/Forward As(Inline or Attachment). Drop down menu of Forward button(Inline or Attachment), which SeaMonkey has for long time, is already requested for Thunderbird. Search B.M.O, please.

Comment 7

[Wayne Mery (:wsmwk)]

nathan is wada saying this is a dup?  ([dupme] preferred if so)

Comment 8

[Ludovic Hirlimann [:Usul]]

Antalthis might have been fixed by bug 351224. Could you take a few
minutes and download the latest nightly (
http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-comm-central/
), backup your profile and test and let us know if this is fixed or not ?

Comment 9

[Thomas D. (:thomas8)]

Confirming.

STR:

1) open testcase.eml of attachment 438243 [details] in TB, and notice attached file
2) forward inline

Actual result:

1) In original multipart/related msg, notice 1 file attachment "Even_nadenken.pps" (sweet), which looks and behaves no different from "real" file attachment (but technically, according to WADA's comment 4, it's orphaned/non-referenced part of multipart/*related*)

2) In same msg forwarded inline, attachment "Even_nadenken.pps" is not included (this bug)

Perhaps this fails because normally when we attach files, msg will be multipart/mixed, but here it is multipart/related, with an "orphan" part not referenced in body as the other inline images parts are.

Expected result:

2) all attachments should always be included when forwarding a msg inline (as we usually do)

UX-consistency: Users won't care much if that msg might be technically unfortunate or even malformed, and they don't know anything about multipart/mixed vs. multipart/related and unreferenced parts, but they'll expect that if they see a good-looking attachment in message reader, that attachment should be kept when forwarding inline, as TB usually does (hence ux-consistency).

I don't understand WADA's argument of comment 4 why he believes we couldn't do this, and I definitely think we should. Perhaps WADA (correctly) says that *just checking for content-disposition: attachment* will *not* do the trick because that also applies to attachments referenced from body which are displayed inline only (e.g. inline images, as in testcase.eml of attachment 438243 [details]). But if we are able to display that orphan part as attachment in msg reader, we should also be able to forward it along with the rest of the message!

Comment 10

[Thomas D. (:thomas8)]

FTR: It was enough work to figure this out, so I haven't checked for dupes yet.

Comment 11

[Thomas D. (:thomas8)]

The same also happens for "Edit as new", the original file attachment (orphan part) is lost. Equally wrong UX, datalossy.

(In reply to Thomas D. from comment #10)
> FTR: It was enough work to figure this out, so I haven't checked for dupes
> yet.

Among the dependants of bug 505172 (multipartfailtracker), I haven't seen any dupes.

Comment 12

[Thomas D. (:thomas8)]

Attachment: Testcase.eml (reduced and annotated)

After some considerable tweaking of attachment 438243 [details], here's a reduced and annotated testcase!

Comment 13

[Thomas D. (:thomas8)]

Testcase attachment 450838 [details] of similar Bug 571669 has an orphaned multipart/related *application/pdf* part with content-disposition:*inline* (which might be possible in other apps?), and we also lose that when forwarding inline.

Worse, we also lose displayed "body" of content-type:text; (without /plain) when forwarding inline.

Comment 14

[Sven Giermann]

Confirming this is still present and annoying.

I assume the 'output_p' flag is responsible for that, since reading this was removed by the workaround for bug 674473. Also it explains why no size is being calculated for orphaned attachments (MimeLeaf_parse_buffer returns before calculating the size, [1]).

BUT - who can point me to the right location or methods that are being used on inline forwarding or editing as new?
(although I would suggest to purge orphaned attachements on EditAsNew...)

[1] http://mxr.mozilla.org/comm-central/source/mailnews/mime/src/mimeleaf.cpp#138

Comment 15

[Jorg K (CEST = GMT+2)]

Can be reproduced with TB 49 (2016-05-17) with attachment 630293 [details].