text/calendar attachments are not shown at all

Bug #849416 reported by jan on 2011-09-13
This bug affects 4 people
Affects Status Importance Assigned to Milestone
seamonkey (Ubuntu)

Bug Description

Upon receiving mail with an attachment with type text/calendar (generated by e.g. outlook), no sign of the attachment is shown in seamonkey.
In seamonkey 1.x, a reasonable summary of the request was being shown, so I consider this a regression bug.
Only in view source mode, I am able to find THAT an attachment is sent.
However, I would not know what kind of viewer to use.

Content-Type: text/calendar; charset="utf-8"; method=REQUEST
Content-Transfer-Encoding: base64

the message header contains (amongst other information):

x-tm-as-user-blocked-sender: No
Content-Type: multipart/alternative;
MIME-Version: 1.0

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803

Moz1.7.2 hides text/calendar of multipart/alternative messages (from MS-Exchange
200x) because it does not know how to display them.
"Unknown" or non-displayable types should not be hidden, but should be shown as

Reproducible: Always
Steps to Reproduce:
example msg: (bits)

[beginning of msg]
MIME-Version: 1.0
Content-Type: multipart/alternative;
Content-class: urn:content-classes:calendarmessage
This is a multi-part message in MIME format.

Content-Type: text/plain;
Content-Transfer-Encoding: quoted-printable
[plain text content]
Content-class: urn:content-classes:calendarmessage
Content-Type: text/calendar;
Content-Transfer-Encoding: 8bit
[vcalendar entry]
[end of msg]
Actual Results:
"Content-Type: text/calendar;" is completely hidden if some other content is

Expected Results:
Display as attachment.
(alt fix: see http://bugzilla.mozilla.org/show_bug.cgi?id=130119)

If a text/calendar type is detected, and Calendar(Sunbird) is integrated into
Moz/Tbird, create a button/popup/icon in the window to export the text/calendar
part into Calendar.

Related items: http://bugzilla.mozilla.org/show_bug.cgi?id=130119#c4
and http://bugzilla.mozilla.org/show_bug.cgi?id=142092#c4

I can confirm that this happens, but isn't the point of alternative parts to
have a failback for browsers that don't support some of these functions? I do
see the RFE for recognizing and exporting vcalendar items and will confirm that.


The problem is how Mozilla decides which part to display, and which part to
hide. Is there some standard that says use first recognizable and ignore the
rest? or is it an internal design decision for Moz?

If I install a calendar plugin, can that plugin tell Moz to utilize
text/calendar; types instead of text/plain; types? (If so, maybe I need to log
this bug against the calendar/sunbird project, because they are not doing it.)

It's supposed to chose the best form that it knows how to handle. It will choose
HTML over text, for example.

From http://www.w3.org/Protocols/rfc1341/7_2_Multipart.html, section 7.2.3:

'The user agent should either choose the "best" type based on the user's
environment and preferences, or offer the user the available alternatives. In
general, choosing the best type means displaying only the LAST part that can be

In , Mcow (mcow) wrote :

*** Bug 336436 has been marked as a duplicate of this bug. ***

In , Moco (moco) wrote :

sorry for the spam. making bugzilla reflect reality as I'm not working on these bugs. filter on FOOBARCHEESE to remove these in bulk.

11 comments hidden view all 152 comments

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20090718 Shredder/3.0b4pre

I have received a .ICS calendar meeting attachment, but no visual evidence of the invitation exists; no attachment item, nor text display within the message. I used to receive these as just text within the message.

Here is the MIME type and beginning of attachment (from message source):
Content-class: urn:content-classes:calendarmessage
Content-Type: text/calendar;
Content-Transfer-Encoding: quoted-printable

PRODID:Microsoft CDO for Microsoft Exchange

Is the change to component "Lightning" correct? I don't have lighting installed, I'm using MeetingMaker to handle my calendar info. Also, this issue is evident in Tbird safe mode so I'm sure it is not being affected by add-ins.

Hmm maybe I read that wrong then.

Do you have View | Display Attachments inline checked?
Can you attach a sample .eml?

Created attachment 389696
.eml of message with issue.

Calendar attachment does not appear even when display attachments inline is turned off.

BTW, I tried to do some cleanup of the data within the calendar invite; if it doesn't work, let me know of an individual working on this issue and I can send the original to them so I don't post potentially sensitive information to the ticket. However, I did open the email with the altered data and it still appears the same - no attachment and no text, with or without display attachments turned on using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20090720 Shredder/3.0b4pre.

The sample shows just fine for me. (As an invitation text without lightning, an invitation with lightning.)

Interesting. I have two different machines (one XP 64bit, one Xp 32bit) and both don't show any attachment, even with attachment not displayed inline (they have completely different profiles, one is not a copy of the other).

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20090727 Shredder/3.0b4pre.

I don't know if it matters, but I've never had lightning installed in my profiles, but they both are upgrades from 2.0 profiles.

You tried it as .eml file?

Correct, I saved the file from the bug and double-clicked on it to replicate your experience.

I just experienced this issue with TB 3.0b2 and then b4 (tried the upgrade to see if it'd help). I'm on Mac OS X 10.4. The profile used to be in use on TB2... so it looks like it is related to that. I don't recall having lightning installed - it certainly is not installed now. Are there any steps I could take to narrow down what the issue is? It seems like something one would want fixed before 3.0 is released --> requesting blocking3.0 for that reason -- attachments are just invisible, and it'd be better if it was at least an attachment or even visible as plaintext inside the email...

The steps I'd start with would be:

* reduce the testcase to something more obvious, like just the text "I'm the text/plain part" "I'm the text/html part" "I'm the attachment description" to be sure that everyone will know what they are seeing

* make sure it's a regression - when I open the .eml in 2.0, I see the same thing I see in 3.0 - and if it is find the one-day window, which will do more good than anything else possibly could

* make sure whether it's associated with having used a profile in 2.0, or with having updated from 2.0, or both, or neither: does a new profile on 3.0 do the same? does a fresh install of 3.0b4 do the same? does a new profile created by the fresh install do the same? does it actually require having installed Lightning (in 2.0, or in 3.0? a particular version of Lightning?)?

* see whether it's Tb-only, or the same in a comparable build of SeaMonkey

Given reproducibility issues, we can't block on this bug as it stands today. Please follow the suggestions in comment 11, and, once those issues are sorted out, if it still seems like it should be a blocker, please renominate. Thanks!

Possibly related but perhaps not.

Even in the sample email that was submitted the message can be opened viewed and all the invite information is present. It's not "lost". Question I have is more that the invite correctly interpreted and displayed in the message offers no interface (that I see) where you could save or run the invite against an external calendar.

For example here on OSX I expected to see a .ics or calendar attachment that I could save to my desktop. But that option doesn't exist instead if I wanted to enter this information into iCal I would have to manually create the invite.

This seen via TB3B4, fresh install no addons or anything. I do see the same behavior in TB2 so (OSX again) I'm wondering if this is by design? Is this a ''bug'' or an interface design decision? Should I be able to save/view/ download the Calendar information from a message?

Assumption is that the same logic that interprets 'text and html' and doesn't provide and interface for "saving the Text Version" of a the original email and doesn't display a multipart message with text and html versions as having attachments is what 'hides' you from being able to save a calendar invite?

(mind you if this is seen entirely off topic from this posted bug let me know and I'll take my thoughts elsewhere)

(In reply to comment #13)
> (mind you if this is seen entirely off topic from this posted bug let me know
> and I'll take my thoughts elsewhere)

I believe your problem is described in bug 242937 - this bug is about not seeing anything (so not even seeing the ICS data in the email text itself).

Created attachment 405560
Reduced test case of email containing VCAL

Attaching reduced testcase.

Per comment 11, confirmed that this behavior is not a regression, the same behavior exists in Seamonkey, Tbird 2, and Tbird3; it exists in clean profiles or upgraded profiles.

Lightning is not installed, nor has it been installed in prior versions either.

I played around with the .eml quite a bit, and essentially the VCAL doesn't show as text as long as the attachment type is text/calendar. Messing with that at least allows the text to show, but clobbers the actual message text.

Removing regression. Can we mark this dataloss since there is no practical way in the standard UI interface to retrieve the data in the message short of saving the email as a file and cutting out the VCAL information manually (or is that considered a reasonable workaround)? Half the time, I don't know the VCAL is there to go retrieving it from the message source....

I'm surprised that if Tbird doesn't understand the application type it doesn't at least just display it as an (unknown) attachment. It would be reasonable to at least just save the meeting.ics as a standard text file....

First, I'm glad I'm not the only one seeing this bug.

Without looking at the code (I'll be doing that shortly), my hypothesis is that Thunderbird only displays one text/* multipart MIME part, and Outlook invitations are sent with text/plain, text/html and text/calendar. The code needs to be changed to "teach" Outlook that text/calendar should be presented as a file attachment, not "ignored" when displaying the text/html or text/plain.

Now, to see if I can come up with a fix ...

27 comments hidden view all 152 comments

I believe Bug 505024 is a duplicate of this bug, but it has seen a bit more detailed investigation.

28 comments hidden view all 152 comments

Just thinking out loud ... it looks like src/mailnews/mime/src/mimemalt.cpp:MimeMultipartAlternative_display_part_p might be a starting point for the fix for this bug.

As an aside, won't line 255 return in a memory leak as *ct isn't PR_FREEIF'ed?

27 comments hidden view all 152 comments

Keith this might have been fixed by bug 351224. Could you take a few minutes and download the latest nightly ( http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-comm-central/ ), backup your profile and test and let us know if this is fixed or not ?

28 comments hidden view all 152 comments

*** Bug 646779 has been marked as a duplicate of this bug. ***

27 comments hidden view all 152 comments

I still have this problem using Thunderbird-3.1.10

Actually, once I uninstalled the old Lightning add-on, the problem disappeared...

I wish, Lightning actually worked with modern Thunderbird, but that's another story.

The problem we are experiencing at work is the Exchange server generates the text/html and text/plain alternates for calendar event invitations and these alternatives are blank!

...<meta name="Generator" content="Microsoft Exchange Server">

Since Thunderbird without Lightning will ignore text/calendar, it correctly displays this blank html message.

So i recommend that if Thunderbird sees text/calendar that at least it tells the user there is a preferred format. This gives the user the option of installing extensions. This could probably be added generically for any type of file.

BTW, with the Lightning extension, the text/calendar alternative is displayed and appears to be working fine.

(In reply to comment #10)
> The problem we are experiencing at work is the Exchange server generates the
> text/html and text/plain alternates for calendar event invitations and these
> alternatives are blank!

Really, that sounds like an Exchange bug, since it's essentially lying by providing a blank part as an "alternative". However, this can be worked around via bug 602718. Personally, I think that's sufficient, since Exchange really needs to get their act together in this regard, and there's only so much that other clients should have to do to accommodate its broken behavior.

Actually, often the alternative is NOT blank.
It is used by Outlook to display comments that accompany the invitation.

In this specific case, I suggest this kind of mails (even if they arguably do not conform to all standards, as Microsoft occasionally does) should not be handled as multipart/alternative but rather as multipart/mixed.

Changed in seamonkey:
importance: Unknown → Wishlist
status: Unknown → Confirmed

I cannot modify the status, but I find it strange that a regression from a user's standpoint (not being able to see when you are invited to a meeting, while it was possible in earlier versions of mozilla) has importance "enhancement". For a user, this is a regression bug.
I cannot modify the importance. Who judges ?

22 comments hidden view all 152 comments

I just wanted to mention that I'm having the same issue with Thunderbird 9.1 on Mac OS X 10.7.

Correction Thunderbird 9.0.1.

All of attached mails is multipart/alternative and text/plain, text/html, text/calender part are contained in it. Because of multipart/alternative, any part in it is ALTERNATIVE each other. Where can we see ATTACHMENT in multipart/alternative?

To see this special part in malformed mail as if attachment, two ways are currently available.
(i) Lightning extension shows this text/calender as if attachment.
     (broken by Tb 8, but will be fixed by Tb 10. see bug 713380)
(ii) View/Message Body As/All Body Parts,
     with mailnews.display.show_all_body_parts_menu = true
     (implemented by Bug 602718. available since Tb 8)
     In order to see any part, any multipart/xxx is treated as multipart/mixed,
     and any part is shown as if attachment at attachment pane.

Similar malformation is seen in multipart/related which was perhaps originally born by MS. Bug 674473 is for such malformed multipart/related case.
By that bug, "non-referred part and non-displayable part in malformed multipart/related" will be shown as if attachment.

Similar enhancement will be needed in case of wrong use of multipart/alternative by some mailers and some mail systems of some companies who don't respect mail RFC.
  - Limit application of "alternative" to mime part which Tb knows only.
    Apply to text/plain, text/html, and some predefined text/xxx only.
  - Show any other part as if attachment at attachment pane.
I believe this is natural enhancement if mail like next.
    text/plain, text/html, application/pdf, audio/wav, video/x-mpeg
  In this case, any part can be actual/valid ALTERNATIVE, because PDF version
  of mail, voice version of mail, video version of mail is possible.
  Even if Tb can render text/plain or text/html only, I believe audio/wav etc.
  is better shown in attachment pane for user's convenience.
And, "doesn't choose single part only" and "doesn't ignore other parts than part of mail sender's highest preference order" is never RFC violation by Tb.

This enhancement can do nothing for "reversed order in multipart/alternative" case. I think reversed order case is far rare than "text/calender in multipart/alternative" case and is relieved by View/Message Body As/All Body Parts. However, enhancement like next, partially ignore "mail sender's preference order", is better for multipart/alternative.
  - When View/Message Body As/Original/Simple HTML, search text/html part only.
    If only text/plain is contained or if text/html part is null/blank,
    use text/plain part.
  - When View/Message Body As/Plain Text, search text/plain part only.
    If only text/html is contained, or if text/plain part is null/blank,
    use text/html part and convert it to Text.

23 comments hidden view all 152 comments

Duping this to the bug where I'm fixing the issue (and which has test cases).

*** This bug has been marked as a duplicate of bug 505024 ***

Changed in seamonkey:
status: Confirmed → Invalid
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in seamonkey (Ubuntu):
status: New → Confirmed
95 comments hidden view all 152 comments

(In reply to Wayne Mery (:wsmwk, use Needinfo for questions) from comment #94)
> Neil won't be replying in the next several months. So to move this foward we
> have proposals in Neil's comment 80, 81 and comment 82. Ben, what is your
> opinion of Neil's proposals?

I know it wasn't addressed to me, but I think it sounds like a good proposal.

I would prefer a variation on comment 77, but instead of displaying as plain text, display the keyword-value pairs as an HTML table.

I found using mailnews.display.show_all_body_parts_menu (comment 81) to be totally unacceptable. I started using lightning as the workaround just to get the displays right.

But the solution expressed in comment 80 - comment 82 is certainly preferable to nothing being done.

*** Bug 760412 has been marked as a duplicate of this bug. ***

ITs all very well closing other bugs as duplicates of this bug, but if this bug is being progressed then they all might as well be closed....including this one. Otherwise effectively its saying "Save wasting your time. Yeah, we know about this problem. We are not going to deal with it and dont need you telling us about it loads of times."

Comment 80 and 81 dated 7th May 2015 (1 year ago) and no progress since. And the whole bug report approaching its SEVENTH birthday!

Yes, Im frustrated. Sorry.

...if this bug ISNT being progressed*

In case somebody needs a simple workaround just to deal with the very occasional Outlook user, here's what I did:

1. View message source; scroll down to "Content-Type: text/calendar" section
2. Copy the block of base64 text and decode it. (On Linux, I use base64 -d; there are also online decoders like https://www.base64decode.org/ ).
3. Save the resulting text (should start with "BEGIN:VCALENDAR" and end with "END:VCALENDAR") into a file. E.g., event.vcs.
4. Open up Google Calendar. In the left margin, click on the "Other calendars" menu and pick "Import calendar."
5. Select your file and click "Import". It should say, "Processed one event. Successfully imported one event."

After that, you should have the event on your calendar. This definitely isn't optimal, but it seems better than having to email back a client and ask them to send you details in plain text.

"After that, you should have the event on your calendar. This definitely isn't optimal, but it seems better than having to email back a client and ask them to send you details in plain text."

Is it??!

As I thought was obvious, I mean that it seems better to me. If it isn't better for you, I will gladly offer you a full refund on your purchase price.

Im concerned that offers of 'workrounds' (however short or long-winded) being posted on this bug report page only serves to further delay any potential real fix to the problem that MIGHT just be in the offing. (Sort of a "oh look, it doesnt stop the show because there is something they can do without it so we will lower the priority even more" sort of thing). I know it shouldnt, but given we are approaching 7 years old with no solution on the horizon, it is easy to understand why such a concern should be had. (Even proposals - comment 79 and onwards - just have "yes, I agree"'s yet no one willing to commit or progress).

(BTW, Im afraid your offer of the *simple* workround or even the virtual refund doesnt apply to me - Ive had to find a different solution due to lack of this functionality. I would have really struggled to try to explain to 'Mary, in Accounts' and all the other users about "content-type's" and "base64 decoding") :-)

I'm exactly none of the developers, but I find your sense of entitlement offputting here. If you'd like things to worry about, you might try worrying that being demanding toward people who you are not paying and who are often volunteers might delay them working on this. In favor of, say, something where they get to deal with pleasant people, or just something they find personally rewarding.

On my part, all I did was try to help, and I've gotten two grumbly emails from some internet rando. So you've certainly convinced me that trying to help here is a bad idea.

As a developer who's worked on this area of the code (but unfortunately has no time to delve back into libmime at the moment), I can assure you that workarounds posted here have no bearing on the schedule for fixing this.

I may look into this when we're further along the process of migrating from libmime to jsmime, but probably not before then. Any significant improvements to libmime would be lost once we switch to jsmime for everything, and I'd prefer to spend my limited time on improvements that will last.

Hi Jim Porter.

I have recently done some other bug-fixes to libmime and the handling of multipart/alternative massages, and I was pondering if I should try to fix this bug.

You said in an earlier comment that you could be willing to mentor and point in the right direction.
So, please, any pointers would be welcome. Where should I start to look in order to fix this bug?

Terje B.

If I were you, I'd take a look at the existing patches, (especially the last two by Neil) and see how they work. They might already do what we need, but some tests would be nice.

*** Bug 1295965 has been marked as a duplicate of this bug. ***

*** Bug 687063 has been marked as a duplicate of this bug. ***

*** Bug 582251 has been marked as a duplicate of this bug. ***

*** Bug 342443 has been marked as a duplicate of this bug. ***

*** Bug 1003241 has been marked as a duplicate of this bug. ***

*** Bug 242937 has been marked as a duplicate of this bug. ***

Terje, are you still interested, we could fix this ancient old bug. Without looking I'd say that Neil's patches don't apply any more since you've made changes in mimemalt.cpp.

BTW, I got here via Neil's review queue.

Comment on attachment 8600315
Hack to display it as plain text

I don't think you're going to get this review :-(

In *HTML* view in a TB 53 Daily attachment 405560 looks very nice, the last part is displayed: Content-Type: text/calendar. For attachment 389696 also the last part Content-Type: text/calendar is displayed.

In both case one clearly sees that there is an attachment. This was most likely already fixed by Terje in bug 574989. I remember he added text/calendar here:

In plaintext view there is no attachment shown.

Terje, can we improve this further?

Hi Jorg.

I am sorry, but I am busy with work related stuff now.
It might be some time before I will look at this again.

I highly recommend that some one else looks at it, because I might never get around to it.

Kind regards

Terje B.

Oli Wade (olithered) on 2017-01-27
Changed in seamonkey:
importance: Wishlist → Unknown
status: Invalid → Unknown
Changed in seamonkey:
importance: Unknown → High
status: Unknown → Confirmed

I'm coming back to this bug after fixing bug 1334937.

Looking at attachment 389696 and attachment 405560.
With Lightning installed, both show the invitation.
With Lightning disabled, both show the HTML part.

Looking at the messages they have three parts:

With Lightning not installed, the text/calendar part is not displayable, see bug 1334937 comment #39.

So I guess you can't have it both ways: Bug 1334937 wanted to see the HTML part and this bug here wants so see an attachment where there isn't one.

The test message from bug 1334937, attachment 8832838, is different. It has those three parts *and* it has a .ics attachment, and that shows, with or without Lightning.

The previous comments show that Lightning is distrusted.

There are a few issues here. The first is that when using mulitpart/alternative, one uses the preference order of the sender in the order that the receiver understands. Thus, in your example, you act on text/calendar if you understand text/calendar, and otherwise move up the list to text/html.

The challenge here is that I don't believe the standard matches the user's expectations, particularly when lightning isn't installed. In particular, the user may wish to view the appointment *and* "double click" on it to hand it off to a handler for Outlook or iCal.


Bug 1334937 comment #46 explains that when you have three parts
and *no* ICS attachment, the difficulty is to display the third usually hidden part additionally or as attachment. RFC 1521 says:
  Receiving user agents should pick and display the last format
  they are capable of displaying. In the case where one of the
  alternatives is itself of type "multipart" and contains unrecognized
  sub-parts, the user agent may choose either to show that alternative,
  an earlier alternative, or both.

This seems really a bug in Microsoft Exchange, not a bug in Thunderbird. However, since so many people send out event invitations via Exchange, it seems other MUAs have added special-case algorithms to deliberately violate the MIME specification if the sender was MS-Exchange and show multiple multipart/alternative parts simultaneously if one of them is an ICS calendar and the others are text/plain or text/html.

The problem is that Exchange sends out calendar invitations as

Example A:

- multipart/alternative
  * text/plain
  * text/html
  * text/calendar

even in cases where the text/plain and text/html parts are empty, or otherwise are no legitimate representation of the same information as the calendar file (e.g., just a human written cover message).

In an ideal world, where Microsoft respected Internet standards, Exchange would instead have sent out

Example B:

- multipart/mixed
  * multipart/alternative
    o text/plain
    o text/html
  * text/calendar

This way, the client would always display either the plain-text or HTML cover letter (which presumably are just alternative renderings of exactly the same information), plus show below that the ICS file as a proper attachment.

But since Exchange sends out so many inappropriate Example A messages, it may be worthwhile to add circumvention code. Thunderbird could detect the structure of Example A and convert it into the structure of Example B before displaying it. That transform can be made conditional to the presence of header fields (such as
regular expression /^x-ms-exchange-/i), such no messages sent my non-Microsoft products are affected.

I can forward example messages.

Regarding Comment 122, one of the use cases here is really quite simple: we want to be able to link a MIME handler to a text/calenar message. That is what Bug 301441 was requesting lo those many year ago (marked a duplicate of this one). And so it's not just a matter of whatever exchange bug might exist. At the time, and I don't know if it has changed, it was not possible to register a MIME handler in the UI.

Could it be that this bug is also related o that https://bugzilla.mozilla.org/show_bug.cgi?id=1396754 is a duplicate of this but with groupwise instead of exchange?.

The Calendly.com scheduling service is affected by this problem.

It's not helpful to decry that there exist implementations that are not spec-compliant. If the reality is that this issue is so widely deployed as to be defacto standard, then it needs to be treated as such. (That said, I'm not entirely convinced that it's a violation of the standard—the e-mail is essentially saying that text/calendar is the preferred format of the message, and text/html and text/plain are provided as the fallback. The bug in the sender, then, is that these other formats don't have all the details that the text/calendar message has.)

Thunderbird should be updated, if not to support the calendar item wholesale (since Thunderbird doesn't have a built-in calendar), at least know enough to convert it to an ICNS attachment that can be downloaded and used by an actual calendar app.

Regarding Comment 125, This is a very old bug indeed. For it to close, someone would actually have to want to work on it. If you are willing to work on it, great.


during the last year I have been faced with the same problem that Outlook appointments are not shown in my Thunderbird. As I did not want to use Lighting I spent some spare time during the Christmas holidays to hack together a small addon which shows a button in the message window when an outlook calendar part is being detected.

I have no experience in creating Thunderbird addons nor did I dive deep into the documentation. I learned from existing addons and put together something that works. I would be happy if someone could review and improve / rewrite the code.

The addon works for me, but I also did not that much testing. Before I wanted to publish this addon it would be nice if some more people could test it with more than my five test messages and only my Thunderbird installation.

You find my addon here: https://github.com/sebastianha/sfoa

Let me know your thoughts, create comments and merge requests.

Regards, Sebastian

I've visited this bug far too many times :-( - So let's try a summary.

Attachment 389696 has a multipart/alternative structure

The so-called "reduced" (not!) test case in attachment 405560 has:
but there is no further "mixed" part :-(

TB with Lightning shows the invitation, TB without Lightning shows the HTML part, no indication of any attachment since for an attachment we need multipart/mixed with the attachment in a "mixed" part.

Nothing new here, already explained in comment #122 (!!).

Now the add-on, I got this version:
I briefly browsed the code (being an add-on reviewer as well) and it all looks good at first glance. It overlays the expandedHeadersBottomBox to display a "Download ICS" button. Somehow it doesn't work, I don't see the button using the test messages here.

If you can make it work, great, submit it at addons.thunderbird.net. Drop a comment here and I'll review/approve it. Thanks for your contribution ;-)


thanks for your comments, I have to admit that I did not test with the attached mails here as I thought these kinds of appointment invitations are obsolet. I did only test with a recent one I got from a colleague.

However, please check v0.2.1 which should now support all three types of known outlook invitations (my sample and the two
 attached here). All sample I used for testing are in the "samples" folder.

There might be encoding issues in the VCAL-file itself in some fields but at least it should be able to import into a calendar.

Regards, Sebastian

Yes, that works fine. You need to know that you have to use Customise to place the button. You can submit this at ATN and let me know when it's ready so I can approve it. PM is OK. In general I'm a Lightning user, so it's not to terribly useful for me. That said, we have a long-standing issue that Lightning can only handle one attached event, bug 547754. Can your add-on save more than one? Or does Outlook only ever send one. For multipart/alternative, multiple text/calendar parts are imaginable.

Good to hear! I will submit the addon soon and let you know.

The hint for the button is quite hidden but inside the Readme. I added another when within the "Installing" section. I could not figure out a way to add a button which is not fixed but visible right after installing. Can anyone help me with this?

Currently it will only handle only one (the first found) calendar event. I do not know if its possible to send multiple appointments in one mail, I will ask a colleague which is using Outlook.

*** Bug 1521050 has been marked as a duplicate of this bug. ***

Installed the addon but still no joy. I'll look out for further updates on this bug.

if you like send me an email or open a bug on github: https://github.com/sebastianha/sfoa
Perhaps we can find a solution, until now I only a small sample of test messages. It could be that the message is not being detected correctly.
Regards, Sebastian

Displaying first 40 and last 40 comments. View all 152 comments or add a comment.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.