1406868 - Allow to switch to display other mime parts in case of multipart/alternative that has a text/calendar part ( "cancel with note" note text not shown anywhere)

Status: RESOLVED DUPLICATE of bug 760412

(Calendar :: E-mail based Scheduling (iTIP/iMIP), enhancement, P2)

Description

[Tristan Miller]

Attachment: Multi-part MIME message containing HTML+iCalendar

When declining an event, some calendar clients will send a multi-part MIME e-mail.  One of these parts will be a text/html part containing a human-readable message, and the other part will be a text/calendar part containing the iCalendar entry updated with attendee info.

The problem is that Lightning displays only a suitably formatted version of the text/calendar part, not the text/html part.  This means that if someone tries to send me a message explaining why they are declining my invitation, there is no way for me to see it.  Changing the View->Message Body As settings does not work around the problem.

Attached are two screenshots of the same message viewed in Thunderbird 52.3.0, one with Lightning 5.4.3 enabled and one with Lightning disabled.  The HTML message is shown only when Lightning is disabled.  Also attached is the original message (with personal names redacted).

Comment 1

[Tristan Miller]

Attachment: Screenshot showing how Thunderbird+Lightning displays the message

Comment 2

[Tristan Miller]

Attachment: Screenshot showing how Thunderbird without Lightning displays the message

Comment 4

[Jorg K (CEST = GMT+2)]

Let's confirm this here since it has a reproducible test case.

Comment 6

[Jorg K (CEST = GMT+2)]

When opening the attached sample e-mail I see various errors saying that this time zone
  TZID:Amsterdam, Berlin, Bern, Rome, Stockholm, Vienna
isn't valid. Changing this to Europa/Amsterdam I run into further problems since the message is a reply declining an invitation and the original event is not in my calendar since I didn't send the invitation in the first place.

I thought this might be related to bug 1360155, but it's not.

MakeMyDay, since you did some duping here (which I undid), have you looked at this case?

Comment 7

[[:MakeMyDay]]

As I stands, we're doing the right thing already here. Since this is a multipart/alternative type message, displaying only the calendar part in this case is correct.

The sending party should have either included the message text in a comment property in the text/calendar part (which is something the Exchange Server in general is capable to do; comments if any are displayed in the invitation preview) or have sent the message as multipart/mixed, so it's basically a configuration issue of the sender (client or server).

Unfortunately, that doesn't really help a TB/Lightning user receiving such an invitation. The only option I see here would be to work around by relaxing the behaviour of the mime parser to treat even a multipart/alternative as multipart/mixed in case a text/calendar section is involved. But I'm not sure whether this is something we really should do.

Comment 8

[Tristan Miller]

(In reply to [:MakeMyDay] from comment #7)
> As I stands, we're doing the right thing already here. Since this is a
> multipart/alternative type message, displaying only the calendar part in
> this case is correct.

I agree.  However, it isn't *incorrect* to offer the user the choice of which part to display.  Quoth RFC 2046:

> It may be the case that some user agents, if they can recognize more
> than one of the formats, will prefer to offer the user the choice of
> which format to view.  This makes sense, for example, if a message
> includes both a nicely- formatted image version and an easily-edited
> text version.  What is most critical, however, is that the user not
> automatically be shown multiple versions of the same data.  Either
> the user should be shown the last recognized version or should be
> given the choice.

Offering this choice, via the View->Message Body As menu, seems to be what Thunderbird itself does with multipart/alternative messages where one part is plain text and the other part is HTML.  Why not provide similar functionality with Lightning?  Display the last (text/calendar) part by default, but provide some mechanism that allows the user to see the other (text/html) part.

Comment 13

[Magnus Melin [:mkmelin]]

Code wise, we need to figure out what and how https://searchfox.org/comm-central/source/calendar/lightning/components/CalMimeConverter.jsm hooks up itself.
https://searchfox.org/comm-central/rev/4a07865f0fd09191dbc094acc58f47a4b563606a/mailnews/mime/src/mimei.cpp#421-441

Comment 15

[Pierre Ossman]

For reference, how do other mail clients display these mails? If they are sending these combinations where both the text (or html) and the text/calendar parts are important I assume they themselves show both somehow?

Comment 16

[bhakta0007]

What should we do to prioritize this?

I know a few in my organization who stopped using TB due to this. I would like to get them back on TB.

@Magnus: I see your note on the code, but unfortunately lack the context to fix this code myself. I can also offer to take a look to fix this if I can get some guidance on the relevant code paths (never developed for TB so far, but would love to).

Comment 17

[Magnus Melin [:mkmelin]]

Since this is ultimately about a mime structure misuse in a way, it may be difficult to change it in libmime (mailnews/mime).

I wonder if the code that creates the overlay - https://searchfox.org/comm-central/rev/eff17f98bda26955f964ea3de3c3c2776810f5a2/calendar/lightning/components/CalMimeConverter.jsm#64 - could grab the message (by the uri) and use MsgHdrToMimeMessage to get the plain text or html parts - and then insert it as appropriate in the overlay. Would be a bit hacky but could potentially work.

If you want take a stab at it, see https://developer.thunderbird.net and https://searchfox.org/comm-central

Comment 19

[Meredith]

I don't use calendaring in TB at all. Previously, I could just keep Lightning disabled and avoid this problem, but now Lightning is fully integrated and can't be disabled to avoid it any longer, not that it fixes things for those who do. A previous iteration of this basic issue was filed 14 years ago in bug 388584.

It looks like maybe CalMimeConverter could include a hack to grab the message by uri and presumably parse it to find the text and html parts and obey user preference for which to display and put that above or below the overlay, or an option to switch which body part is displayed on each message could be added, but I think the least bad resolution may be to force MIME handling to stop considering text/calendar as a possible alternative in a multipart/alternative group one way or another? When the vcal object is not displayed as the body, it's shown as an inlined attachment, according to pref, in the same rendering, below the user-selected message body, with the calendar header popdown (imip bar?) still showing as well. I tested out the user-visible result by saving a calendar message and switching MIME boundaries to move the vcal part.

Comment 20

[Zoe Martin]

This is fixed by bug 760412 comment #27, in fact, this is a duplicate of that bug.