Closed Bug 1666296 Opened 4 years ago Closed 3 years ago

Microsoft Teams invitation link not supported

Categories

(Calendar :: General, defect, P1)

Product:
Calendar
Component:
General
Version:
Thunderbird 81
Type:
defect

Tracking

(thunderbird_esr78 unaffected, thunderbird88+ fixed)

Status:
RESOLVED FIXED
Milestone:
89 Branch
Tracking Flags:
Tracking Status
thunderbird_esr78 --- unaffected
thunderbird88 + fixed

People

(Reporter: thedonpedro, Assigned: mkmelin)

References

(Regression)

Details

(Keywords: regression)

Attachments

(3 files, 4 obsolete files)

sanitized2.eml
16.74 KB, message/rfc822
Details
Problematic meeting invitation - ICS file
2.18 KB, text/calendar
Details
Bug 1666296 - Properly show descriptions in Teams invites. r=darktrojan
48 bytes, text/x-phabricator-request
wsmwk
: approval-comm-beta+
Details | Review

User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.83 Safari/537.36 OPR/71.0.3770.97 (Edition beta)

Steps to reproduce:

Received an invitation to a Microsoft Teams meeting in e-mail (probably directly from Outlook.com, definitely from a Microsoft ecosystem, actual user agent couldn't be determined).

Actual results:

The event was displayed without any hint about the Teams URL which is required to join the meeting. Couldn't join the meeting.

Expected results:

The client should provide a way to get the meeting URL (X-MICROSOFT-SKYPETEAMSMEETINGURL in iCS) somehow.

  • preferred: have complete support the Teams-specific URL and show it when available
  • at the very least provide a way to save the ICS for events already caught by Lightning/Calendar (no way to save attachments for invitations)
  • or as an imperfect but useful alternative provide a built-in ICS viewer for all similar needs

Can you attach a sample invitation as .eml?

Attached file sanitized.eml (obsolete) —

Hi Magnus, I have the same issue also on TB 80.0b2. I attach here a real email with Microsoft Teams meeting link. I have deleted all sensitive information. Let me know if the testcase is enough.
Thanks.

I see a "join meeting" link in there (on trunk at least)

Attached image ii.png (obsolete) —

Nothing change for me also after installing TB nighty (83.0a1): I don't see any meeting link (OS is Windows 10).

To clarify, for that message I don't see a calendar invitation at all, just an html view with the link. Maybe you removed too much?

Attached file sanitized2.eml —

ah sorry ok. Yep, you have right, I have only leave the html part with the meeting link that is not dispayed in TB (you can see it if inspect the source of the email). Anyway I attach here another email with the calendar event. Tell me if this is enough.
Thanks!

Attachment #9181515 - Attachment is obsolete: true
Attachment #9181529 - Attachment is obsolete: true

Yeah I can reproduce with that. Decoded it is:

BEGIN:VCALENDAR
METHOD:REQUEST
PRODID:Microsoft Exchange Server 2010
VERSION:2.0
BEGIN:VTIMEZONE
TZID:W. Europe Standard Time
BEGIN:STANDARD
DTSTART:16010101T030000
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=10
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T020000
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=3
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
ORGANIZER;CN=Barbara Farina:mailto:barbara@rconsultingsrl.onmicrosoft.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=d.zanloren
 zi@edigit.it:mailto:d.zanlorenzi@edigit.it
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Giovanni.G
 abbi@tikappapi.com:mailto:Giovanni.Gabbi@tikappapi.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=p.dante@ed
 igit.it:mailto:p.dante@edigit.it
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=f.veraldi@
 edigit.it:mailto:f.veraldi@edigit.it
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Raffaello.
 Venturelli@tikappapi.com:mailto:Raffaello.Venturelli@tikappapi.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=bruno.pisa
 ni@tikappapi.com:mailto:bruno.pisani@tikappapi.com
DESCRIPTION;LANGUAGE=en-US:\n\n\n__________________________________________
 ______________________________________\nPartecipa alla riunione di Microso
 ft Teams<https://teams.microsoft.com/l/meetup-join/19%3ameeting_MmQ0MjI1Zj
 MtMjE0Yi00ZTY4LThmYmMtZmY3NmUzMDMyOWQ2%40thread.v2/0?context=%7b%22Tid%22%
 3a%225d08b37c-b698-400d-b333-9e8b32140464%22%2c%22Oid%22%3a%227bc64f55-9f3
 5-46ea-8ea3-fa03d7c84914%22%7d>\nUlteriori informazioni su Teams<https://a
 ka.ms/JoinTeamsMeeting> | Opzioni riunione<https://teams.microsoft.com/mee
 tingOptions/?organizerId=7bc64f55-9f35-46ea-8ea3-fa03d7c84914&tenantId=5d0
 8b37c-b698-400d-b333-9e8b32140464&threadId=19_meeting_MmQ0MjI1ZjMtMjE0Yi00
 ZTY4LThmYmMtZmY3NmUzMDMyOWQ2@thread.v2&messageId=0&language=it-IT>\n______
 __________________________________________________________________________
 \n
UID:040000008200E00074C5B7101A82E0080000000019B0CEB819A2D601000000000000000
 010000000331AB190FE0AEA4F880C87A5D13AB432
SUMMARY;LANGUAGE=en-US:Formazione sulla Leadership-Consapevolezza
DTSTART;TZID=W. Europe Standard Time:20201015T140000
DTEND;TZID=W. Europe Standard Time:20201015T180000
CLASS:PUBLIC
PRIORITY:5
DTSTAMP:20201014T110401Z
TRANSP:OPAQUE
STATUS:CONFIRMED
SEQUENCE:0
LOCATION;LANGUAGE=en-US:
X-MICROSOFT-CDO-APPT-SEQUENCE:0
X-MICROSOFT-CDO-OWNERAPPTID:2118808857
X-MICROSOFT-CDO-BUSYSTATUS:TENTATIVE
X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY
X-MICROSOFT-CDO-ALLDAYEVENT:FALSE
X-MICROSOFT-CDO-IMPORTANCE:1
X-MICROSOFT-CDO-INSTTYPE:0
X-MICROSOFT-SKYPETEAMSMEETINGURL:https://teams.microsoft.com/l/meetup-join/
 19%3ameeting_MmQ0MjI1ZjMtMjE0Yi00ZTY4LThmYmMtZmY3NmUzMDMyOWQ2%40thread.v2/
 0?context=%7b%22Tid%22%3a%225d08b37c-b698-400d-b333-9e8b32140464%22%2c%22O
 id%22%3a%227bc64f55-9f35-46ea-8ea3-fa03d7c84914%22%7d
X-MICROSOFT-SCHEDULINGSERVICEUPDATEURL:https://scheduler.teams.microsoft.co
 m/teams/5d08b37c-b698-400d-b333-9e8b32140464/7bc64f55-9f35-46ea-8ea3-fa03d
 7c84914/19_meeting_MmQ0MjI1ZjMtMjE0Yi00ZTY4LThmYmMtZmY3NmUzMDMyOWQ2@thread
 .v2/0
X-MICROSOFT-SKYPETEAMSPROPERTIES:{"cid":"19:meeting_MmQ0MjI1ZjMtMjE0Yi00ZTY
 4LThmYmMtZmY3NmUzMDMyOWQ2@thread.v2"\,"rid":0\,"mid":0\,"uid":null\,"priva
 te":true\,"type":0}
X-MICROSOFT-ONLINEMEETINGCONFLINK:conf:sip:barbara@rconsultingsrl.onmicroso
 ft.com\;gruu\;opaque=app:conf:focus:id:teams:2:0!19:meeting_MmQ0MjI1ZjMtMj
 E0Yi00ZTY4LThmYmMtZmY3NmUzMDMyOWQ2-thread.v2!7bc64f559f3546ea8ea3fa03d7c84
 914!5d08b37cb698400db3339e8b32140464
X-MICROSOFT-ONLINEMEETINGINFORMATION:{"OnlineMeetingChannelId":null\,"Onlin
 eMeetingProvider":3}
X-MICROSOFT-DONOTFORWARDMEETING:FALSE
X-MICROSOFT-DISALLOW-COUNTER:FALSE
X-MICROSOFT-LOCATIONS:[]
BEGIN:VALARM
DESCRIPTION:REMINDER
TRIGGER;RELATED=START:-PT15M
ACTION:DISPLAY
END:VALARM
END:VEVENT
END:VCALENDAR
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P1

This is obviously not isolated only to MS Teams invitations. It seems that HTML formatting is not currently supported in calendar events description, hence the formatted links (URLs) are removed. Fix for that would be to convert links at least to plain text to preserve the URL until full support for HTML format is provided in Lightning.

(In reply to Marek Sajner from comment #11)

This is obviously not isolated only to MS Teams invitations. It seems that HTML formatting is not currently supported in calendar events description, hence the formatted links (URLs) are removed. Fix for that would be to convert links at least to plain text to preserve the URL until full support for HTML format is provided in Lightning.

That already happens in "old" Lightnings: URLs are turned into text.
A proper solution is to enhance the UI to include a way to join a meeting with the click of a mouse.
Adding a "Join meeting" context menu, or button or whatever can be done without supporting HTML in calendar event descriptions.

See Also: → 1666452

(This isn't affecting 78.)

Assignee: nobody → mkmelin+mozilla
Keywords: regression
Regressed by: 1659363
Version: Thunderbird 78 → Thunderbird 81

I have both cases in which the link is not shown in the invitstion (and event) and one in which it works. The latter was sent via the Google calendar and not via Outlook. The difference is that the Outlook links do IMO not follow HTML rules, but I'm a bit rusty...

Outlook:
Click here<http://.....

Google:
Click here<a href=http://...

The outlook variant results in only the plain text "Click here", the Google variant produces a clickable link.

Hello. Thanks for working on this. Running 86.0b1 here and the problem seems to be that Teams saves links in the DESCRIPTION field surrounded by left and right angle brackets (<) and (>). If you remove those brackets manually, the link is recognized correctly.

This seems strongly related to bug 1659363. I reported this there initially with some more details.

Interestingly the main email window of Thunderbird already handles that scenario correctly. Whether your email contains <www.google.com> or www.google.com it always recognizes the link and just ignores the brackets.

...
DESCRIPTION;LANGUAGE=en-US:\n\n______________
__________________________________________________________________\nMicros
oft Teams-Meeting\nJoin on your computer or mobile app\nClick here\,
to join the meeting<https://teams.microsoft.com/l/meetup-j
oin/19%3ameeting_ODFmOGFmMGItZjA3OC66MGVjLTllMzItNDNmM2QxNzViOTg1%40thread
.v2/0?context=%7b%22Tid%22%3a%222f1bf2a7-730e-4228-82d5-440fbfcb419a%22%2c
%22Oid%22%3a%229a3157f6-b6ff-4f1b-894d-baf81555bfb0%22%7d>\n ...

This is a critical issue that is still affecting 86.0b2 (64-bit) I just upgraded to...

It really needs to be resolved before the next ESR... A lot of people use Teams now a days especially in the covid19 context...

It is really handicapping not to be able to access the Teams link to join a meeting...
Indeed all you see in the invite is the text below... with no active link to click, nor the link available as a text path you can copy paste... you just simply cannot access any links in the invite!

Microsoft Teams meeting
Join on your computer or mobile app
Click here to join the meeting
Learn more | Meeting options

So you simply cannot join a Teams meeting from Thunderbird. You need to get the link via another email client software... a real pity!!!

Flags: needinfo?(bugzilla2007)

(In reply to Magnus Melin [:mkmelin] from comment #14)

(This isn't affecting 78.)

but bug 1676040 is (also a regression) - both need quick(er) action.
Magnus, are you actively working on this, or both?

Severity: -- → S2
Flags: needinfo?(mkmelin+mozilla)

(In reply to Richard Leger from comment #17)

This is a critical issue that is still affecting 86.0b2 (64-bit) I just upgraded to...
It really needs to be resolved before the next ESR...
So you simply cannot join a Teams meeting from Thunderbird. You need to get the link via another email client software... a real pity!!!

+1. We must fix it, and it is going to be fixed. Priority is on P1. Everybody on the team is doing their best, but there's a lot to do.

If anyone can suggest a patch, most welcome!

Flags: needinfo?(bugzilla2007)

From a cursory look at code implemented by Bug 1659363 to render HTML in event descriptions:

Hey Ben, any idea why html = gTextToHtmlConverter.scanHTML(text, mode); (l. 387 or l. 390) seems to fail to convert <http...> into <a href...> but instead just removes the whole <plaintext link>? Is that what happens?

https://searchfox.org/comm-central/rev/8731bf11d5bbc15d770078def50db63b297061f1/calendar/base/modules/utils/calViewUtils.jsm#362-404

Flags: needinfo?(ben.bucksch)

I can only guess, but I think there's a space missing between "here" and "<http". The text recongnizer recognizes here http://foo there and here <http://foo> there, but cannot recognize here<http://foo>. No human writes here<http. Remember that the recognizer does heuristics for normal plaintext.

Given that some stupid software seems to output this malformed plaintext: The quick and dirty fix is to simply replace all "<http" with " <http", before recognizing. That should be a 1-line fix, in the right place, where the ICS plaintext is parsed, before sending it to scanHTML().

The real fix is not to use that plaintext, but to use the original HTML. As it happens, we (Beonex, my company) are working on that right now, to make Lightning properly support HTML descriptions from start to finish. We plan to be contributing that to TB/Lightning trunk, in bug 1607834.

Thanks, Thomas D, for ccing me on this. I'm happy to help here.

Flags: needinfo?(ben.bucksch)

Aureliano wrote:

I have deleted all sensitive information.

Actually, you have not. It was still in the last attachment part, in the actual ICS file, just base64 encoded. I could see everything. I have tried to delete the email addresses and Teams link ID, and saved only the ICS.

Attachment #9181531 - Attachment is obsolete: true

Fix would be to add:

text = text.replace(/([^ ])(\<http)/g, "$1 $2");

or something similar to calViewUtils.jsm textToHtmlDocumentFragment().

Example text:

let text = "click here<https://foo> or there <https://bar>"
text = text.replace(/([^ ])(\<http)/g, "$1 $2");
returns: "click here <https://foo> or there <https://bar>"
Attached patch Potential fix, v1 (obsolete) — — Splinter Review

Untested patch (4:30 AM here, too late to start a build etc.). Patch attached in diff form only for completeness and to move this forward.

From the description, this should fix it, though.

Assignee: mkmelin+mozilla → ben.bucksch
Status: NEW → ASSIGNED
Attachment #9203336 - Flags: review?(mkmelin+mozilla)

I can't test this patch out right now but based on my experiments (which are really just base64 decoding the ics part of an email, editing it and encoding it back) this will not fix the problem. Even with a leading space character the link is not recognized when enclosed in right angle brackets.

The plaintext link is not removed either as Thomas suggested - it's still there in the ics DESCRIPTION. It's just not rendered, assumingly because it looks like a (faulty) html tag. Consequently Thunderbird stable (without the html rendering of event descriptions) shows the plaintext mangled together and Thunderbird beta doesn't show the link at all.

Again, thanks for taking this on.

Attachment #9181531 - Attachment is obsolete: false
Attachment #9203336 - Flags: review?(mkmelin+mozilla)

@Paul: Ah, I see what you're saying. The fundamental problem here is the hack that was put in here, to treat plaintext as HTML. That cannot work. So, yes, a https://... would be treated as HTML tag.

The only proper fix is what I said in comment 21: Not treating plaintext as HTML, but cleanly separating them.

The challenge here is that the MIME message structure violates the MIME specs: It's coming down as multipart/alternative, which is defined as: The later parts are better, and the earlier parts are to be ignored. I.e. the earlier parts are only a fallback in case the client doesn't support the format of the last part., and the last part is the real thing and must have all information. In this case, we have a plaintext part, a HTML part, and an ICS file, in this order, as multipart/alternative, which says - per spec: Ignore the HTML part, and use only the ICS file, if you know what an ICS is.

The problem is that the ICS file does not contain HTML. Microsoft itself specced how to put HTML in ICS, but Microsoft itself doesn't do it here. So, if we follow the spec, we have to ignore the HTML and take only the plaintext description. So, the data loss here comes from a spec violation on the part of Microsoft.

The regression bug here arises from the hack that was created in bug 1659363 (and later tweaked in bug 1663947), which treats plaintext as HTML. That cannot work, and goes wrong here, and causes this bug that you (Paul) describe.

  1. The only way out is either revert bug 1659363 or to be more discriminating when to apply that hack, namely only when we're sure it's HTML, and only for the broken senders. That limits the scope of the hack, fixes this bug, and avoids encouraging other clients to do the same nonsense of putting HTML in a plaintext field.

  2. Next step is to properly support HTML descriptions in a separate property. We plan to work on that, in bug 1607834.

  3. Last step would be to make a hack specifically for these broken invitations that have ICS with plaintext only superseeding a (more valuable) HTML description. That is going to be difficult to fix, because it goes against the spec, and is therefore difficult to do in the current software design.

If somebody wants to take a stab at part 1, feel free to attach a patch. I don't want to block anybody.

Assignee: ben.bucksch → nobody
Status: ASSIGNED → NEW
Depends on: 1607834

Hi all,

@Paul, as you may have worked on bug 1659363 maybe you would have some insight about this bug, see Comment 26.

FYI, in TB 86.0b3 (64-bit) in the Teams email invite received, the body of the email message also seems to be plaintext converted into html with no link available. As MS also send the invite in html format text/html, why not to use it directly as body of the email message instead of trying to convert plaintext into HTML?

Is the multipart/alternative interpreted correctly here?
This is use to sent the same content (more or less) in various format: plaintext, html, ics then it is down to the application to pickup and choose properly which part to use to show the data appropriately. "The later parts are better, and the earlier parts" is correct as in the order the plain text part contains less information/feature that HTML which may contains less information that the ics... but it does not mean the application cannot use the HTML format provided, or am I mistaking? You are just given three options here to choose and pickup from as you may see fit you application and purpose.

About the "...and the earlier parts are to be ignored" is not imposed by the RFC... the choice remain yours :-)
"...the multipart/alternative type is syntactically identical to multipart/mixed, but the semantics are different. In particular, each of the parts is an "alternative" version of the same information. User agents should recognize that the content of the various parts are interchangeable. 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 displayed..."

Therefore the HTML part provide by MS in the Teams invite, could be used as body of the email message instead of trying to convert plaintext into HTML from the ICS file... As HTML format is available couldn't be just used as is? At least of the email body... if not as ICS file description :-)

As for the plaintext in ISC, this is by RFC definition. TB is just trying to detect any content (e.g link, html entities) in it and convert it on the fly which is a good thing from a user point of view (but a nightmare from a dev one I reckon), it just need to be a bit more clever at it as per Ben's point 1 in Comment 26...
Unfortunately you cannot prevent sender to add links or HTML code to event descriptions, so you would need to workaround it as best you can... clearly the Teams invite plaintext description does not really contains HTML code per say, just plaintext links, so you cannot just treats plaintext description as HTML in that case... but you would still need to able to convert plaintext links into clickable ones in some way... or at the least show them in plaintext till full support of HTML description would be implemented.

It look like in a way, MS found a clever way to "break" other email client to its own advantage by making it difficult to parse its generated invite content, clearly making TB looking like a "faulty" program from an end-user point of view...

Regards,

Flags: needinfo?(paul)

FYI Paul is not actively working on Thunderbird anymore. (Dunno if he still reads bugmail.)

Anyway, I was working on this bug got sidetracked. I'll upload what I had. Not sure what exact state I left it in, but it needed test fixed and a test at least.

The situation is a bit complex: like it or not, google calendar and likely some others will put html in the description, so we need to treat it as if it's supported. I don't think using any other fields will work really, further complicated by how the invite description data put back to the server should not be changed, AND IIRC custom fields are not supported by Google.

Flags: needinfo?(paul)
Flags: needinfo?(mkmelin+mozilla)
Attached patch bug1666296_teams_link.patch (obsolete) — — Splinter Review
Assignee: nobody → mkmelin+mozilla
Attachment #9203336 - Attachment is obsolete: true

(In reply to Wayne Mery (:wsmwk) from comment #18)

but bug 1676040 is (also a regression) - both need quick(er) action.

That one is 78 only and not a regression,. It only occurs for some special cases. We could do a bandaid for it I think.

plaintext in ICS, this is by RFC definition.

Exactly.

TB is just trying to detect ... html ... in it

That's the bug. It's plaintext, not HTML. If you try to parse it as HTML, it will go wrong. It goes wrong here. That's the bug.

There is a specific property in ICS for HTML, ironically an extension from Microsoft, called X-ALT-DESC, which is for HTML.

That is of little joy if you still can't store custom properties.

need to be a bit more clever at it as per Ben's point 1 in Comment 26...

Agreed. We should parse it only when we're sure that it's HTML. For example, we could check whether we find <html> or <body> at the beginning, or <div> and </div> in the plaintext. But if a HTML developer writes about HTML tags in the event description, we should not parse that description as HTML, so just finding <div> is not sufficient to assume that we have HTML and treat it as HTML.

Also, additionally, we need to make sure that this doesn't become the "new way" of putting HTML in invitations. As mentioned, X-ALT-DESC must be used instead. I'd rather file a bug against Google Calendar. As it is, this is a spec violation.

Otherwise, how do we know whether some web developer talks about HTML in the event description? if we cannot differentiate between plaintext and HTML, we will have plenty more bugs like this coming up in the future. We will never ever be able to fix it properly.

Ben,
As you seems to have some experience, would you be able to test Magnus patch as per his Comment 30?
That may be a workable solution in the short term... or you may be able to adjust it further with your suggestions to make it work?

Magnus,
As for the long term... why trying to convert plaintext into html if the html version of the event is already provided?

(In reply to Magnus Melin [:mkmelin] from comment #29)

I don't think using any other fields will work really

In a Teams invite, there are three attachments received in the multipart/alternative MIME section:

  • a plaint text one
  • an html one
  • an ICS one (with the plaintext description that TB try to convert to HTML)
Content-Type: multipart/alternative;
(...)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
(...)
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<html>
(...)
</html>
(...)
Content-Type: text/calendar; charset="utf-8"; method=REQUEST
Content-Transfer-Encoding: base64
(...)

So for invite that contains an HTML attachment, couldn't you use the HTML attachment body content directly in addition of the ICS one?

  • to set the body of the invite email message when displayed in TB
  • to set the X-ALT-DESC field within the ICS item - for re-using later when the event is read within the calendar - iCalendar being a plaintext format it should not be hard to add the field in, set its value and store it as plaintext for later re-use as Description when event is read...

"...X-ALT-DESC shall be used to include HTML markup in an event's description. Standard DESCRIPTION tag should contain non-HTML version display the description (when reading the event not editing it)..." Source: https://en.wikipedia.org/wiki/ICalendar

Considering that invites such as Teams. Zoom, etc... are only read and not edited (TB does not allow edit of such events) it should not be an issue to reuse the HTML content provided if it exists already in the invite received... assuming you can re-use it...

In the future a new STYLED-DESCRIPTION property may be introduced in the next iteration of the iCalendar standard. This new property will provide in theory for one or more rich-text descriptions to replace that provided by the DESCRIPTION property. Source: https://datatracker.ietf.org/doc/draft-ietf-calext-eventpub-extensions/?include_text=1

In a similar way I just noticed that Zoom invite emails body content appears empty after accepting the event :-(
All I see is this message contain an event that has already been processed with a Details... button. Why can't the event content still be displayed in the email body at this stage of the process? Likely a separate bug for another day...

why trying to convert plaintext into html

As mentioned, bug 1659363 was trying to fix Google Calendar, and that hack goes wrong here, because the hack was overreaching. The hack was never intended to apply here. The fix is to make that hack specific.

"...X-ALT-DESC shall be used to include HTML markup in an event's description. Standard DESCRIPTION tag should contain non-HTML version display the description (when reading the event not editing it)..." Source: https://en.wikipedia.org/wiki/ICalendar

What I'm saying. The problem is that Microsoft does not use X-ALT-DESC here, even though they themselves invented it.

multipart/alternative MIME section
for invite that contains an HTML attachment, couldn't you use the HTML attachment body content directly in addition of the ICS one?

The multipart/alternative specifically tells us to ignore the HTML part, per spec. Please see comment 26. And the HTML - being an alternative to the entire ICS file, not just the description - MUST include the meeting details (like time, location, invitee list etc.), which we don't want in the description, because it would be repetetive. So, that's the wrong fix.
Also, technically, in the calendar, we don't get the entire email, we get only the ICS to read. And the ICS doesn't have the HTML. If Microsoft wants us to use the HTML description, they need to put it in the ICS.

Also, technically, in the calendar, we don't get the entire email, we get only the ICS to read. And the ICS doesn't have the HTML. If Microsoft wants us to use the HTML description, they need to put it in the ICS.

Why not show on top of the message the ICS part and on bottom the HTML part? It looks like Outlook does this like this.

That's bug 1406868 which I agree we need a solution for as well. But it's another angle really.

(In reply to Ben Bucksch (:BenB) from comment #36)

multipart/alternative MIME section
for invite that contains an HTML attachment, couldn't you use the HTML attachment body content directly in addition of the ICS one?

The multipart/alternative specifically tells us to ignore the HTML part, per spec. Please see comment 26. And the HTML - being an alternative to the entire ICS file, not just the description - MUST include the meeting details (like time, location, invitee list etc.), which we don't want in the description, because it would be repetitive. So, that's the wrong fix.
Also, technically, in the calendar, we don't get the entire email, we get only the ICS to read. And the ICS doesn't have the HTML. If Microsoft wants us to use the HTML description, they need to put it in the ICS.

FYI, in the case of Teams invite, the plaintext attachment and the HTML attachment only contains the Description formatted in plaintext and HTML format respectively, no other information (like time, location, invitee list etc.) about the event that remain only stored in the ICS attachment file. MS intent may be to show any of those two within the body of the email message (or as a fallback in absence of calendar feature able to parse the ICS file - e.g if disabled) and use the ICS file for processing by the calendar feature.

I agree it is a bit strange that MS do not store the HTML version of the description into X-ALT-DESC but that does not mean that TB could not do it on the fly :-)

In a similar way it is a bit silly for MS not to show the link in the plaintext version of the Description as plaintext link... instead they only show the display text of the link without the link itself which is another part of the issue :-)

I tried the patch in Comment 30 but it does not seems to work, though I am not sure if I applied it correctly (though I can see the new line of code via the Debugger) nor if the function applies when you read an event or only when you receive an invite and accept it. Opening an already accepted Teams event from my calendar still show the Description as plaintext without any link (either clickable HTML one, or as a plaintext link). It is quite possible I may have done something wrong also as it is my first attempt at twicking TB on the fly via the hacking: trick https://wiki.mozilla.org/Thunderbird:Start_Hacking so if someone else can give it a try that may be best to confirm.

(In reply to Richard Leger from comment #39)

(In reply to Ben Bucksch (:BenB) from comment #36)
I tried the patch in Comment 30 but it does not seems to work,

Correction:

The patch from Comment 30 seems to be working, in my previous attempt I had forgotten to use -purgecaches option when starting TB with the patched file so the following line of code was not properly triggered when opening a Teams event already saved in calendar:

text = text.replace(/<((https?|mailto|ftps?|file|webcals?|nntp|s?news|nntp|ircs?|skype|tel|xmpp):[^>]+)>/g, "<a href='$1'>&lt;$1&gt;</a>");

With the patch, Teams event Description now appears with visible and clickable links when opened from the calendar view.

I would suggest to replace the line of code above by:

text = text.replace(/<((https?|mailto|ftps?|file|webcals?|nntp|s?news|nntp|ircs?|skype|tel|xmpp):[^>]+)>/g, "<br/><a href='$1'>$1</a><br/>");

Basically dropping the < and > at beginning and end of the displayed link as well as adding carriage return before and after the link so it appears alone on a new line.

This is to make the Description better formatted and more readable to end-users.

Note1: When clicking on the link, it seems that TB is complaining that Firefox is already opened and must be closed first. If you close Firefox first then clicking the link open Firefox fine and allow access to Teams meeting... but that may just be a bug in the Daily version of TB I tested with... Thunderbird Daily 87.0a1.en-US.win64_2021022021-02-17-13-07-47-comm-central

Note2: Zoom events appears with twice the same link... not sure if it is linked to that patch or not...

Note3: This function seems to be triggered multiple time when the calendar is loading upon startup (possibly once for each event in the calendar). I believe it should only be triggered when an event is opened and displayed on screen, otherwise it may just be loss of processing time... unless the intention is to store the converted Description back into the event. I haven't really looked further...

I can't help but wonder: why is everyone concentrating on parsing or not parsing in one way or another way, when the more user friendly straight forward solution is to 'detect' header X-MICROSOFT-SKYPETEAMSMEETINGURL and add a "Join Meeting" context menu to the meeting entry?
Optionally with a setting where one can specified which headers can/should be transformed into a "Join Meeting" context menu.

Because presence of the header doesn't really make a difference: this bug is affecting other events as well (non-teams ones).

Will this issue be sorted out before next ESR? Currently it is really handicapping as you simply cannot join a Teams meeting (or else links affected) via Thunderbird... you need to rely on an alternative email client software, defeating TB!

Of course.

Attachment #9203729 - Attachment is obsolete: true
Status: NEW → ASSIGNED

Pushed by mkmelin@iki.fi:
https://hg.mozilla.org/comm-central/rev/f1e31de81440
Properly show descriptions in Teams invites. r=darktrojan

Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
status-thunderbird88: --- → affected
tracking-thunderbird88: --- → +
Target Milestone: --- → 89 Branch

Comment on attachment 9210700 [details]
Bug 1666296 - Properly show descriptions in Teams invites. r=darktrojan

[Approval Request Comment]
User impact if declined: Teams invites useless - can't find the link to join
Testing completed (on c-c, etc.): just landed on c-c
Risk to taking this patch (and alternatives if risky): Low

Attachment #9210700 - Flags: approval-comm-beta?

Comment on attachment 9210700 [details]
Bug 1666296 - Properly show descriptions in Teams invites. r=darktrojan

[Triage Comment]
Approved for beta

Attachment #9210700 - Flags: approval-comm-beta? → approval-comm-beta+

Thanks for fixing this. When TB 88 is scheduled to be released (officially)? Cannot find a roadmap...

The next (general) release is 91 in mid July. 88 is beta only. The beta2 should be out in a day or two - you can get it from https://www.thunderbird.net/en-US/#channel

Thank you very much Magnus for fixing this important bug, non-trivial stuff!

Thank you guys, it is nice to be able again to join a Teams meeting directly from TB 88.0b2 (64-bit) onward :-)

How do you guys use the Google Calendar Provider in TB88. When I install the TB78 version of it, I can't add a google calendar to lightning. The option "Add Google Calendar" is missing.

Is there a beta version of the provider for TB88?

That is completely unrelated to this bug.
Note that the google calendar can be accessed using CalDAV as well. On trunk/beta, just ill in your gmail address in the username, and you're set to go.

Sorry for that, and thanks a lot for answering and fixing the bug. Works great now. Solved a problem that occupied me several times a day.

See Also: 1666452 →

Will this be approved for ESR after it marinates for a while Wayne?

Flags: needinfo?(vseerror)

Stupid question, of course it is in 91.

Flags: needinfo?(vseerror)

this does not seem to be fixed in 91 - Teams meeting invitation is rendered without clickable links (or any links for that matter)

I'm on Thunderbird 91.1.0, using Google Calendar (using Thunderbird native functionality to connect to my google calendar). I do have links in some descriptions, but not the teams links to the meeting when it was sent via the teams application.

So the link to the meeting is available on google agenda but not via Thunderbird (I do have different display of the description if I use the native functionality to link to my google agenda or the provider for google agenda extension, but in both cases, the link to the teams meeting is not displayed).

The bug in TB 91 is bug 1727061, not this one. It has a patch waiting for review.

(In reply to Ben Bucksch (:BenB) from comment #64)

The bug in TB 91 is bug 1727061, not this one. It has a patch waiting for review.

I can confirm what @dmonnehay said, it shows up fine in google calendar in the web browser, but does not show the MS teams meeting link in Thunderbird/lightning 91.1.2 (64-bit). @ben, if I'm following your saying that there is currently a fix for this in review, but it's just not ready yet?

As mentioned, please see bug 1727061, not here. You can see the status over there.

See Also: → 1727061

Does this patch has the following side effect?
https://thunderbird.topicbox.com/groups/enterprise/T0661b5915a2d00e8-M43050dbf43c83726521bb141/expand-calendar-event-details-by-default
Or is it related to a separate bug/patch?

No. Related to bug 760412.

This bug still exist in TB 91.5.0 (64 bits)
I cannot help fixing the bug but I can help in documenting/reproducing.
Regards

I can also confirm this bug exists in TB 91.5.0 (64 bits). TB doesn't detect the URL to join MS Teams meetings via calendar invites.

Flags: needinfo?(mkmelin+mozilla)

If you still see some problem, please file a new bug and if possible include a test case as .eml
I don't know of a case where it doesn't work.

Flags: needinfo?(mkmelin+mozilla)

I am on 91.3.1 (Ubuntu 20.10).

On the header bar I see the Invitation bar with buttons to accept, deny etc.

2 issues remain:

  1. I can't see WHEN the meeting is to be scheduled. I can only see this after accepting the invitation, by clicking Details.
  2. When clicking Accept, the organizer does not receive the confirmation.

Reopened as Bug 1750223 as requested by Magnus Melin @Magnus Melin

In my case, once the invite is accepted and it appears on the calendar, the link with the URL of the invite is not shown in the description of the meeting, and it is not shown anywhere else. This means even though the meeting might be accepted and included in the calendar, you have no way to jump to the meeting URL, there's no way to see it or tap into it.

Looking at recent comments above here, I am confused. Is this bug fixed or not?

Using 91.5.0 and the bug is still there. Maybe a stupid thing but when looking at the same invitation in my google calendar, all links to teams-meeting seem to be OK (after restoring the event in google cal...). Then when I edit my google cal invitation and remove the first bracket (<) just before the teams-link in google cal event and save the event, everything will be OK in Thunderbird as well. So that seem to do the trick! Of course having this automated would be great...

(In reply to Worcester12345 from comment #76)

Looking at recent comments above here, I am confused. Is this bug fixed or not?

(In reply to mika.pyoria from comment #77)

Using 91.5.0 and the bug is still there.

THIS bug report is marked fixed. For people who still a problem:

  • If your issue is the newer Bug 1750223 you should note that it is NOT yet fixed in 91.x (such as 91.5.0), as indicated by the flags "thunderbird_esr91 affected" in bug 1742101, fixed only 3 days ago and isn't even fixed yet in beta - it fixes the 91.2.0 regression of Bug 760412, and will eventually get fixed in beta and 91.x
  • If your issue is the not Bug 1750223/bug 1742101, then you should file a new bug report, because commenting in fixed bug reports will not result in developer action
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: