543698 - Moved occurrences of repeating all-day events are displayed on new and original date

Status: RESOLVED FIXED

(Calendar :: Provider: Local Storage, defect)

Description

[A. Sel.]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2) Gecko/20100115 Firefox/3.6 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.1.7) Gecko/20100111 Lightning/1.0b1 Thunderbird/3.0.1

When creating a recurring whole-time / full-time event and moving one instance of this event by drag & drop in the calendar view (multiple weeks) to another day, the event for this day will have been duplicated after restarting thunderbird, so that the event exists on both days (the original, the day it was moved to). 

Deleting one of the events will sometimes delete both (may depend on which of both you delete).

The recurring events (f. ex. this event next month) are not effected.

Reproducible: Always

Steps to Reproduce:
1. Create a recurring full-time event
2. Drag one instance of it to another day
3. Restart Thunderbird
Actual Results:  
Dragged event exists on both days

Expected Results:  
Dragged event only exists on the day it was dragged to

Comment 1

[Stefan Sitter [:ssitter]]

Confirmed using Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.8pre) Gecko/20100202 Calendar/1.0b2pre. 

Seems to be specific to all-day events and storage provider because I can't reproduce it using ics provider.

Comment 2

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

Attachment: Fix - v1

Stupid mistake I made while fixing bug 468846. Just passing a numeric parameter doesn't make it pass by reference! This is the much cleaner fix anyway.

Comment 3

[Stefan Sitter [:ssitter]]

Comment on attachment 431606 [details] [diff] [review]
Fix - v1

r=ssitter
Patch works, but only for new created events. What should happen to occurrences that were created with Sunbird 1.0b1 and that are stored without the proper flag in the database?

Comment 4

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

Unfortunately there's not much we can do about that. We had the same problem in bug 468846 itself. We don't really know if the exception is really an allday exception or not, so we can't update flags. 

Pushed to comm-central <http://hg.mozilla.org/comm-central/rev/188b04a3f384>

-> FIXED