User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050907 (No IDN) Firefox/1.4 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050907 (No IDN) Firefox/1.4 Detached message is displayed incorrectly in inline mode, if message body is empty Reproducible: Always Steps to Reproduce: 1.Create empty message with text attachment 2 [review].Detach attachment 3 [review].Set inline mode 4.View message Actual Results: Message is displayed incorrectly Expected Results: Message view shoud be empty
Created attachment 195863 [details] sample mbox which contains 2 message message 1: original empty message with text attachment message 2: detached message
I'm using Thunderbird 1.5 Beta 1
Reproduced with TB 1.6a1-0904, 1.5b1-0904, Win2K. It's not dependent on the message body being empty. The problem has to do with this header: Content-Transfer-Encoding: base64 not being removed when the new headers are written out: Content-Type: text/plain; name="test.txt" Content-Transfer-Encoding: base64 <- TAKE THIS OUT Content-Disposition: attachment; filename="test.txt" X-Mozilla-External-Attachment-URL: file:///C:/test.txt X-Mozilla-Altered: AttachmentDetached; date="Tue Sep 13 22:06:38 2005" The C-T-E header *is* copied to the "detachment body" text showing the original headers. I assume this same issue applies for quoted-printable (which will cause display issues with any '=' signs in the original headers).
I think this should block 1.8b5 - I'll look into it.
Created attachment 195935 [details] [diff] [review] proposed fix don't write out transfer-encoding.
this is a 1.8b5 blocker for thunderbird
Comment on attachment 195935 [details] [diff] [review] proposed fix david, is this code that's only fired when we are writing out a message whose attachment has been deleted?
yes, only for when attachments are detached (not even deleted, just detached)