User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Firefox/91.0

Steps to reproduce:

I have to say that I think that the following problem seems to overwrite information in the calendar of users using Thunderbird 91. I hope I'm wrong, but I think this is a serious problem affecting many users.

Version of Thunderbird: 91.4.1
Bugs that are connected to this: 1607834 and 1737518

1. Create an event with text in the description field, for example the word "test" without any formatting.
   The event gets saved correctly on the CalDAV server. The description field of the VEVENT contains:

DESCRIPTION;ALTREP="data:text/html,%3Cbody%3Etest%3C%2Fbody%3E":test

2. Open an other calendar client like Nextcloud Calendar (web) and edit the event description text to "1111111111111111test".
   Now the VEVENT on the server looks like this:

DESCRIPTION;ALTREP="data:text/html,%3Cbody%3Etest%3C%2Fbody%3E":1111111111111111test
(I've deleted the line break for better reading)

As you can see, Nextcloud only updates the plain text description, but the HTML description isn't updated.

3. Open the event in Thunderbird. The event description only contains "test".

4. Edit the event in Thunderbird and set the description field to "test222222222222222222". The VEVENT now contains:

DESCRIPTION;ALTREP="data:text/html,%3Cbody%3Etest222222222222222222%3C%2Fbody%3E":test222222222222222222
(I've deleted the line break for better reading)

Actual results:

The problem with the new formatted description field is that now other clients like Nextcloud Calendar seem to only update the plain text version of the text.
Also Thunderbird seems to ignore any changes to the description from external clients and overwrites these.

The problem is that users that use other devices (maybe a smartphone) and Thunderbird to edit calendar events are going to overwrite the modifications without seeing it: as Thunderbird shows only the HTML description and not the plain text description the user isn't warned that something is going to be overwritten the next time he saves the description.

Expected results:

I'm not sure how this could be solved - maybe there should exist some check if an other client has modified the plain text version of the event. I don't think that the problem is restricted to Nextcloud when thinking of the possible ways of how "DESCRIPTION;ALTREP" can be used.

Also there should exist the possibility to disable the formatting options completely (for enterprise use this is important when you have to use software that maybe only modifies the plain text version of the description).

I'm sorry that I forgot to add the developers of this new function - hereby I try to catch up on this.

Nextcloud only updates the plain text description, but the HTML description isn't updated.

This is a bug in NextCloud. If it changes the description, it should either update the property, or remove the property, if it doesn't understand it. The ALTREP is a property of the description.

The ALTREP property is in the CalDAV spec, so this is clearly a bug in the other software. We follow the spec.

Could you please file a bug against NextCloud?

Thanks for your reply - if this is a error of Nextcloud then I will open an Issue there.

I understand that Thunderbird follows the spec and I see that there is requested a URI for ALTREP so that data: URLs are usable. But although this is specified from the CalDAV side it seems hard for other clients to update the data: block in there. Thinking of a solution for this every other CalDAV client would have to exactly use the same formatting possibilities and rules as Thunderbird does. I have to admit that I don't know if also the usage of the formatting inside of the data: block follows some spec?

I'm pretty happy that there is a solution in Thunderbird for this - my doubt arises because years ago (2016) I had a short discussion on exactly the same question (formatting the description of events) with :Fallen who pointed out that in some way there should exist some kind of check if only one part of the description (for example only plaintext) has been changed. But like I've said if everything follows the specs and this only affects Nextcloud i will open an Issue there.

An other question would be if the new editor could be disabled in about:config when a user does not want / can use the ALTREP property introduced? Enterprise users may have to disable this until their other Clients like Nextcloud can support the ALTREP...? At the moment the users using Thunderbird and Nextcloud Calendar risk to loose data in the description field - I guess.

there should exist some kind of check if only one part of the description (for example only plaintext) has been changed

I don't expect that from other clients.

it seems hard for other clients to update the data: block in there.

Yes, I don't expect clients to update the HTML ALTREP. They might not support HTML descriptions at all. However, if they are changing the description, they should at least remove the ALTREP property, because it's no longer valid, because description has been overwritten, so ALTREP needs to be removed as well. I would actually expect this to be the default behavior, to remove unknown properties of fields that are overwritten (but of course leave unknown properties of unchanged fields alone).

If NextCloud were to replace the entire description field, including removing its properties, when the description is changed, then this would work.

Thanks for your reply now I see your point. I've tested the behavior on a smartphone using "Simple Calendar" and there the event description is overwritten like you've described it in Comment 5: the ALTREP property is completely deleted and in Thunderbird I only see not formatted text.

The question is if we can expect this behavior of the major part of CalDAV clients - if I've understood correctly the RFC 5545 Section 3.2.1 a ALTREP description could also be a URL to a website. Because of this a CalDAV client could also preserve the property and only change the descriptive text in the plain text view. But I think that your view on this should be the right one (that in this case the ALTREP should be deleted).

Thinking of the many possible combinations of client applications I imagine that there exists the possibility that a user overwrites the formatting of the description because he can't be sure how his client application acts: although an app may respect the spec and delete the ALTREP parameter the user may not want to loose his formatted description. I know that it's not possible to face all the various situations - i would only like to point out that users may be irritated by this situation.
From my point of view it would be a different thing if Thunderbird would use - as example - markdown to format the description field. If a user in this example would overwrite the markdown styling using his phone it would be "his fault" as he could have known that deleting the styling will result in loosing the formatting. This isn't the case with the ALTREP parameter because there the user can't know like his client software acts before he saved his changes.

Like you said I will open an Issue at Nextcloud to point them on this situation in their calendar. Nevertheless I'm hoping that Thunderbird will get the possibility to disable the formatted descriptions. At the moment I have to inform all users in our company that they have to be aware on this situation (combination of Nextcloud & Thunderbird, possible loose of formatting when using a smartphone app). If there would be a config parameter I could just deploy a new version of the policies to circumvent this problem.

I will open an Issue at Nextcloud

Thanks. Once you did, could you please post the URL of the NextCloud bug report here, so that we can follow it?

Hi,
I've opened the Issue yesterday at Nextcloud, see Issue 3863 of Nextcloud Calendar.

Great news! Somebody (github user max65482, probably maximartin here) fixed the bug in NextCloud. Fantastic! Thank you.

Perfect, thanks a lot to everyone involved to resolve this problem :-)!

This was fixed in NextCloud https://github.com/nextcloud/calendar/issues/3863

Thanks, everyone!