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

Steps to reproduce:

In TB98v2 I tried can not accept changes to individual events (i.e. moved from 10:00 to 11:00) and I can't accept them for series events (one of a series or the whole series changed) either. Not sure if this is only MS Teams events or all events.

It used to at least accept the change in TB91 (though it sometimes actually changed the calendar entry and sometimes not, I never looked into it in detail), but now clicking on "Accept" does nothing. Something that might be related: I used to have to accept a meeting, then select the calendar, and then accept the meeting again for the status to change to "...already been processed"

I'll take this since I'm doing testing in this area. What the user describes may be bug 1759055 but there are still other issues with accepting updates.

(In reply to Nils from comment #0)

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

Steps to reproduce:

In TB98v2 I tried can not accept changes to individual events (i.e. moved from 10:00 to 11:00) and I can't accept them for series events (one of a series or the whole series changed) either. Not sure if this is only MS Teams events or all events.

It used to at least accept the change in TB91 (though it sometimes actually changed the calendar entry and sometimes not, I never looked into it in detail), but now clicking on "Accept" does nothing. Something that might be related: I used to have to accept a meeting, then select the calendar, and then accept the meeting again for the status to change to "...already been processed"

And different in 100.0 b1?

This is caused by a chain of events that start here:
https://searchfox.org/comm-central/rev/3a9dbc25aa8678c3b065ac93f74607436aea4915/calendar/base/modules/utils/calItipUtils.jsm#734

Apparently calling setProperty() on a calIItemBase has the side effect of marking the item "dirty" (except when setting "LAST-MODIFIED" which will do the opposite).
https://searchfox.org/comm-central/rev/3a9dbc25aa8678c3b065ac93f74607436aea4915/calendar/base/src/calItemBase.js#479

This does not mean much except for when ensureNotDirty() is called which will overwrite the DTSTAMP and LAST-MODIFIED properties of the object.
https://searchfox.org/comm-central/rev/3a9dbc25aa8678c3b065ac93f74607436aea4915/calendar/base/src/calItemBase.js#203

That method is called in a few places, included in a getter for stampTime (accessing the read-only property stampTime causes data to be overwritten).
https://searchfox.org/comm-central/rev/3a9dbc25aa8678c3b065ac93f74607436aea4915/calendar/base/src/calItemBase.js#383

When we receive a calIItipItem we preserve the original DTSTAMP on the received item(s) as X-MOZ-RECEIVED-DTSTAMP which is used in by the cal.itip.compare function to determine whether a new copy of the item (from the invitation) is older or newer than what we have stored in the calendar.

https://searchfox.org/comm-central/rev/3a9dbc25aa8678c3b065ac93f74607436aea4915/calendar/base/modules/utils/calItipUtils.jsm#75
https://searchfox.org/comm-central/rev/3a9dbc25aa8678c3b065ac93f74607436aea4915/calendar/base/modules/utils/calItipUtils.jsm#92

If setProperty is called without removing the mDirty flag during this workflow (as is the case when setting X-MOZ-INVITED-ATTENDEE) then the call on line 92 will overwrite the DTSTAMP with the current datetime and thus determine that the new version of the invitation is actually old and should not be processed.

There are a bunch of design issues here including the overwriting of data from a read-only property but there is not much that could be safely changed so close to a release and limited tests.

Pushed by mkmelin@iki.fi:
https://hg.mozilla.org/comm-central/rev/63e833ae6325
Reset item dirty flag after setting X-MOZ-INVITED-ATTENDEE. r=john.bieling