701261 - Emails with attachment appears blank with no option to save attachment, and is shown as attachment by Forward (Actual Voice mail, PDF mail etc. Message body of non-multipart mail is non-displayable one such as audio/wav, application/pdf.)

Status: VERIFIED FIXED

(MailNews Core :: MIME, defect)

Description

[Frank]

Attachment: Copy/pasted source contents of a sample email message which does now show the file attachment

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20100101 Firefox/8.0
Build ID: 20111104165243

Steps to reproduce:

Initially my boss brought this issue to my attention.  He is running Thunderbird 8.0 on Windows 7 Professional (64-bit) on an Intel C2D/4GB RAM system.  As I can duplicate the issue, it appears not to be OS-specific.  Now what I did.

On my 24" iMac (2.66GHz C2D/4GB RAM) running Mac OS X 10.6.8, I have two IMAP accounts configured.  One account is my general work email account.  The other connects to a Cisco CallManager Business Edition appliance running CUCM v8.0.3.10000-8.  This CUCM box is setup to allow users to access their voicemails via an IMAP interface, where each voicemail appears as a separate email with a .WAV file attachment.  This is how most of the folks here are setup, and until the release of Thunderbird 8.0 yesterday, all worked well.

(Ok, not perfect, but it functioned.  That is, until now, when you accessed this CUCM IMAP account, you'd get a list of emails, but none would indicate an attachment.  You would click on a message, and at that moment the paperclip icon would appear to indicate an attachment, and you could open/save the attached .WAV file like normal.  So slight UI glitch, but functionally it worked just fine.)


Actual results:

Now with Thunderbird v8.0, the opposite is happening.  If you check your CUCM IMAP Inbox, you might see paperclips next to some messages (likely cached from previous views?), but if you click on any message, it appears blank with NO ATTACHMENTS!  If you click on a message that was showing a paperclip, the paperclip disappears.  But the key here is the loss of functionality.  There is no way to open/save the attached .WAV file.

Note the message still shows a size that indicates the attachment is there.  And looking at the source of the message, it is clear the message is still there in encoded form.  I believe the problem may have to do with the particular headers provided by the CUCM version of IMAP... that somehow TB 8.0 isn't handling something it did in the past.  The email messages are MIME 1.0 encoded, but unlike most emails, they are not a multi-part message.  There is just the .WAV file encoded in the message.


Expected results:

Ideally, when accessing the CUCM IMAP Inbox, users should see all messages with paperclips next to them, and when an individual message is selected, the user should see the .WAV file as an attachment at the bottom and be able to open/save that file like any other email attachment.

To help this along, I did the following.  I called myself and left a test voicemail message.  I then selected this voicemail message from the CUCM IMAP Inbox and selected [other actions] and chose 'view source' from the popup menu.  I am copy/pasting the contents of that to a text file, which I am attaching below, in hopes that this will provide insight into why TB 8.0 no longer shows the .WAV attachments.

If I can be of any further assistance, please advise.

Comment 1

[Hashem Masoud]

(In reply to Frank from comment #0)
This is an old bug (bug 372696) which could offer some help.

Comment 2

[WADA:World Anti-bad-Duping Agency]

The mail is sent as actual "voice mail".
> Content-Type: audio/wav; name=VoiceMessage.wav
> Content-Disposition: inline; filename=VoiceMessage.wav; voice=Voice-Message

Where can we see ATTACHMENT? Even if Content-Disposition: is written, message body(payload, lines after message headers and first null line) can not be an attachment part in multipart/mixed mail.

AFAIK, Tb is not "voice mail player" yet, and Tb still doesn't have standard feature to show "message body" of non-multipart mail as if attachment(bug 372696 is a request for this), and Tb still doesn't have capability to play audio/wav file as "inlne attachment" even when it's an attachment in multipart mixed mail.

You say "this is Tb's bug(flaw in code of Tb)" because you opened this bug at B.M.O. Does it implies that many popular mailers such as Apple Mail, MS's mailer, ..., already plays the actual "voice mail" as you want?

> and until the release of Thunderbird 8.0 yesterday, all worked well.

Before "Tb 8.0 yesterday", which Tb version did you use?
Does "worked well" mean that you could save the "audio/wav data as message body" as a file because Tb before Tb 8.0 showed it as if attachment?
If so, former Tb releases perhaps showed as if attachmnt by quirks because Content-Disposition exists.

Tb 8.0 already has hidden feature for user's torelance with malformed mail or not-well-formed mail or unplesantly formed mail.
Is next new "All Bdy Parts" feature effective in your case?
(1) Tools/Options/Advanced/General, Config Editor,
    mailnews.display.show_all_body_parts_menu = true
(2) View/Message Body As/All Body Parts

I think the new feature shows the "messsage body of non multipart mail" as if fisrt part in multipart/mixed mail, then it's shown as if attachment in attachment pane.

"Nothing is shown for attached mail with Tb 8.0" is observed.
Confirming.

Comment 3

[WADA:World Anti-bad-Duping Agency]

With any View/Message Body As option, when "Forward" is requested, the audio/wav data is shown as attachment with filename in composition window.
This is phenomenon reported to bug 701619(application/pdf case)

It's possibly a phenomenon due to existence of Content-Disposition: even though message body of non-multipart mail.
Tb's decision on body or attachment is inconsistent. Even though apparent message body part of multipart mail, Tb sometimes treated it as attachment and didn't show as message body, merely by existence of name parameter in Content-Type: header. This kind of inconsistency produces funny phenomenon for user, and produces sudden behaviour change by small change in a Tb release.
The new "All Body Parts" mode is also for user's torelance with such unwanted problems.

Comment 5

[trantor]

The same happens to me on windows platform;

a message in TB 8.0 don't show an xls attachment at all in attachment list;
Switching back to TB 7.01 loose the problem, and attachment is shown as usual..

I've observed The same problem on others PC in my company.

Here follows some information extracted from email source (I've changed sensible informations with the word example):

X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: application/vnd.ms-excel;
	name="=?iso-8859-1?Q?Modif_Affr=Example_Example=2Exls?="
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="=?iso-8859-1?Q?Modif_Affr=Example_Example=2Exls?="
Disposition-Notification-To: "NICOLAS Example, Example" <[e-mail]>
Subject: =?iso-8859-1?Q?Modif_Affr=Example_Example_=3A_____Sem____2011?=
Date: Wed, 9 Nov 2011 16:24:08 +0100
Message-ID: <[e-mail]>
X-MS-Has-Attach: yes

Comment 6

[WADA:World Anti-bad-Duping Agency]

Checked with last nightly build of 7.0a2.
> Mozilla/5.0 (Windows NT 5.1; rv:7.0a2) Gecko/20110816 Thunderbird/7.0a2
Even when Content-Type: audio/wav (no name) and no Content-Disposition:, Tb 7 showed the audio/wav message body as if attachment of filename=attachment.wav.
It seems existence of Content-Disposition is irrelevant.
It looks that Tb 7 or older had quirks of "show non-displayable message body as if attachment", and it looks killed by Tb 8.

Comment 10

[Rick Coloccia]

Is next new "All Bdy Parts" feature effective in your case?
(1) Tools/Options/Advanced/General, Config Editor,
    mailnews.display.show_all_body_parts_menu = true
(2) View/Message Body As/All Body Parts

YES it is.  With this set I can get at my voicemail attachments.

Comment 11

[notas]

Yes I can confirm this works with Bug 702001 too

Comment 12

[Roman Volf]

This worked for me as well.

Comment 13

[Rick Coloccia]

This does present a problem, though.  The option to view message body as all body parts breaks standard html rendering.  I have several accounts in thunderbird and would like to view messages in all other accounts as standard html.  Can this option be restricted to messages in one account as opposed to being applied globally?

Comment 14

[recep]

this does not work for me. we are using pdf's

Comment 15

[trantor]

This worked for me too

Comment 16

[trantor]

(In reply to recep from comment #14)
> this does not work for me. we are using pdf's

Are you sure that you don't forget point 2 ?

(2) View/Message Body As/All Body Parts

Comment 17

[trantor]

I hope anyway, this is only a temporary fix, cause it breaks
all received emails appearance and emails signatures.

Comment 18

[recep]

yes(In reply to trantor from comment #16)
> (In reply to recep from comment #14)
> > this does not work for me. we are using pdf's
> 
> Are you sure that you don't forget point 2 ?
> 
> (2) View/Message Body As/All Body Parts

yes I did #2

I also agree with comment 17, it breaks into to many pieces

Comment 19

[JoS]

The procedure/fix presented in Comment 2 (https://bugzilla.mozilla.org/show_bug.cgi?id=701261#c2)

(1) Tools/Options/Advanced/General, Config Editor,
    mailnews.display.show_all_body_parts_menu = true
(2) View/Message Body As/All Body Parts

makes attachment reappear in Tb 8.0 for messages like this example:

Return-path: <[e-mail]>
Envelope-to: [e-mail]
Delivery-date: Thu, 17 Nov 2011 12:18:20 +0100
Received: from [123.123.123.123] (helo=Goodbye)
	by not.any.com with esmtpa (Exim 4.69)
	(envelope-from <[e-mail]>)
	id 1RQzz1-0004w5-Dq; Thu, 17 Nov 2011 12:18:19 +0100
From: "Dummy" <[e-mail]>
Subject: Report
To: [e-mail]
MIME-Version: 1.0
Sender: Dummy <[e-mail]>
Date: Thu, 17 Nov 2011 12:18:18 +0000
Content-Type: application/octet-stream;
        name="fdp.pdf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
        filename="fdp.pdf"

JVBERi0xLjQNCiXi48/TDQoxMCAwIG9iag0KPDwNCi9UeXBlL0Fubm90L0JvcmRlciBbXS9IL0kv
.
.
.

Comment 20

[Scott Gifford]

Attachment: Problem email with attached voicemail

Here is an example that exhibits the problem for me.  The voicemail does not show up as an attachment in Thunderbird.

Comment 21

[trantor]

May I humbly suggest to elevate the importance of this bug to major ?

we cannot live with missing attachments vs. completely broken emails rendering
In my opinion this is a very severe bug

Comment 22

[recep]

(In reply to trantor from comment #21)
> May I humbly suggest to elevate the importance of this bug to major ?
> 
> we cannot live with missing attachments vs. completely broken emails
> rendering
> In my opinion this is a very severe bug



I concur!

Comment 23

[MGW]

seams to be a similar problem with my Tbs.
Under certain circumstances Tb8 does not show attachments.
With other mail clients (Outlook, android/K9) the attachments of the mails are shown. I'm using Tb and some other clients with IMAP on a private mail server with VMail/postfix under Linux.

In Tb8 Mails which have only an attached file an therefore only have one content like this

  Content-Type: application/pdf;
  	name="Protokoll.pdf"
  Content-Transfer-Encoding: base64
  Content-Disposition: attachment;
  	filename="Protokoll.pdf"

are not shown with any attachment.

If I add an additional content header to received mail-file (editing the file on my mailserver) like this

  Content-Type: multipart/mixed;
  	boundary="----=_NextPart_000_0001_01CC8E6C.8675EFF0"

  This is a multi-part message in MIME format.
 
  ------=_NextPart_000_0001_01CC8E6C.8675EFF0
  Content-Type: application/pdf;
  	name="Protokoll.pdf"
  ...

everything works fine.
So, I think there is a bug in Tb8 on handling mails with single contents if this content belongs to an application (Content-Type: application/...).

Comment 24

[[e-mail]]

Confirming the issue and the workaround for Thunderbird 8.0 on Mac OS X 10.6.8. Before 8.0 this worked fine. The problem occurs for me on PDF attachments.

This is a temporary workaround at best. The behaviour of Thunderbird 7 (and earlier) is much preferred.

Comment 26

[Andre Klapper]

Potential duplicates are bug 703914, bug 701704, bug 701997, bug 704107, and maybe bug 703250. Also see bug 702938 for another issue that has similar outcome.

Comment 27

[Andre Klapper]

(In reply to Andre Klapper from comment #26)
> Potential duplicates are

and bug 705059.

Comment 28

[:aceman]

Also bug 705249.

Comment 30

[Richard Graf]

we receive many orders out of SAP-Systems as email from our customers. the bug occur on that mails, because the mail body is blank and the order is attached as a pdf-file.

I'm sure many other companies have the same problem now after the thunderbird 8.0 update.

In my opinion the importance of this bug should be higher.

Comment 31

[Frank]

Wow.  I'm the one who logged this bug originally 3 weeks ago.  And I've been reading all the emails coming in on this from bugzilla, which gave me the impression that this was a rather active ticket/issue.  Clearly other folks are being affected by the changes brought in v8.0.

But I just now logged into Bugzilla and I see that this bug has yet to even be assigned to anyone!

"Assigned To: 	Nobody; OK to take it and work on it"

What does this mean?
Does this mean that not a single person who has commented is part of the Thunderbird dev community??
Has anyone from the Thunderbird dev community even LOOKED at this bug report, if only to determine its validity?

I realize this is an open-source project, but if the Mozilla developer community is going to go to a "rapid release" cycle of putting out new versions every 6 weeks (ESPECIALLY when they decide to simply force those version updates as they occur on existing users vs. the older, manual mechanism), they also should to at least try and make sure that all their Ooh-Aah features don't go breaking fundamental UI interactions that have existed for... well, as long as I can remember.  This would include checking out new bug reports after a new version gets released, to make sure they didn't inadvertently bork something.

<rant>
Personally, I don't care for the rapid release cycle.  This whole idiotic "full new version every 6 weeks" seems silly to me.  Google puts out Chrome, the last browser to hit the market, and yet it's now at something like v15, whereas IE just hit v9, Firefox WAS at something like v4, and others like Opera were also with lower numbers.  Thunderbird now follows suit.  Does the Mozilla community now subscribe to the "Spinal Tap" theory of software versioning?  "But...but... mine goes to 11", where they think the higher the version number, the better the product?  Surely not.

Worse, however, is that this pace of releases is causing various things to break.  If not addons like 1Password having to be rewritten due to the architectural changes in Firefox, then things like this bug.  If the Mozilla community honestly thinks average Joe User gives a **** about technical features over stability/reliability, they really should look around a bit more.

New features are great.  But don't cause so much grief that people get fed up and leave what is an otherwise incredible project because they become tired of disruptions to their workflow.  Just because developer A added feature B that is "just so cool", it should not cause something else that has, until then, worked reliably to break.

Please, don't sacrifice Q&A so much that the product becomes usable only to geeks and techs who like to live on the bleeding edge and are willing to tolerate such disruptions.  That's what alpha/beta versions were for.

I like Thunderbird and Firefox.  But the more this continues, the more I have to reconsider recommending these programs to my less technical friends and family, as it causes me more support headaches.  I'd be better off telling my Mac users to stick to Safari and Apple Mail, and my Windows users... well, I really can't tolerate leaving the poor bastards on IE or Outlook Express for any reason.  But I could simply recommend they stick to web-based email like Gmail or Yahoo, and possibly use Chrome for their browsing needs.
</rant>

Comment 32

[David :Bienvenu]

Jonathan, do you think this is caused by the fix for bug 351224? I ask only because the show all body parts menu lets people see these attachments again. Or was this regression caused by us not showing attachments w/o filenames?

Comment 33

[David :Bienvenu]

ok, this looks like a result of us not showing attachments w/o names - Jim?

Comment 34

[David :Bienvenu]

given the number of dups, we need to track this bug. If we need to, we should backout the fix that's caused the regression.

Comment 35

[Jim Porter (:squib)]

(In reply to David :Bienvenu from comment #33)
> ok, this looks like a result of us not showing attachments w/o names - Jim?

That does appear to be the problem. We forgot to update ProcessBodyAsAttachment[1] to deal with that change. I have a patch for this, but it still needs tests.

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

Comment 36

[David :Bienvenu]

(In reply to Jim Porter (:squib) from comment #35)
> (In reply to David :Bienvenu from comment #33)
> > ok, this looks like a result of us not showing attachments w/o names - Jim?
> 
> That does appear to be the problem. We forgot to update
> ProcessBodyAsAttachment[1] to deal with that change. I have a patch for
> this, but it still needs tests.
Great, yeah, I was going to mention that we need a test for this.

I'd really like to get a fix for this into 9.0, so anything you can do to get this moving in the next few days would be much appreciated.

Comment 37

[Jim Porter (:squib)]

Attachment: Fix this and test it (plus make body "attachments" report their size)

Here's a fix for this. To make testing easier, and because it's the right thing to do, I also made these body "attachments" report their size, so now when you open a message like this, it won't just say "unknown size".

Comment 38

[WADA:World Anti-bad-Duping Agency]

Attachment pane display of Tb 7 was affected by name parameter of simple text mail with next Content-Type: header.
> Content-Type: text/plain; name="VoiceMessage.TXT"
> (no Content-Disposition:, no Content-Transfer-Encoding:)
(1) Mozilla/5.0 (Windows NT 5.1; rv:7.0a2) Gecko/20110816 Thunderbird/7.0a2
    VoiceMessage.TXT was shown in attachment pane,
    in addition to normal text display at message pane.
   (problem of "not showing message body if name specified" is already resolved)
(2) Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0
    Nothing is shown in attachment pane.
    Needless to say, with normal text display at message pane.

Attachment pane display of Tb 7 was also affected by "message body is displayable or non-displayable".
> Content-Type: audio/wav
> (no name, no Content-Disposition:, no Content-Transfer-Encoding:)
(3) Mozilla/5.0 (Windows NT 5.1; rv:7.0a2) Gecko/20110816 Thunderbird/7.0a2
    attavhment.wav was shown in attachment pane.
    Nothing is shown at message pane because of audio/wav.
(4) Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0
    Nothing is shown in attachment pane.
    Nothing is shown at message pane because of audio/wav.

Jim Porter, is your patch for problem of (4)? How about phenomenon of (2)?
I think there is no need to show message body as if attachment when displayable, even if Content-Disposition:attachment and/or name/filename is specified for message body of non-multipart mail.

Comment 39

[Jim Porter (:squib)]

This will display an attachment in the attachment pane for both cases (2 and 4). While it might make sense for the attachment pane not to include a named body if it's also rendered inline, Thunderbird doesn't follow that rule for multipart/mixed subparts. As far as I can tell, RFC 2183 doesn't specify that Content-Disposition is meant to be used only in multipart/mixed subparts; it looks like it can be used in the root part as well. Therefore, I think we should be consistent and handle body "attachments" just the same as multipart/mixed attachments.

In any case, the patch is wrong for another reason and I'll be uploading a new one shortly.

Comment 40

[Jim Porter (:squib)]

Attachment: Body parts shouldn't always have names

Libmime is full of mysteries. Apparently ProcessBodyAsAttachment is always run (presumably so that the "Show All Body Parts" option can treat the body as an attachment), which means that we shouldn't always treat the body "attachment" as having a name. Otherwise, every message appears to have an attachment.

Comment 44

[WADA:World Anti-bad-Duping Agency]

Attachment: Non-displayable message body part in multipart/mixed, depends on existence of filename(perhaps name too)

Two mails of multipart/mixed, with non-displayable message body part.
 part-1: audio/wav, no name (Voice00 in string)
           mail-1 : no filename
           mail-2 : with filename
 part-2: text/plain,      no filename,   no name (Voice01 in string)
 part-3: audio/wav,       no filename,   no name (Voice02 in string)
 part-4: application/pdf, no filename,   no name (Voice03 in string)
 part-5: text/plain,      with filename, no name (Voice11 in string)
 part-6: audio/wav,       with filename, no name (Voice12 in string)
 part-7: application/pdf, with filename, no name (Voice13 in string)

(A) non-displayable message body part(part-1) is;
    mail-1 (no filename)   : not shown at attachment pane
    mail-2 (with filename) : shown at attachment pane
(B) parts without filenam(part-2 to part-4) is not shown at attachment pane
    parts with    filenam(part-5 to part-7) is at attachment pane

Above (B) is phenomenon/problem of bug 705431 & bug 702938 and is irreleant to this bug, but (A) is relevant to both this bug(non-displayable message body) and bug 705431 & bug 702938.

Jim Porter, can your patch resolve above (A) too?

Comment 45

[Jim Porter (:squib)]

This patch only applies to *non*-multipart messages. Nothing else is affected.

Comment 46

[Jonathan Protzenko [:protz]]

Is this not subsumed by bug 705431 ?

Comment 47

[Jim Porter (:squib)]

(In reply to Jonathan Protzenko [:protz] from comment #46)
> Is this not subsumed by bug 705431 ?

Mmmaybe? That all depends on how you handle that patch. I'd say it's very likely that you'll be touching some of the same code as this, but the two changes are logically distinct. This one is basically about updating the non-multipart case to account for bug 564423 and bug 561851. The other bug is about adding logic for "Content-Disposition: attachment" means "this is *definitely* an attachment" right?

Comment 48

[WADA:World Anti-bad-Duping Agency]

See bug 705431(and bug 702938) if multipart mail case.

Comment 49

[Jonathan Protzenko [:protz]]

Okay, makes sense to have two patches then :).

Comment 50

[David :Bienvenu]

Comment on attachment 578164 [details] [diff] [review]
Body parts shouldn't always have names

thx, Jim - this does fix the basic problem.

this should be !id_imap, per our coding style guide:

+  tmp->m_isDownloaded = (id_imap == nsnull);
+

Do we need a separate test beyond the size test to verify that the attachment is added to the message, or is that redundant w/ the size test?

Comment 51

[Jason Haar]

me too. We use Cisco Unity for voicemail and its emails look like this

MIME-Version: 1.0
Content-Type: audio/wav;
        name="VoiceMessage.wav"
Content-Transfer-Encoding: base64
Content-Description: VoiceMessage
Content-Disposition: attachment;
        filename="VoiceMessage.wav"

Totally valid MIME - TB just doesn't understand a non-text(ish) MIME message. I see a "blank" email instead of a "blank" email with an attachment (that's what Outlook does)

Jason

Comment 52

[Jim Porter (:squib)]

(In reply to David :Bienvenu from comment #50)
> this should be !id_imap, per our coding style guide:
> 
> +  tmp->m_isDownloaded = (id_imap == nsnull);
> +

Fixed. Since I followed that style from another part of this file, I've made the corresponding change there as well.

> Do we need a separate test beyond the size test to verify that the
> attachment is added to the message, or is that redundant w/ the size test?

No, the attachment size is emitted if and only if an attachment is added to the message.

(In reply to Jason Haar from comment #51)
> me too. We use Cisco Unity for voicemail and its emails look like this

I copied this into a sample .eml and it works as you'd expect.

Comment 53

[Jim Porter (:squib)]

Checked in: http://hg.mozilla.org/comm-central/rev/97dfc499d575

Comment 54

[JoS]

I would advice to stop fiddling toes and get the socks off;  this bug might be extremely detrimental to TB's general standing.

To me all reports seem to stem from received messages created by more or less 'single minded' automated systems transmitting simple attachments as the sole message.

Current TB handling of this scenario is obviously not optimal:  A message with some contents signalled as attachment should at all times display an indication of and access to the attachment in question;  this is fundamental.

The fix (or maybe rather 'cludge') presented very early by WADA ([e-mail]) in comment 2 (https://bugzilla.mozilla.org/show_bug.cgi?id=701261#c2) satisfies this requirement, but often clutters further handling of 'innocent' messages to an almost impossible degree - obviously not a perfect solution.


Best regards to all handling this!

JoS

Comment 55

[Jim Porter (:squib)]

(In reply to JoS from comment #54)
> I would advice to stop fiddling toes and get the socks off;  this bug might
> be extremely detrimental to TB's general standing.

This bug is fixed. The only thing that remains is backporting it to 9.0 and 10.0.

Comment 56

[JoS]

(In reply to Jim Porter (:squib) from comment #55)
> (In reply to JoS from comment #54)
> > I would advice to stop fiddling toes and get the socks off;  this bug might
> > be extremely detrimental to TB's general standing.
> 
> This bug is fixed. The only thing that remains is backporting it to 9.0 and
> 10.0.

Jolly good, squib - gimme that fix to return to normal e-mail handling and TB efficciency - thank you!

JoS

Comment 57

[yorlik]

when will it be ported to 9.0 so I can update our emails in our office?  I had to downgrade to previous version to keep Thunderbird running acceptably.....

Comment 58

[Jim Porter (:squib)]

(In reply to yorlik from comment #57)
> when will it be ported to 9.0 so I can update our emails in our office?  I
> had to downgrade to previous version to keep Thunderbird running
> acceptably.....

When I push the change to comm-beta (and then when the next beta is released).

Comment 59

[Jim Porter (:squib)]

http://hg.mozilla.org/releases/comm-aurora/rev/27141263834b
http://hg.mozilla.org/releases/comm-beta/rev/dd915d6cd71d

Comment 60

[WADA:World Anti-bad-Duping Agency]

(In reply to Jim Porter (:squib) from comment #53)
> Checked in: http://hg.mozilla.org/comm-central/rev/97dfc499d575

Checked with trunk nightly build.
> Mozilla/5.0 (Windows NT 5.1; rv:11.0a1) Gecko/20111205 Thunderbird/11.0a1
(a) Content-Type: audio/wav; name=X.WAV => Body is shown as attachment
(b) Content-Type: audio/wav             => Body is not shown as attachment
(c) Content-Type: audio/wav
    Content-Disposition: attachment     => Body is not shown as attachment

Jim Porter, show as attachment/not show as attachment still based on existence of name/filename only? We still need to wait future enhancements/improvements for attachment/inline based one and/or displayable/non-displayable based one?

Anyway, VERIFIED by (a). Actual cases has name/filename in message header.

Comment 61

[Jim Porter (:squib)]

(In reply to WADA from comment #60)
> (a) Content-Type: audio/wav; name=X.WAV => Body is shown as attachment
> (b) Content-Type: audio/wav             => Body is not shown as attachment
> (c) Content-Type: audio/wav
>     Content-Disposition: attachment     => Body is not shown as attachment
> 
> Jim Porter, show as attachment/not show as attachment still based on
> existence of name/filename only? We still need to wait future
> enhancements/improvements for attachment/inline based one and/or
> displayable/non-displayable based one?

Correct. (c) (and possibly (b)) will be handled in bug 705431. Discussion on the proper behavior for these cases should happen in that bug so that protz sees it and can respond to it.

Comment 62

[Mark Banner (:standard8)]

The landed on beta broke the build, I pushed a bustage fix but please double-check the patch as it looks like it was affected by bitrot:

http://hg.mozilla.org/releases/comm-beta/rev/7b09fc4f9f86

Comment 64

[Jim Porter (:squib)]

(In reply to Mark Banner (:standard8) from comment #62)
> The landed on beta broke the build, I pushed a bustage fix but please
> double-check the patch as it looks like it was affected by bitrot:
> 
> http://hg.mozilla.org/releases/comm-beta/rev/7b09fc4f9f86

That looks right, though it's really strange, since I had encountered some bitrot, and thought I'd fixed it. Guess not...