It works here, so I wonder if you have an incompatible add-on. Run TB in safe mode (hold Shift when you launch TB), and see if csv attachments appear inline. If it doesn't help, it could be that the attachment handling for csv files has become damaged. Do you have an entry in Tools/Options/Attachments/Incoming for csv Content Type?

Thanks, but running without add-ons didn't fix it.

I have spent a couple of hours this morning and have narrowed down the problem to a minimum reproducible set of steps. The problem occurs in the transition from TB 45.8.0 to 52.0, in other words the problem doesn't occur in 45.8.0 but does occur in 52.0.

Proceed as follows, in both 45.8.0 and 52.0:

• Create a brand new TB profile
• Click to configure an account later
• Quit TB
• Open the profile folder
• Make a mimeTypes.rdf file containing (this is a cut down file which demonstrates the problem - with a non-existant mimeTypes.rdf file, as default, the CSV is *not* shown inline in either 45.8.0 or 52.0):

<RDF:RDF xmlns:NC="http://home.netscape.com/NC-rdf#"
        xmlns:RDF="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
 <RDF:Description RDF:about="urn:mimetype:text/csv"
                  NC:fileExtensions="csv"
                  NC:description="Microsoft Excel Comma Separated Values File"
                  NC:value="text/csv"
                  NC:editable="true">
   <NC:handlerProp RDF:resource="urn:mimetype:handler:text/csv"/>
 </RDF:Description>
 <RDF:Seq RDF:about="urn:schemes:root">
 </RDF:Seq>
 <RDF:Seq RDF:about="urn:mimetypes:root">
   <RDF:li RDF:resource="urn:mimetype:text/csv"/>
 </RDF:Seq>
 <RDF:Description RDF:about="urn:root"
                  NC:en-GB_defaultHandlersVersion="-1" />
 <RDF:Description RDF:about="urn:mimetype:handler:text/csv"
                  NC:alwaysAsk="true"
                  NC:useSystemDefault="true"
                  NC:saveToDisk="false">
   <NC:externalApplication RDF:resource="urn:mimetype:externalApplication:text/csv"/>
 </RDF:Description>
 <RDF:Description RDF:about="urn:schemes">
   <NC:Protocol-Schemes RDF:resource="urn:schemes:root"/>
 </RDF:Description>
 <RDF:Description RDF:about="urn:mimetypes">
   <NC:MIME-types RDF:resource="urn:mimetypes:root"/>
 </RDF:Description>
</RDF:RDF>

• Create a text file anywhere called test.eml containing:

To: <test@example.com>
From: <test@example.com>
Subject: test CSV attachment
Date: Thu, 27 Apr 2017 09:55:58 +0100
Content-Type: multipart/mixed;
	boundary="------------5D27B340E9C850CE2E11E73A"
Content-Language: en-GB
MIME-Version: 1.0

--------------5D27B340E9C850CE2E11E73A
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Transfer-Encoding: 7bit

This is the body text


--------------5D27B340E9C850CE2E11E73A
Content-Type: application/octet-stream; name="test.csv"
Content-Transfer-Encoding: base64

RmllbGQxLEZpZWxkMixGaWVsZDMNCjEyMywiYWJjIiw0NTYNCg==

--------------5D27B340E9C850CE2E11E73A--

• Run TB again
• Again click to configure an account later
• Double-click the .eml file and open it in Thunderbird
• Click Cancel then Exit on the Account Wizard

In 45.8.0 you will see the first image. In 52.0 you will see the second. The behaviour of 45.8.0 is much more desirable to me.

I've looked at the changelog for 52.0 but I'm not sure what may have caused this change, or whether it was intended or not. I haven't tried the beta versions between 45.8.0 and 52.0, but hopefully the above is enough for someone to be able to investigate this. I'm happy to open this in bugzilla.mozilla.org if it is seen as a bug.

There may be differences between 45 and 52 in attachment handling, but in this case I think the problem is due to the 'Content-Type: application/octet-stream' header for the csv. On my system, the message source shows 'Content-Type: text/plain' for a csv attachment, which is why it displays inline in TB 52. I also have no entry for csv in mimeTypes.rdf. The Content-Type depends on how the sender's email program encodes attachments, so I suggest you send yourself a csv from TB and see if it has the correct encoding.

There is a discussion here as to how you might circumvent the problem induced by other email programs.

Yes, for me, the particular CSV attachments that I'm having trouble with in 52 (but which worked in 48) are being sent as Content-Type: application/octet-stream, from an external system over which I have no control.

Thanks for the link. However that page seems to only be about what happens when you double-click an attachment, not control over whether an attachment shows inline or not.

An attachment will only be shown inline if TB knows how to open the file, and the reason it doesn't in your case is because of incorrect Content-Type produced by the sender's email program. So, to 'help' TB open such files you need to receive a properly-encoded csv file, set the default action to open the file with a non-system-default application, e.g. Notepad in the case of csv, and check 'Do this automatically...' so the setting is stored in Options/Attachments, even if you have no need to actually open csv files with Notepad. The point is to have a defined option for treating csv attachments with incorrect encoding.

If you still cannot get csv files displayed inline in TB 52, I suggest you start by looking at existing, related bugs.

I've tried this with no difference, although to be clear I've done this on a "application/octet-stream" CSV attachment, and I'm not sure if that's what you meant by a "properly-encoded csv file".

You have to set the Attachments option with a csv attachment that appears in the message source with 'Content-Type: text/plain'. On my system, sending a csv attachment from TB to any other account I have in TB results in an attachment with this 'correct' encoding. Some years ago a similar issue arose because TB was not encoding certain attachments correctly, so the problem couldn't be fixed with a message sent from TB. The solution was to send a message from the hotmail or gmail website, which did proper encoding, and receive it in TB. I have encountered the same problem with Firefox downloading mkv files: after it handles a properly-encoded mkv, all subsequent mkv files are handled correctly.

I edited the saved test.eml file from the original post, changing application/octet-stream to text/plain. If I open that .eml file in Thunderbird, I can see the CSV inline. I clicked on the attachment and set it to open in Notepad and ticked to do this by default. But this still doesn't make application/octet-stream CSV attachments view inline, which they used to do in v48.

I can't find any existing bug covering this, so I'll open a new one. Thanks for your advice so far.

https://www.iana.org/assignments/media-types/application/octet-stream

That is the detail on application octet stream. As you see doing anything with it is not recommended. This recommendation is based on security issues that could arise if the octet stream were a binary executable (read malware)

Basically the sender is malforming the email.