938459 - Lightning Calendar Edit Events : Unable to update changes to invited attendees

Status: RESOLVED FIXED

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

Description

[yeokaiwei]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:25.0) Gecko/20100101 Firefox/25.0 (Beta/Release)
Build ID: 20131025151332

Steps to reproduce:

1. Click on "New Event" in Lightning
2. Fill in details of event i.e. "Title", "Location", etc
3. Click on "Invite Attendees" and fill in emails of attendees
4. Click "Save and close"
5. Agree to "Would you like to send out notification E-Mail now?"

At this point, all attendees should get an email invite.

6. Click on above event in calendar to edit.
7. Change the "Location".
8. Click on "Save and Close"
9. Notice Step 5. does not occur and no email is sent out.



Actual results:

No change email will be sent out and the event details on the invitees end will not change.



Expected results:

A desired result would be similar to deleting the event on the calendar. 

If you delete an event, a message saying "Would you like to send out notification E-Mail now?" would pop up.

We would like to request the following:
A message asking "Would you like to send out an update to the event E-Mail now?" similar to step 5. 

Upon choosing "OK", an email will be sent to all the original attendees to update the details of their event.

If the attendees agree to accept the change, the details in their event will be updated.

Comment 1

[Stefan Sitter [:ssitter]]

What version of Lightning do you use? Do you get any error messages in Tools > Error Console?

"Save and Close" is known to not work reliable. Could you try "Save" from menu first and afterwards "Close"?

Comment 2

[yeokaiwei]

Version 2.6.2.

I have a lot of error messages in Tools > Error Console. I do not know which one is the problem.

"Save" from menu first and afterwards "Close" does not work.

Comment 3

[Sven Giermann]

Confirming. Don't know why, but the call to display the confirmation "Would you like to send out an update to the event E-Mail now?" immediately returns false without showing up:
http://mxr.mozilla.org/comm-central/source/calendar/itip/calItipEmailTransport.js#195

Comment 4

[Sven Giermann]

EDIT: of course it doesn't return 'false' but 1, as if "No" had been pressed.
But as there's no error, is it a toolkit problem then?

The dialog normally shows up deleting the same event.
Even it shows up when I prefer a former "Save" as suggested in Comment 1 - so not confirming Comment 2.

@Stefan, is there an open bug collecting all issues with "Save an Close"?

Comment 5

[Sven Giermann]

Apart from that, some possible canditates for duplicate:
Bug 703513, Bug 709604, Bug 716373

Comment 6

[yeokaiwei]

Will this bug be able to be fixed in version 2.6.3?

Comment 7

[Sven Giermann]

In my tests the single "Save" always worked fine.
Please open the Dialog details and verify the attendee list is filled with at least one address, different from the assigned address to your calendar. Also verify the checkbox "send invitation mail" is checked.
What calendar type are you using? Local, calDAV, Google?

Could you please Delete the contents of your Error Console while the Event dialog is open and then simply press on "Save" - is there any error coming up by this? Do you see the "Send invitations" question?

Comment 8

[[:MakeMyDay]]

I also investigated on this isssue and i can confirm the observation from #3, but I think this is not the root course.

The OL-mode popup returns not a boolean value, but the index of the button pressed. For this popup dialog, there are two buttons with yes = 0 and no = 1. According to bug 345067, it always returns 1, if the dialog is closed by pressing X. See also the reference at MDN: https://developer.mozilla.org/en-US/docs/XPCOM_Interface_Reference/nsIPromptService#confirmEx()

To me it looks like the popup is in some way canceled. Maybe there is a problem with the observers defined in http://mxr.mozilla.org/comm-central/source/calendar/base/content/dialogs/calendar-event-dialog.js - these were introduced with bug 682583 close to when the issue was reported for the first time.

Maybe someone with a better insight can have a look at this issue?

Comment 9

[Decathlon]

I think MakeMyDay (comment 8) is right, the dialog seems as canceled and confirmEx returns 1.
The regression range is:

Ligthtnig 1.0b10pre BuildID=20111017035407 (2011/10/17) works

Lightning 1.0b10pre BuildID=20111018051157 (2011/10/18) fails

-> http://hg.mozilla.org/comm-central/log/0fb5c93dd679

there are a few fixes and Bug 682583 is inside the range.

Comment 10

[[:MakeMyDay]]

Attachment: AdditionalLogging.patch

It seems to be a problem with the dialog lifecycle. I have added a patch to add some more debug logging messages to see what happens if someone is interested to reproduce my findings.

There are basicly 3 scenarios of interest with a different behaviour:

1. [Failed] hit save&close button (or the respective menu item) on an existing event with attendee after you modified a major property (e.g. location) 

2. [Working] close the dialog by hiiting the (x) after modifying a major prop of the same event and confirm saving the item

3. [Working] create a new event with an attendee and hit the save&close button

In case of #3 the transaction to send the invitation is completed before the event dialog is unloaded, while in case of #2 the event dialog is unloaded before the transaction is going to send the invitation. In both cases there is no overlapping of the transaction processing and the shut down of the event dialog.

But in case of #1, the transction has started but not completed the procedure to send the invitation, when the event dialog is unloaded. To me, this seems the reason why the popup is silently canceled. I don't know whether this is handled by Thunderbird or directly by OS (which would also explain, why some commenters stated the problem would not occur on their Linux machine).

Maybe it's a solution to prevent the dialog from shutting down before sending out the inviation is completed, even though this might have not been the intention when implementing the transaction or vice versa to move the trigger of the transaction to the dialog unload part. Any thoughts?


BTW: I also observed, that trying to close the dialog by the menu command fails, if you saved the event beforehand (also by the menu command) - but this might be annother issue.

Comment 11

[[:MakeMyDay]]

Attachment: NoInvitationUpdatesSentOut-V1.diff

After taking a look to the checkins within the range reported in comment #9, I assume this is a side effect of the fix from bug 380060 (implementing offline mode). While operations including creating effectivly a new calendar item (creating an entirely new item or moving an existing one to another calendar) are runnig fast enough to be completed before event dialog unloads. Obviously modifying an existing item without changing the calendar takes too long.

The attached patch provides a solution (at least a work around) to wait for invitation sending is complete before the event dialog is closed.

Comment 12

[[:MakeMyDay]]

Just for the record: The issue mentioned at the end of comment #10 is independent to this bug and addressed in bug 844747.

Comment 13

[[:MakeMyDay]]

Attachment: NoInvitationUpdatesSentOut-V2.diff

Updated patch.

Comment 14

[Philipp Kewisch [:Fallen][📱📆]]

Attachment: Use recent or main window as parent - v1

I've come up with a slightly different solution. The problem is that we are specifying null as the parent window on the confirm dialog. This causes the code to select the most recent window, which is our event dialog. Our event dialog is closing and is considered closed by its window prop.

This patch explicitly takes the most recent window (so clicking "save" will use the event dialog as parent), but if its closed it falls back to the most recent calendar window.

Now we'll likely still run into problems if the event dialog is the only open window, but I'd consider this edge case and its probably attached to a whole new can of worms.

Comment 15

[Philipp Kewisch [:Fallen][📱📆]]

Attachment: Use recent or main window as parent - v1

(Fixes missing qref)

Comment 16

[[:MakeMyDay]]

Comment on attachment 8391924 [details] [diff] [review]
Use recent or main window as parent - v1

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

looks good.

Comment 17

[[:MakeMyDay]]

As your approach fixes the issue, we should go with that, as it also should resolve bug 772407 without further action. Unfortunately, this breaks the solution for bug 981055, I thought about, but that's to resolve there.

Comment 18

[[:MakeMyDay]]

Oh, I forgot to mention: r=makemyday. Do you check in the patch?

I guess we probably should backport this, what do you think?

Comment 19

[Philipp Kewisch [:Fallen][📱📆]]

Normally I would check this in, the tree is currently closed though. Setting the keyword so someone will take care once the tree is open again. Sorry for breaking your solution :) I hope we'll find a new solution then.

Comment 20

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/comm-central/rev/21e847fcd823

Comment 24

[Philipp Kewisch [:Fallen][📱📆]]

https://hg.mozilla.org/releases/comm-beta/rev/535ae40cb9e8
https://hg.mozilla.org/releases/comm-esr24/rev/0fc420befbfe

Comment 28

[Lukasz Szybalski]

Looks like The issue is in Thunderbird 24.4 and Lightning 2.6.4
The workaround to this problem is Comment #10 
2. [Working] close the dialog by hinting the (x) after modifying a major prop of the same event and confirm saving the item