Last Comment Bug 468846 - Recurring all day event -> duplicate event created after editing a single all day event
: Recurring all day event -> duplicate event created after editing a single all...
[needed beta][no l10n impact]
Product: Calendar
Classification: Client Software
Component: Provider: Local Storage (show other bugs)
: unspecified
: All All
-- normal with 2 votes (vote)
: 1.0b1
Assigned To: Philipp Kewisch [:Fallen]
: 471266 (view as bug list)
Depends on: 470430
  Show dependency treegraph
Reported: 2008-12-10 08:05 PST by fif4183
Modified: 2010-03-24 10:45 PDT (History)
7 users (show)
philipp: blocking‑calendar1.0+
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---

Image showing steps 1 through 5 of reproducing the issue (65.10 KB, image/jpeg)
2008-12-10 08:06 PST, fif4183
no flags Details
Image showing step 6 to reproduce the issue (16.97 KB, image/jpeg)
2008-12-10 08:07 PST, fif4183
no flags Details
[checked in] fix - v1 (1.05 KB, patch)
2009-03-30 07:38 PDT, Daniel Boelzle [:dbo]
philipp: review+
Details | Diff | Splinter Review
Fix - v2 (2.45 KB, patch)
2009-08-19 15:28 PDT, Philipp Kewisch [:Fallen]
dbo.moz: review+
Details | Diff | Splinter Review

Description User image fif4183 2008-12-10 08:05:19 PST
User-Agent:       Opera/9.52 (Windows NT 5.1; U; en)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20081210 Calendar/1.0pre

If a single instance of an all day weekly-repeating event is edited, the original unedited event reappears adjacent to the modified event the next time the user opens the calendar program, Sunbird in this case.

Reproducible: Always

Steps to Reproduce:
1. Create a new All Day Event that repeats weekly
2. Edit a single occurrence of the event
3. Change the description of the specified single event and save
4. Exit the application, Sunbird in this case
5. Open the application
6. Upon loading, the application shows both the edited event and the original event on the same day.
<img src=""><br>
<img src=""><br>
Actual Results:  
Two events shown.

Expected Results:  
One event shown (the edited one).

This problem did not exist in Sunbird 0.7, but it does exist in Sunbird 0.9 and Sunbird 1.0pre.
Comment 1 User image fif4183 2008-12-10 08:06:28 PST
Created attachment 352322 [details]
Image showing steps 1 through 5 of reproducing the issue
Comment 2 User image fif4183 2008-12-10 08:07:18 PST
Created attachment 352323 [details]
Image showing step 6 to reproduce the issue
Comment 3 User image Andreas Treumann 2008-12-11 05:17:09 PST
It's possible for me to reproduce this issue with lightning build 20081210 and a local storage calendar.
Comment 4 User image fif4183 2008-12-22 22:47:23 PST
I'm not sure whom this bug should be assigned to.

However, I just remembered an issue I had with Sunbird 0.8.  If I made a repeating event but I later tried to edit just one instance, it was necessary to make the change twice.  The first time, it did not store the change.

This seems like it may be related to bug 468846, but I'm not sure who worked on it previously.
Comment 5 User image Andreas Treumann 2009-01-13 00:31:17 PST
*** Bug 471266 has been marked as a duplicate of this bug. ***
Comment 6 User image Philipp Kewisch [:Fallen] 2009-03-16 01:54:13 PDT
Confirmed. This sucks. blocking+
Comment 7 User image Daniel Boelzle [:dbo] 2009-03-30 07:38:59 PDT
Created attachment 370004 [details] [diff] [review]
[checked in] fix - v1

This fixes the problem. Storage has always handled RECURRENCE-ID as DATE-TIME.

BTW: I couldn't run the unit tests; is that issue known (or my build broken)?

/System/Library/Frameworks/Python.framework/Versions/2.5/Resources/ can't open file '/Users/dbo/moz_cc/src/mozilla/testing/xpcshell/': [Errno 2] No such file or directory
make: *** [check] Error 2
Comment 8 User image Stefan Sitter 2009-03-31 12:04:24 PDT
(In reply to comment #7)
> BTW: I couldn't run the unit tests; is that issue known (or my build broken)?
> .../src/mozilla/testing/xpcshell/': [Errno 2]

|make check| runs fine for me on win32 sunbird build as of today.
Comment 9 User image Philipp Kewisch [:Fallen] 2009-04-02 14:07:04 PDT
Comment on attachment 370004 [details] [diff] [review]
[checked in] fix - v1

r=philipp, thanks a bunch!
Comment 10 User image Daniel Boelzle [:dbo] 2009-04-03 07:54:11 PDT
Pushed to comm-central <>

Comment 11 User image Simon Vaillancourt 2009-06-17 20:05:35 PDT
The patch that was committed will not work if you have a DATE-TIME based recurring meeting which has one DATE-ONLY exception, the recurrence id for the exception must have the time information even if the exception instance is an allday event.

- Create a DAILY recurring for 3 days
- Make second instance an all day event
- Restart, observe duplicate instance

Here is a suggested workaround that seems to work for me (but will not work if the original instance has a time value of T000000. But it's still better than the current situation.

            // If the item is of type "allday" and
            // no "time" values are specified, assume that the 
            // recurrenceId is a date type value
            if ((row.flags & CAL_ITEM_FLAG_EVENT_ALLDAY) != 0 &&
                item.recurrenceId.hour == 0 &&
                item.recurrenceId.minute == 0 &&
                item.recurrenceId.second == 0) {
              item.recurrenceId.isDate = true;
Comment 12 User image Martin Schröder [:mschroeder] 2009-06-21 07:19:44 PDT
Philipp, is this [needed beta]?
Comment 13 User image Philipp Kewisch [:Fallen] 2009-06-22 03:56:56 PDT
If possible we should fix this for the beta, but I'd be fine postponing it to beta2.

I think the better solution would be to add a column so that also instances with T000000 work.
Comment 14 User image Daniel Boelzle [:dbo] 2009-08-13 07:17:27 PDT
I agree with Philipp that the easiest solution would be to add a flag, e.g. CAL_ITEM_FLAG_PARENT_ALLDAY), so overridden items construct the correct recurrence id value type.
Comment 15 User image Philipp Kewisch [:Fallen] 2009-08-19 15:28:09 PDT
Created attachment 395429 [details] [diff] [review]
Fix - v2

This fixes, requires patch from bug 470430 and possibly also from bug 494140 (the latter of which I only have local, since I don't know how much more 470430 will change. Ask me if needed).
Comment 16 User image Daniel Boelzle [:dbo] 2009-09-02 08:02:49 PDT
Comment on attachment 395429 [details] [diff] [review]
Fix - v2

The patch looks good.

I think this wording is misleading, because
1. The occurrence itself already has EVENT_ALLDAY.
2. It's a flag to just balance out the RECURRENCE-ID which relates to the parent item's rule.

That way I'd propose to make clear what type the parent has (allday or not), e.g. PARENT_IS_ALLDAY or the like.

r=dbo with this resolved
Comment 17 User image Philipp Kewisch [:Fallen] 2009-09-03 00:28:31 PDT
At first I thought this wasn't quite true, but actually you are right. To be even more clear, I think we should call it RECURRENCE_ID_ALLDAY. This way all ambiguities should be taken care of.

I'll check this in as soon as bug 470430 and bug 494140 are checked in.
Comment 18 User image Philipp Kewisch [:Fallen] 2009-11-02 13:53:37 PST
bug 470430 is sufficient for applying this patch. I will check this in tomorrow when we have a nightly with the aforementioned bug.
Comment 19 User image Philipp Kewisch [:Fallen] 2009-11-04 09:43:00 PST
Pushed to comm-central <>
and <>

Comment 20 User image Philipp Kewisch [:Fallen] 2009-11-04 10:47:25 PST
Comment #17 taken into account in revs c-c: a2514ada730a c191: 7fee9d989390
Comment 21 User image Damian Szczepanik 2010-03-24 09:00:07 PDT
verified with
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20100323 Calendar/1.0b2pre

Note You need to log in before you can comment on or make changes to this bug.