commonName in addAttendee() cannot be updated in all cases

RESOLVED FIXED in 4.0.5

Status

defect
RESOLVED FIXED
4 years ago
4 years ago

People

(Reporter: MakeMyDay, Assigned: MakeMyDay)

Tracking

({regression})

Lightning 4.0.4
4.0.5
Dependency tree / graph

Details

Attachments

(1 attachment, 1 obsolete attachment)

Assignee

Description

4 years ago
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.
Assignee

Comment 1

4 years ago
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.
Attachment #8694137 - Flags: review?(philipp)
Attachment #8694137 - Flags: approval-calendar-release?(philipp)
Attachment #8694137 - Flags: approval-calendar-beta?(philipp)
Attachment #8694137 - Flags: approval-calendar-aurora?(philipp)
Assignee

Comment 2

4 years ago
Sorry, ebusd, forgot to cc you, see comment above.
Blocks: 1209399
Flags: needinfo?(ebusd)
Keywords: regression
Version: unspecified → Lightning 4.0.4

Comment 3

4 years ago
with this patch I can no longer change my participation status of an appointment.
Flags: needinfo?(ebusd)
Assignee

Comment 4

4 years ago
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?
Flags: needinfo?(ebusd)

Comment 5

4 years ago
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.
Flags: needinfo?(ebusd)
Assignee

Comment 6

4 years ago
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?
Flags: needinfo?(ebusd)

Comment 7

4 years ago
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
Flags: needinfo?(ebusd)
Assignee

Comment 8

4 years ago
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.
Flags: needinfo?(ebusd)

Comment 9

4 years ago
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
Flags: needinfo?(ebusd)
Comment on attachment 8694137 [details] [diff] [review]
FixCnUpdateForImmutableAttendees-V1.diff

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

Looks good, r=philipp
Attachment #8694137 - Flags: review?(philipp)
Attachment #8694137 - Flags: review+
Attachment #8694137 - Flags: approval-calendar-release?(philipp)
Attachment #8694137 - Flags: approval-calendar-release+
Attachment #8694137 - Flags: approval-calendar-beta?(philipp)
Attachment #8694137 - Flags: approval-calendar-beta+
Attachment #8694137 - Flags: approval-calendar-aurora?(philipp)
Attachment #8694137 - Flags: approval-calendar-aurora+
If you can reproduce the issue with the new debug info I'd apprecciate a complete patch of course
Assignee

Comment 12

4 years ago
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.

ebusd@ebusd.eu, can you check whether this fixes the issue for you?
Attachment #8694137 - Attachment is obsolete: true
Flags: needinfo?(ebusd)

Comment 13

4 years ago
works for me
Flags: needinfo?(ebusd)
Assignee

Comment 14

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

Ok, let's go that way.
Attachment #8696340 - Flags: review?(philipp)
Attachment #8696340 - Flags: approval-calendar-release?(philipp)
Attachment #8696340 - Flags: approval-calendar-beta?(philipp)
Attachment #8696340 - Flags: approval-calendar-aurora?(philipp)
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 :-)
Attachment #8696340 - Flags: review?(philipp)
Attachment #8696340 - Flags: review+
Attachment #8696340 - Flags: approval-calendar-release?(philipp)
Attachment #8696340 - Flags: approval-calendar-release+
Attachment #8696340 - Flags: approval-calendar-beta?(philipp)
Attachment #8696340 - Flags: approval-calendar-beta+
Attachment #8696340 - Flags: approval-calendar-aurora?(philipp)
Attachment #8696340 - Flags: approval-calendar-aurora+
Assignee

Comment 16

4 years ago
https://hg.mozilla.org/comm-central/rev/4dc92595235c
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → 4.7
Assignee

Updated

4 years ago
Duplicate of this bug: 1233365

Comment 19

4 years ago
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.
Assignee

Updated

4 years ago
Depends on: 1238381
Assignee

Comment 20

4 years ago
I have created bug 1238381 to follow up with comment 19.
You need to log in before you can comment on or make changes to this bug.