Closed Bug 1295965 Opened 9 years ago Closed 9 years ago

text/calendar not treated as attachment

Categories

(Thunderbird :: Untriaged, defect)

45 Branch
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 760412

People

(Reporter: u93378, Unassigned)

Details

Attachments

(2 files)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.116 Safari/537.36 Steps to reproduce: Received email from Outlook whose content type is text/calendar: Content-Type: text/calendar; method=REQUEST; charset="UTF-8" Actual results: VCALENDAR record was displayed raw, instead of being treated as an attachment that can be exported to a calendar program (or displayed readably). Expected results: Ideally, I would see the content of the VCALENDAR record rendered readably. But definitely, I should get the option to export the VCALENDAR record so that I can import it into a calendar program (e.g., Google Calendar, Apple Calendar).
I see that the vcalendar record contains a field, X-ALT-DESC;FMTTYPE=text/html:, that shows a message that TB could render for more readable view. I will try to collect a sample message without confidential information and post it as an attachment.
Is the Lightning calendar installed and enabled? It should be by default.
Attachment #8781991 - Attachment mime type: message/rfc822 → text/plain
One noteworthy detail: "Content-Type: text/calendar;" is actually the top-level MIME type, whereas usually it would be contained in a "Content-Type: multipart/mixed;" or "Content-Type: multipart/alternative;" context (the latter especially seen with Outlook). Nevertheless, at least for me, Lightning 4.7 correctly picks this up when opening foo.eml from the File menu.
(In reply to rsx11m from comment #4) > Is the Lightning calendar installed and enabled? It should be by default. Oh, you can check this by clicking "Add-ons" from the [≡] button menu.
You are right: I have disabled the Lightning calendar add-on. I use Google calendar for my calendar needs. In the past I would get .ics attachments, and import them into the Google Calendar. But now it seems like calendar attachments are either handled by Lightning, when enabled, or not exposed for use as attachments, when Lightning is disabled. I do not wish to use Lightning, since it does not provide the cross-device synchronization I need. I don't mean to express any criticism for Lightning: it's just not for me. Did support for people who want to use other calendars get inadvertently damaged when Lightning was more completely integrated into Thunderbird?
No, it's quite likely just the way this specific message is formed, having *only* the calendar entry as message body and as the top-level MIME type. It shows as an attachment with Lightning disabled in other cases because there it's a secondary MIME part which is handles as any other attachment. So, strictly speaking, it appears that the behavior to show a text/* main MIME part simply as text is correct, and there is no filename or content disposition given either that would hint to display it as an attachment. The only clue is "method=REQUEST;" in the Content-Type header.
I see your point, but from the User point of view, if Microsoft Outlook is spitting out these things, I'd really like to be able to handle them in a more sensible way than having to visually parse a format that is intended only for machine consumption. When Lightning is enabled, aren't these treated better? When I turn Lightning on, I see what looks like the HTML content of the X-ALT-DESC;FMTTYPE=text/html field. Would it be possible to enable this display when Lightning is disabled? That would be a reasonable half step: at least it would let me hand-transcribe the invitation into my calendar of choice.
Parsing that format and displaying it in a "human readable" form is performed by Lightning, and as such available when that extension is enabled. I doubt that any Thunderbird developer would duplicate that behavior in Thunderbird itself if Lightning is not enabled (or not installed). Making a text/calendar MIME part available for storage or opening with another application is a different story and sure should be investigated.
Agreed. I'd be happy if I could send it off to another application for saving. But, of course, if an invitation isn't rendered with any useful information, then what would we see? Having to simply click on a wholly opaque attachment seems like a security problem (if only because TB would be training users to be careless about attachments). I'm not trying to be difficult: I see that these are problematic issues.
> I doubt that any Thunderbird developer would duplicate that behavior in Thunderbird itself if Lightning is not enabled (or not installed). Are you suggesting wontfix? I'm almost certain I've seen this reported before
Flags: needinfo?(rsx11m.pub)
(In reply to Wayne Mery (:wsmwk, NI for questions) from comment #12) > > I doubt that any Thunderbird developer would duplicate that behavior in Thunderbird itself if Lightning is not enabled (or not installed). > > Are you suggesting wontfix? I'm almost certain I've seen this reported > before I read that full comment (versus the little snippet here) not as a wontfix, but as a "won't try to replicate Lightning's rendering logic, but we should make it possible to save the .ics for handling by external calendars." I don't mean to be difficult, but I'm already pretty committed to my current calendaring solution, so I really don't want TBird to try to force me into using Lightning.
I was just trying to figure out what rsx11m was thinking. Not trying to suggest it SHOULD be wontfix. Quite the contrary, I'd also like to see it fixed. See bug 505024
Status: UNCONFIRMED → RESOLVED
Closed: 9 years ago
Flags: needinfo?(rsx11m.pub)
Resolution: --- → DUPLICATE
(In reply to Robert Goldman from comment #13) > I read that full comment (versus the little snippet here) not as a wontfix, > but as a "won't try to replicate Lightning's rendering logic, but we should > make it possible to save the .ics for handling by external calendars." Yes, that's what I meant - and apparently bug 505024 handles that topic already.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: