Closed Bug 1756547 Opened 3 months ago Closed 1 month ago

Cannot accept invitation modification, imip-bar only shows Details button.

Categories

(Calendar :: E-mail based Scheduling (iTIP/iMIP), defect)

Thunderbird 98
defect

Tracking

(Not tracked)

RESOLVED FIXED
101 Branch

People

(Reporter: lohner, Assigned: lasana)

References

Details

Attachments

(1 file, 1 obsolete file)

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"

Component: Untriaged → General
Keywords: dupeme
Product: Thunderbird → Calendar

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.

Assignee: nobody → lasana
Status: UNCONFIRMED → NEW
Component: General → E-mail based Scheduling (iTIP/iMIP)
Ever confirmed: true
Keywords: dupeme

(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?

Summary: Cannot accept invitation modification → Cannot accept invitation modification, imip-bar only shows Details button.

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.

See Also: → 1760272
Attachment #9271524 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Target Milestone: --- → 101 Branch

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

Status: ASSIGNED → RESOLVED
Closed: 1 month ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.