705249 - Thunderbird does not show attachments in messages

Status: RESOLVED DUPLICATE of bug 674473

(MailNews Core :: MIME, defect)

Description

[Volodia]

Attachment: ZAKAZ: N EXT_1841952 ot 22_11_2011.eml

User Agent: Mozilla/5.0 (X11; Linux i686; rv:9.0a2) Gecko/20111104 Firefox/9.0a2 Iceweasel/9.0a2
Build ID: 20111104042026

Steps to reproduce:

Updated from version 3.1.10 to version 8.0


Actual results:

Thunderbird stop displaying attachments in some new and existing letters. In old letters there is a "clip sign", which tells that there is an attachment. But when I select that letters - atachment sign just disappearing and there is no pannel with attachments. After downgrade back to 3.1.10 - attachments showing perfect.

Comment 1

[:aceman]

There is some .dbf attachment but is marked by the sending program as text/plain (so readable text).

Can you see if your problem is already reported as bug 695042 or bug 674473 or bug 701261?

Comment 2

[Volodia]

(In reply to :aceman from comment #1)
> There is some .dbf attachment but is marked by the sending program as
> text/plain (so readable text).
> 
> Can you see if your problem is already reported as bug 695042 or bug 674473
> or bug 701261?

No, this is not that problems.
The main part of message views fine. Switching between viewing mode does not change anything.
Letters with attached dbf files, in which "Content-Type: application/octet-stream;" displays fine. But I don`t think that there is real need to hide attachments with wrong "Content-Type"... If there`s attachment then user must have ability to save it...

Comment 3

[:aceman]

(In reply to Volodia from comment #2)
> But I don`t think that there is
> real need to hide attachments with wrong "Content-Type"... If there`s
> attachment then user must have ability to save it...

I'd agree with this.

Comment 4

[rsx11m]

> Content-Type: multipart/related; charset=windows-1251;boundary="-----7D81B75CCC90D2974F7A1CBD"
> Content-Transfer-Encoding: multipart/related; charset=windows-1251;boundary="-----7D81B75CCC90D2974F7A1CBD"binary

> -------7D81B75CCC90D2974F7A1CBD
> Content-Type: text/plain; charset=windows-1251

> -------7D81B75CCC90D2974F7A1CBD
> Content-Type: text/plain
> Content-Disposition: attachment; filename="B27460_EXT_1841952.dbf"
> Content-Transfer-Encoding: base64

Notwithstanding the nonsensical Content-Transfer-Encoding header, this is exactly the structure bug 674473 is about (attachment wrongfully placed into a "related" context and thus hidden now). Why do you think this is not a duplicate?

Comment 5

[Volodia]

(In reply to rsx11m from comment #4)
> > Content-Type: multipart/related; charset=windows-1251;boundary="-----7D81B75CCC90D2974F7A1CBD"
> > Content-Transfer-Encoding: multipart/related; charset=windows-1251;boundary="-----7D81B75CCC90D2974F7A1CBD"binary
> 
> > -------7D81B75CCC90D2974F7A1CBD
> > Content-Type: text/plain; charset=windows-1251
> 
> > -------7D81B75CCC90D2974F7A1CBD
> > Content-Type: text/plain
> > Content-Disposition: attachment; filename="B27460_EXT_1841952.dbf"
> > Content-Transfer-Encoding: base64
> 
> Notwithstanding the nonsensical Content-Transfer-Encoding header, this is
> exactly the structure bug 674473 is about (attachment wrongfully placed into
> a "related" context and thus hidden now). Why do you think this is not a
> duplicate?

Well, I re-read that bug and you are right. My bug-report is duplication.