1311930 - Only one .ics attachment showing in the attachment area

Status: RESOLVED DUPLICATE of bug 547754

(Calendar :: General, defect)

Description

[Mathias Landgraf]

Attachment: Parametric_Curve.ics

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:49.0) Gecko/20100101 Firefox/49.0
Build ID: 20160922113459

Steps to reproduce:

I received an Email.


Actual results:

Attachments were missing. Only the first attachment was preserved, the rest deleted  (or are at least invisible and not accessible).

The same e-mail sent to an Outlook client or Google Mail is received successfully, with all attachments.

.ics in this case is not the common appointment/calendar format, but a binary file format (used since ~1995, CAD program IronCAD from IRONCAD, Atlanta, GA).
The one remaining attachment, once saved, is fully functional.

Let me know if you would need a test email with three attachments.




Expected results:

All three attachments should be preserved (and eventually a further step: no Thunderbird/Firefox calendar should try to mangle with these attachments as they are in an unknown format - like Outlook does.).

Comment 1

[Jorg K (CEST = GMT+2)]

> Let me know if you would need a test email with three attachments.
Yes, please.

Comment 2

[Jorg K (CEST = GMT+2)]

In a private message the reporter send me a multipart/mixed message which contained three attached .ics files. Only the first one shows in the attachment area, the other two can be seen when viewing the source of the message.

The part header looks like this:
Content-Type: text/calendar;
	name="Curve.ics"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="Curve.ics"

TB is choking on this message. Usually I have messages marked as "read" when the are displayed for a few seconds in the previous pane. Not this one.

On the console I see:Component returned failure code: 0x804a0100 [calIICSService.parseICS] calIcsParser.js:145

I'll move this to product "Calendar". Perhaps, as the description says, we should stop parsing an ICS file if it's not of the correct format.

Comment 3

[[:MakeMyDay]]

Whatever this is, it seems not to be a valid ics. Maybe something went wrong when extracting this from the message.

In general for email invitation related issues, we need always the entire email and not just an ics part to be attached to investigate the issue. If you can attach this, we can take a look.

Comment 4

[Mathias Landgraf]

(In reply to [:MakeMyDay] from comment #3)
> Whatever this is, it seems not to be a valid ics. Maybe something went wrong
> when extracting this from the message.
> 
> In general for email invitation related issues, we need always the entire
> email and not just an ics part to be attached to investigate the issue. If
> you can attach this, we can take a look.

Hi MakeMyDay,
from your answer I can take that you seem not to have fully understood the problem.

The attachments do not have calendar file format (they only carry the extension .ics), but a format of a mechanical design program. It renders Thunderbird unuseable for this group of users - they only receive one attachment; the rest is cut off.

FYI: I have sent an email to your Email address in parallel.

Comment 5

[Jorg K (CEST = GMT+2)]

Please read comment #2. I've already experimented with those "other" .ics files. TB tries to parse them and fails miserably. What needs to be done here is to improve the ICS parser, so if it doesn't find the expected format, it stops *gracefully*.

Comment 6

[Philipp Kewisch [:Fallen][📱📆]]

Are there any error console messages? Lightning uses a nsISimpleMimeConverter implementation, which is registered per mime-type. Given the sender is mistakingly assuming text/calendar, Lightning tries to parse it.

The parser will of course fail, but I am not sure what happens when the method throws. Thunderbird should probably be catching exceptions and then displaying the attachment with other methods. If we catch the error then all we can do is return an empty string or simply the input data as a html string, but that would inline the attachment and probably also not be right.

I'd appreciate if you could attach the .eml file nevertheless, this makes testing easier. You are welcome to redact various headers that contain private information as long as the general structure stays as it is.