Closed Bug 571669 Opened 12 years ago Closed 2 years ago

Multipart/related: body part of Content-type: text; (without /plain) displays "correctly" but lost/disappears when forwarding inline or "edit as new"

Categories

(Thunderbird :: Message Compose Window, defect)

x86
Windows 7
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 408114

People

(Reporter: barbara.obryk+bugzilla, Unassigned)

Details

(Keywords: dataloss, testcase)

Attachments

(1 file)

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

When forwarding inline one specific message the body of the original message gets included as an attachment and the attachment isn't included at all in the forwarded message. The same happens when I try to `edit message as new'.

Reproducible: Always

Steps to Reproduce:
1. Open attached email message
2. Click `Forward' or `Edit message as new'
Actual Results:  
The attachment disappeared and the original body went into an attachment

Expected Results:  
The attachment should remain an attachment and the original body should remain inline
This is an anonymized version of the message which causes the problem. It still does cause the problem.
STR (tested on TB12.0.1/WinXP)

1 Open .eml of attachment 450838 [details] with TB
2 Forward inline or Edit as new

Actual result (slightly different from comment 0, reported against TB3)
1 msg displays "correctly", with plaintext body text and 1 attached .pdf
2 a) body text disappears when forwarding inline (confirming this bug)
  b) attachment disappears (Bug 558128)

Expected
2 a) keep body text when forwarding inline
  b) keep attachment when forwarding inline

Explanation:

Looking at testcase.eml of attachment 450838 [details]:

2 a) "missing body on forward inline" occurs because body part is
Content-Type:text; changing that to Content-Type:text/plain fixes that problem.
However, if we display the "text;" body correctly, we also need to forward it.


> --------------c2997eda0922b9fff775d5489ccac0af
> Content-Type: text; charset=ISO-8859-1
> Content-Transfer-Encoding: 7bit
> 
> This was message body

2 b) this looks like duplicate in support of Bug 558128: parts of multipart/related that are not referenced from main part get lost when forwarding.

Further notes:
- pdf attachment is broken/incomplete (but that shouldn't matter)
- final boundary missing (but adding it doesn't help)
Summary: attachment and body mixed up when forwarding → Multipart/related: body part of Content-type: text; (without /plain) displays "correctly" but lost/disappears when forwarding inline
Keywords: testcase
Summary: Multipart/related: body part of Content-type: text; (without /plain) displays "correctly" but lost/disappears when forwarding inline → Multipart/related: body part of Content-type: text; (without /plain) displays "correctly" but lost/disappears when forwarding inline or "edit as new"
Keywords: dataloss

testcase message is broken?

Flags: needinfo?(jorgk)
Attachment #450838 - Attachment mime type: message/rfc822 → text/plain

Incorrect MIME format: Content-Type: multipart/related. Should be multipart/mixed for an attachment. More later.

OK, looking at meta bug 1405234, this is a duplicate of bug 1404822.

Status: UNCONFIRMED → RESOLVED
Closed: 2 years ago
Flags: needinfo?(jorgk)
Resolution: --- → DUPLICATE
Duplicate of bug: 1404822

Reshuffling the duplicate.

Duplicate of bug: 408114
You need to log in before you can comment on or make changes to this bug.