295017 - copy and paste of recurring weekly calendar events results in unexpected recurrance effects

Status: VERIFIED DUPLICATE of bug 393084

(Calendar :: Sunbird Only, defect)

Description

[Leo]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a5) Gecko/20050203 Mozilla Sunbird/0.2

I copied an event that recurred three times, once a week on the same day of the
week.  I then tried to paste this series of three events to other days of the
week.  The result was the following:

-The start times were changed to the nearest-to-current half-hour (I reproduced
this problem at 10:55pm and the start times were changed to 11:00pm; I
reproduced it again at 11:05pm and the start times were changed to 11:30pm)
-The event was copied to the day I intended, but the recurrance was either on
the same day of the week as the original event, starting the next time the
original day of the week occurred; or it was on a combination of the original
day of the week *and* the new day of the week.
-If the event spans more than one day (ie 11:30pm-12:30am), then the new day of
the week seems to be completely ignored for the purposes of recurrance; the
event only recurs on the original day of the week in every reproduction.

In order to try and figure out what was the problem, I double-clicked the
newly-pasted events to investigate their properties.  I discovered:

-The settings on the "Recurrence" tab were slightly different.  There were two
days of the week checked, one of which was "greyed out" (the day I pasted the
event on) and the other "selectable" (the day of the original).  Also, *both* of
the first two recurrance options, "Forever" and "Number of times", were selected.  

Reproducible: Always

Steps to Reproduce:
1. Switch to Multiweek View in Sunbird 0.2
2. Create an event with the following settings under the "Recurrence" tab:
repeat every 1 week; number of times: [any number greater than 1]
3. Change the event's start time to something that is at least one (1) hour
before or after the time Sunbird provides.
4. Click OK.
5. Highlight the newly created event, right-click, and select "Copy" from the
right-click menu.
6. Select a different day of the week in either the same or a different week,
right-click, and select "Paste" from the right-click menu.
Actual Results:  
Nothing out of the ordinary happened until I tried to paste the event to another
location.  When I did this, the event pasted into the correct day, but at the
next half-hour increment from the current time.  Also, every recurring event
recurred only on the day of the week of the original event.

Expected Results:  
It should have pasted the event in the correct day at the correct time, and the
recurring events should be on the same day of the week as the newly-pasted
event.  For example, if I create an event that recurs every week for three weeks
on Tuesday, and I want to paste that event one week later on a Thursday, I want
the recurrance to occur on Thursday as well.

Comment 1

[Joey Minta]

Leo,
   A lot of what you've mentioned here is covered in bug 199422.  Specifically,
I believe the time changes should be considered a duplicate of that bug.  Also,
the Forever/Number of Times radio button problem is bug 287393.  For recurring
events, I can confirm the problem of the recurrence information being preserved
too perfectly.  This results in all future occurrences of the event happening on
the day of the week the original event was scheduled to repeat on, rather than
on the day of the week the event was pasted to. The graying out/checking of the
new day of the week is most likely a result of the front end trying to make sure
that a recurring event repeats on the day it falls.  The actual stored data
doesn't agree with this though.
    Leo, can you please say if you agree with my suggestions about other bugs
for a few of these issues?  If so, the question then remains whether to include
this information about recurrence problems under bug 199422 or keep this open as
a new bug to deal with them.  My personal opinion is to include it there, based
on that bug's summary, but if you disagree, I can probably be persuaded.

Comment 2

[Leo]

(In reply to comment #1)

I agree 100% about the radio button issue... that's my fault for repeating
287393.  I also agree that, as far as the start/end times bug goes, it is a
repeat of 199422.  So that leaves recurrance info being preserved too perfectly...

The summary of this bug is a bit misleading... I had written that before I had
discovered the full extent of the bug I was writing up.  I changed the summary
to more accurately depict the real bug here.

[Summary changed from "copy and paste of recurring calendar events results in
unexpected start & end times" to "copy and paste of recurring calendar events
results in unexpected recurrance effects"]

It seems to me that the essential quality of bug 199422 and of (what remains of)
295017 is fundamentally different: 199422 is about losing too much info about
the event, and 295017 is about preserving too much info about the event. 
However, if those are related enough that you think they should be combined, I
won't complain.  Whatever makes it easier for the people at Mozilla to do what
they need to do is fine by me.

Comment 3

[Joey Minta]

Confirming this bug on 2005011113-cal.  Since bug 199422 already has a patch on
it, it probably makes more sense to solve this one separately.  

I did a bit more testing and, for me, recurring monthly/yearly events are
handled beautifully by copy and paste.  I don't think daily events can be an
issue here.  So, I'm adding 'weekly' to the summary.  Just to clarify from the
original:

Reproducable: Always

Steps to reproduce:
1.) Create an event that recurs weekly, for instance, on every Tuesday.
2.) Copy the event and paste it on another day of the week, for instance, Wednesday.

Actual results:
The event is pasted on the Wednesday that was intended, but the recurrence
information is still set for Tuesday, meaning all future events recur on Tuesday.

Expected results:
The pasted event should recur on Wednesdays.

Status: NEW
Hardware/OS: All

Comment 4

[Stefan Sitter [:ssitter]]

(In reply to comment #3)
> 1.) Create an event that recurs weekly, for instance, on every Tuesday.
> 2.) Copy the event and paste it on another day of the week, for instance, 
Wednesday.

Tried to reproduce with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/
20051014 Mozilla Sunbird/0.2+. Paste of reoccuring event fails with JS error:

Error: flushItem DB error: not an error
Source File: file:///home/sts/sunbird/components/calStorageCalendar.js
Line: 1448

Error: [Exception... "Component returned failure code: 0x80004005 
(NS_ERROR_FAILURE) [calIRecurrenceRule.endDate]"  nsresult: "0x80004005 
(NS_ERROR_FAILURE)"  location: "JS frame :: file:///home/sts/sunbird/components/
calStorageCalendar.js :: anonymous :: line 1662"  data: no]
Source File: file:///home/sts/sunbird/components/calStorageCalendar.js
Line: 1662

Error: [Exception... "Component returned failure code: 0x80004005 
(NS_ERROR_FAILURE) [calIRecurrenceRule.endDate]"  nsresult: "0x80004005 
(NS_ERROR_FAILURE)"  location: "JS frame :: file:///home/sts/sunbird/components/
calStorageCalendar.js :: anonymous :: line 1662"  data: no]
Source File: file:///home/sts/sunbird/components/calStorageCalendar.js
Line: 1662

Error: uncaught exception: [Exception... "Component returned failure code: 
0x80004005 (NS_ERROR_FAILURE) [calIRecurrenceRule.endDate]"  nsresult: 
"0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: file:///home/sts/
sunbird/components/calStorageCalendar.js :: anonymous :: line 1662"  data: no]

Comment 5

[Matthew (lilmatt) Willis]

Reassigning all automatically assigned bugs from Mostafa to nobody@m.o

Bugspam filter: TorontoMostafaMove

Comment 6

[Sebastian Schwieger]

I tried with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060828 Calendar/0.3a2+

by copying the event and pasting it to another day only this occurence is copied, no recurrence rule seems to be associated with it. No error messages.

(following the steps provided in comment 3.)

Comment 7

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

Since we now copy only single occurrences, this is bug 393084.