431536 - Only one invitation can be accepted per Thunderbird session

Status: RESOLVED FIXED

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

Description

[Hubert FONGARNAND]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.9b5) Gecko/2008032619 Firefox/3.0b5
Build Identifier: 

There's a problem when accepting two invitation. The first one is saved in the calendar but not the others

Reproducible: Always

Steps to Reproduce:
1.Open Tb/lightning
2.Send two invitation from an outlook 
3.Return in Tb/lightning
4.Accept the first invitation
5. -> The event is correctly saved in the calendar
6.Accept the second one...
7. -> No event saved in the calendar 
Actual Results:  
No event saved in the calendar 

Expected Results:  
the second event should be saved in the calendar

Comment 1

[Stefan Sitter [:ssitter]]

What version of Thunderbird do you use? What version of Lightning do you use? 

Do you see any error messages in Tools -> Error Console when performing the steps from above? If yes please copy and paste them here.

Are both ics files send in one email message? Or in separate ones? Are the events in the ics files connected to each other, e.g. is the second one an update for the first one?

What calendar (local storage, ics, caldav, ...) do you store the events in? Does it happen for other calendar types as well?

Comment 2

[Hubert FONGARNAND]

Thunderbird 2.0.12 Lightning CVS

No errors on error console or on console

ics files are in separated mail message and are not connected to each other
it happens on local storage, and caldav

Comment 3

[Hubert FONGARNAND]

I've tested with an empty profile too...

Comment 4

[Hubert FONGARNAND]

I think the problem comes from : lightning/js/calItipProcessor.js : 406-407


if (!Components.isSuccessCode(aStatus) &&
                    !this.itipProcessor._handledID) {

i think that this.itipProcessor._handledID is not null, because you already use it before...
so the this.itipProcessor._continueProcessingItem is not called...

Comment 5

[Hubert FONGARNAND]

Attachment: I think this patch will fix the problem

Comment 7

[Marcel Berteler]

I can confirm this problem. The only work-around is re-start TB, which really
makes Calendar unusable until this is fixed.

Comment 8

[Daniel Boelzle [:dbo]]

Comment on attachment 321611 [details] [diff] [review]
I think this patch will fix the problem

r- this seems to fix the bug, but I wonder why we should keep _handledID

Comment 9

[Daniel Boelzle [:dbo]]

Attachment: fix - removing _handledID

Asking Clint; maybe the _handledID stuff is only a leftover.

Comment 10

[Marcel Berteler]

Is there any movement on this bug as in my opinion this is a real show-stopper.

If the patch is working, can it please please please be applied to trunk so we can start using the nightly builds again?

Comment 11

[Bas van den Bosch]

@Daniel: Could attachment 321611 [details] [diff] [review] be chekced in and this bug left open? Clint doesn't have a lot of time and it's a pity to leave this problem lying around when there's an obvious fix.

Comment 12

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

Comment on attachment 322367 [details] [diff] [review]
fix - removing _handledID

Looks good, r=philipp

Requesting additional review from Clint to find out why we need this. Go ahead and check this in to fix the bug, we can still reopen when Clint enlightens us to why handledID is needed.

Comment 13

[Daniel Boelzle [:dbo]]

Makes sense, checked in on HEAD and MOZILLA_1_8_BRANCH => FIXED.

Comment 14

[cmtalbert]

Comment on attachment 322367 [details] [diff] [review]
fix - removing _handledID

(In reply to comment #13)
> Makes sense, checked in on HEAD and MOZILLA_1_8_BRANCH => FIXED.
> 
Thanks for not blocking on my availability.  I've been underwater with Firefox 3 of late.

>Index: calendar/base/src/calItipProcessor.js
>     /**
>      * Helper function to determine if this item already exists on this calendar
>      * or not.  It then calls _continueProcessingItem setting calAction and
>      * existingItem appropirately
>      */
>     _isExistingItem: function cipIEI(aCalItem, aItipItem, aRecvMethod, aRespMethod,
>                                      aTargetCal, aListener) {
I believe that handleID was a response to an odd behavior that we couldn't explain with the listeners.  For some reason, we'd get called in this function from both the onOperationComplete and from onGetResult callbacks and that would result in us adding the same event twice (well, attempting to add it twice, and encountering the failure on the second add).  

If that isn't happening anymore (perhaps we fixed that in the meantime) then we should definitely remove it.

Nice work.
r=ctalbert