1002024 - Sending separate invitations to attendees onlys send email for first invited person

Status: RESOLVED FIXED

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

Description

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

Daily 20140427 with latest Lightning 3.3a1

As discovered by rb in bug 544169, the separate email invitation per attendee only sends to the first person added to the attendee list of a new event.

Comment 1

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

Error message:

[JavaScript Error: "[Exception... "[JavaScript Error: "document.getElementById(...) is null" {file: "chrome://lightning/content/imip-bar.js" line: 138}]'[JavaScript Error: "document.getElementById(...) is null" {file: "chrome://lightning/content/imip-bar.js" line: 138}]' when calling method: [calIOperationListener::onOperationComplete]"  nsresult: "0x80570021 (NS_ERROR_XPC_JAVASCRIPT_ERROR_WITH_DETAILS)"  location: "JS frame :: file:///C:/Mozilla/Debugging/Thunderbird/Profiles/unstable/central/Test-central-en/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/components/calCompositeCalendar.js :: calCompositeGetListenerHelper.prototype.onOperationComplete :: line 520"  data: yes]"]

Comment 2

[[:MakeMyDay]]

This should have been fixed with bug 986852 - I'll take a look.

Comment 3

[[:MakeMyDay]]

Are you sure this error message is related to the reported issue? This indicates a problem with the implementation of bug 990009 under some conditions and is not related to the notification feature.

Comment 4

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

I didn't see the error this time, but if you check the Sent folder, there is only message: the one for the first attendee invited.

Comment 5

[[:MakeMyDay]]

Did you only check the sent folder or also the inbox of the recipients?

Comment 6

[[:MakeMyDay]]

Even as the error message from comment #1 is not related to this issue, it shouldn't occur. If you are able to reproduce that, can you please file a respective bug?

Comment 7

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

(In reply to MakeMyDay from comment #5)
> Did you only check the sent folder or also the inbox of the recipients?
I checked the inboxes of the recipients: If I let Tb send to all of them in one mail, the both get it, if it shall send separate mails, only the first one gets a mail.

Comment 8

[[:MakeMyDay]]

Confirming the issue, even though it's not yet clear what's happening here. Unfortunately, I had a system crash yesterday, so it may take some days until my system is in shape again to proceed in investigation here.

The issue producing the error log message is a different one and I had already a fix for it before the crash. I will file a separate bug for that.

Comment 9

[[:MakeMyDay]]

The mentioned bug in comment #8 related to the error message from comment #1 is bug 1002415.

Comment 10

[[:MakeMyDay]]

This bug is a strange one. I identified the place, where thing are going wrong, but actually I have no idea, why this is happening.

_sendItem(...) at http://mxr.mozilla.org/comm-central/source/calendar/base/modules/calItipUtils.jsm#984 receives a value from aTransport.sendItems(...) (-> http://mxr.mozilla.org/comm-central/source/calendar/itip/calItipEmailTransport.js#132 ), which then is returned further.

While in aTransport.sendItems(...) TRUE is passed back, _sendItems(...) receives UNDEFINED. It seems there's a layer inbetween, that I'm not aware of - but if so, I have no idea why this worked before...

Does anybody has an idea about this?

Comment 11

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

Reason for this:

http://dxr.mozilla.org/comm-central/source/calendar/base/modules/calItipUtils.jsm#1001
  if (!_sendItem(sendToList, sendItem)) {

calls

_sendItem which calls

http://dxr.mozilla.org/comm-central/source/calendar/base/modules/calItipUtils.jsm#984
  return aTransport.sendItems(aSendToList.length, aSendToList, itipItem);

That calls http://dxr.mozilla.org/comm-central/source/calendar/itip/calItipEmailTransport.js#132
  return this._sendXpcomMail(aRecipients, aSubject, aBody, aItipItem);

were we get to http://dxr.mozilla.org/comm-central/source/calendar/itip/calItipEmailTransport.js#187
  switch (aItem.autoResponse) {

We pass that check at http://dxr.mozilla.org/comm-central/source/calendar/itip/calItipEmailTransport.js#188
  case (Components.interfaces.calIItipItem.USER): {

At the end of the method, there is a |return false|, only in |case (Components.interfaces.calIItipItem.AUTO): {| something different can be returned.

For this reason, the for loop at http://dxr.mozilla.org/comm-central/source/calendar/base/modules/calItipUtils.jsm#1001
  if (!_sendItem(sendToList, sendItem)) {
breaks.

Comment 12

[[:MakeMyDay]]

Attachment: ExtendedLoggingForAnalysingBug1002024.diff

Thank you for digging into this, but I think that's not the problem here. If aItem.autoResponse is of value Components.interfaces.calIItipItem.USER there is an indended fall through to the Components.interfaces.calIItipItem.AUTO section, which ends in return TRUE once a message is sent out.

To make this obvious, you can apply this logging patch and using verbose debug mode.

Comment 13

[Stefan Sitter [:ssitter]]

Despite the fact that this is marked as a blocker I doubt that it will delay the release of Lightning 3.3 that must ship together with Thunderbird 31. If you can't fix it I suggest to disable the new 'separate invitations' feature for the final 3.3 release instead of shipping a broken feature.

Comment 14

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

I agree, this needs fixing or backing out on beta. I'm temporarily setting the milestone to 3.3 so I can easier track what still needs to be done before b2.

Comment 15

[[:MakeMyDay]]

Attachment: MakeSentItemReturnBooleanValue-V1.diff

Now, I guess what's going wrong here: Calling aTransport.sendItems(...) at http://mxr.mozilla.org/comm-central/source/calendar/base/modules/calItipUtils.jsm#1003 cannot return anything as the interface at http://mxr.mozilla.org/comm-central/source/calendar/base/public/calIItipTransport.idl#45 is defined to not to do so.

I have a simple patch to enable returning the result by changing the interface, but before asking for review I would like to test this. Unfortunately, the Calendar try builds seem to be broken since 19-Jun-2014 (as well as nightly builds of TB & Lightning).

Comment 16

[[:MakeMyDay]]

Comment on attachment 8447720 [details] [diff] [review]
MakeSentItemReturnBooleanValue-V1.diff

I tested the patch successfully with a try build.

Comment 17

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

Comment on attachment 8447720 [details] [diff] [review]
MakeSentItemReturnBooleanValue-V1.diff

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

r=philipp and approval for aurora and beta. As beta 2 was just built, I'll probably include this manually so we can get some testing in.

Comment 18

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

Comment on attachment 8447720 [details] [diff] [review]
MakeSentItemReturnBooleanValue-V1.diff

Oh actually, we need to change the UUID of the interface since it changed. Thank you tree hooks for catching this!

Comment 19

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

Attachment: MakeSentItemReturnBooleanValue-V2.diff

Here is the same patch with uuid changed. I've pushed this to comm-beta so we can use this in Lightning 3.3b2 and up. 

https://hg.mozilla.org/releases/comm-beta/rev/56a7f0a73865

Keeping checkin-needed for aurora and central.

Comment 20

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

https://hg.mozilla.org/releases/comm-aurora/rev/05a977be5c70
https://hg.mozilla.org/comm-central/rev/4c3d957c48d3