1229329 - commonName in addAttendee() cannot be updated in all cases

Status: RESOLVED FIXED

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

Description

[[:MakeMyDay]]

From bug 1209399 comment 26:

It seems this patch leads to Lightning no longer being able to send email confirmation on accepted appointments. This is due to line 574 in calItemBase.js failing because of non-write access to "attendee.commonName". This occurs with a CalDAV based network calendar.

This is a report for 4.0.4, I'll update the version once available.

Comment 1

[[:MakeMyDay]]

Attachment: FixCnUpdateForImmutableAttendees-V1.diff

This patch should take care.

ebusd, can you give this patch a try an confirm that it solves the issue for you? You would have to revert the changes you made mentioned on the other bug, however.

Comment 2

[[:MakeMyDay]]

Sorry, ebusd, forgot to cc you, see comment above.

Comment 3

[ebusd]

with this patch I can no longer change my participation status of an appointment.

Comment 4

[[:MakeMyDay]]

Thanks for your feedback. Did get any messages in the error console?

Also, can you please describe your exact STR in detail to encounter the issue?

Comment 5

[ebusd]

There was no logging at all in the console after I've applied the patch and restarted TB.
TB version is 38.4.0 release, Lightning is 4.0.4.

steps to reproduce:
- in Lightning, double click on an appointment to which you were invited.
- change the participation state
- press OK
- open the appointment again to check the participation state

Without any patch applied, the error console starts with:
- uncaught exception: 2152071170
- NS_ERROR_OBJECT_IS_IMMUTABLE: Can not modify immutable data container'Can not modify immutable data container' when calling method: [calIAttendee::commonName]

With my patch (from bug #1229329) applied, the participation status is changed correctly, a dialog appears with the question whether to inform the owner via email, and no error is logged in the error console.

With your patch applied, the participation status is not changed, no dialog appears, and no error is logged.

Comment 6

[[:MakeMyDay]]

Thanks. Your patch would keep trying to change an immutable attendee if the cn is updated. That it works for you with your patch just means the cn in your case didn't need any modification, so it's not sufficient here.

Can you please provide the full log message including the line references?

From which to which partstat did you change while testing?

Are you in #calendar on irc.mozilla.org?

Comment 7

[ebusd]

Yes, that's right of course.
I changed from "attending" (or whatever it is called) to "potentially attending".
No, I'm not on IRC.
Here are the complete log entries:

>Zeitstempel: 01.12.2015 15:38:36
>Fehler: uncaught exception: 2152071170

>Zeitstempel: 01.12.2015 15:38:36
>Fehler: NS_ERROR_OBJECT_IS_IMMUTABLE: Can not modify immutable data container'Can not modify immutable data container' when calling method: [calIAttendee::commonName]
>Quelldatei: resource://calendar/modules/calUtils.jsm -> file:///C:/Users/john.MITXP/AppData/Roaming/Thunderbird/Profiles/i250ps4r.default/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/calendar-js/calItemBase.js
>Zeile: 575

>Zeitstempel: 01.12.2015 15:38:36
>Fehler: NS_ERROR_OBJECT_IS_IMMUTABLE: Can not modify immutable data container'Can not modify immutable data container' when calling method: [calIAttendee::commonName]
>Quelldatei: resource://calendar/modules/calUtils.jsm -> file:///C:/Users/john.MITXP/AppData/Roaming/Thunderbird/Profiles/i250ps4r.default/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/calendar-js/calItemBase.js
>Zeile: 575

>Zeitstempel: 01.12.2015 15:38:36
>Fehler: [Exception... "Can not modify immutable data container'Can not modify immutable data container' when calling method: [calIAttendee::commonName]"  nsresult: "0x80460002 (NS_ERROR_OBJECT_IS_IMMUTABLE)"  location: "JS frame :: resource://calendar/modules/calUtils.jsm -> file:///C:/Users/john.MITXP/AppData/Roaming/Thunderbird/Profiles/i250ps4r.default/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/calendar-js/calItemBase.js :: cIB_addAttendee :: line 575"  data: no]
>Quelldatei: resource://calendar/modules/calProviderUtils.jsm
>Zeile: 636

Comment 8

[[:MakeMyDay]]

It's still hard to debug as I don't see the issue here - if it passes with the patch without error, there must be an issue somewhere else that is preventing sending the reply. Can you please add the following snippet

if (!attendee.isMutable) {
    cal.LOG(cal.STACK(10));
}

just before the

attendee = attendee.clone();

from the patch. Then, please enable calendar.debug.log and calendar.debug.log.verbose, restart TB, run your test case and provide what you got in the log? Thanks.

Comment 9

[ebusd]

I've debugged it and the difference after adding the clone() call is that the transmission back to the caldav server contains the old (unchanged) participation state instead of the new one.
So it seems to me that the attendee.clone() is somehow incomplete.
Furthermore, without the clone() call one can see, that after sending the change to the caldav server, the attendee will be immutable. Here is the stack trace for this:

1: [resource://calendar/modules/calUtils.jsm -> file:///C:/Users/john.MITXP/AppData/Roaming/Thunderbird/Profiles/i250ps4r.default/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/calendar-js/calItemBase.js:575] cIB_addAttendee
2: [resource://calendar/modules/calItipUtils.jsm:613] cal_itip_checkAndSend
3: [resource://calendar/modules/calUtils.jsm -> file:///C:/Users/john.MITXP/AppData/Roaming/Thunderbird/Profiles/i250ps4r.default/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/calendar-js/calTransactionManager.js:134] cT_onOperationComplete
4: [resource://calendar/modules/calProviderUtils.jsm:634] cPB_notifyPureOperationComplete
5: [resource://calendar/modules/calProviderUtils.jsm:648] cPB_notifyOperationComplete
6: [file:///C:/Users/john.MITXP/AppData/Roaming/Thunderbird/Profiles/i250ps4r.default/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/components/calMemoryCalendar.js:243] calMemoryCalendar.prototype.modifyItem
7: [file:///C:/Users/john.MITXP/AppData/Roaming/Thunderbird/Profiles/i250ps4r.default/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/components/calDavCalendar.js:1137] caldav_addTargetCalendarItem/<
8: [self-hosted:620] next
9: [resource://gre/modules/Task.jsm:314] TaskImpl_run
10: [resource://gre/modules/Task.jsm:275] TaskImpl

Comment 10

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

Comment on attachment 8694137 [details] [diff] [review]
FixCnUpdateForImmutableAttendees-V1.diff

Review of attachment 8694137 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good, r=philipp

Comment 11

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

If you can reproduce the issue with the new debug info I'd apprecciate a complete patch of course

Comment 12

[[:MakeMyDay]]

Attachment: FixCommaInCnHandling-V2.diff

Here is the updated patch. It partly excludes applying the migration code, but this seems safer at the moment then to run into another malfunction.

[e-mail], can you check whether this fixes the issue for you?

Comment 13

[ebusd]

works for me

Comment 14

[[:MakeMyDay]]

Comment on attachment 8696340 [details] [diff] [review]
FixCommaInCnHandling-V2.diff

Ok, let's go that way.

Comment 15

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

Comment on attachment 8696340 [details] [diff] [review]
FixCommaInCnHandling-V2.diff

Review of attachment 8696340 [details] [diff] [review]:
-----------------------------------------------------------------

::: calendar/test/unit/test_bug1209399.js
@@ +90,5 @@
> +
> +    equal(event.getAttendees({}).length, expected.length, "Check test consistency");
> +    for (let exp of expected) {
> +        let attendee = event.getAttendeeById(exp.id);
> +        equal(attendee.commonName, exp.cn, "Test for cn matching of " + exp.id); 

Whitespace :-)

Comment 16

[[:MakeMyDay]]

https://hg.mozilla.org/comm-central/rev/4dc92595235c

Comment 17

[[:MakeMyDay]]

https://hg.mozilla.org/releases/comm-aurora/rev/969f9b057918
https://hg.mozilla.org/releases/comm-beta/rev/459a4f930fe5
https://hg.mozilla.org/releases/comm-esr38/rev/9abccdd1e73e

Comment 19

[SPuch]

I just tested the patch https://hg.mozilla.org/comm-central/rev/4dc92595235c
against lightning 4.0.4.1 and would like to remark, that it has some site effect.
While the dialog with the question whether to inform the owner via email when adding or modifying the event appears  fine, it does not come up anymore when event is deleted from calendar.

Steps to reproduce:
1) Add an invitation to (see dialog comes up)
2) delete the invitation (no dialog comes up)

Position in code:

Removing line 601 in calItipUtils.jsm
invitedAttendee = invitedAttendee.clone();
causes that bug. Part of the section "in case the attendee has just deleted the item"

Unfortunately I cannot reopen this bug here.

Comment 20

[[:MakeMyDay]]

I have created bug 1238381 to follow up with comment 19.