Closed Bug 431536 Opened 16 years ago Closed 16 years ago

Only one invitation can be accepted per Thunderbird session


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

Not set


(Not tracked)



(Reporter: informatique.internet, Assigned: dbo)




(2 files)

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
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?
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
Version: unspecified → Mozilla 1.8 Branch
I've tested with an empty profile too...
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...

Assignee: nobody → informatique.internet
Attachment #321611 - Flags: review? → review?(daniel.boelzle)
I can confirm this problem. The only work-around is re-start TB, which really
makes Calendar unusable until this is fixed.
Ever confirmed: true
Flags: wanted-calendar0.9?
OS: Linux → All
Hardware: PC → All
Summary: Problem when accepting two invitation → Problem when accepting two invitations
Version: Mozilla 1.8 Branch → unspecified
Flags: wanted-calendar0.9? → blocking-calendar0.9+
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
Attachment #321611 - Flags: review?(daniel.boelzle) → review-
Asking Clint; maybe the _handledID stuff is only a leftover.
Assignee: informatique.internet → daniel.boelzle
Attachment #322367 - Flags: review?(ctalbert)
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?
Summary: Problem when accepting two invitations → Only one invitation can be accepted per Thunderbird session
@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 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.
Attachment #322367 - Flags: review+
Makes sense, checked in on HEAD and MOZILLA_1_8_BRANCH => FIXED.
Closed: 16 years ago
Resolution: --- → FIXED
Target Milestone: --- → 0.9
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.
Attachment #322367 - Flags: review?(ctalbert) → review+
You need to log in before you can comment on or make changes to this bug.