345607 - Copy recurring event and paste to another day appears to work but event is not saved (has RECURRENCE-ID but no parent item) [clipboard]

Status: RESOLVED FIXED

(Calendar :: Calendar Frontend, defect)

Description

[Brent Lambert]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060507 Mozilla Sunbird/0.3a2

I create an arbitrary one-time event and can copy and paste to another day just fine.  However if I try to copy a repeating event and paste it to another day, the paste operation appears to work but when I browse to the next week (or previous week) then back to where I pasted the event, it is gone.

I've tested with events that repeat daily, weekly, and monthly, all with the same results.  I've tested with repeating forever, and with repeating for 5 occurrences.  I've tried it in both week view and month view, and I've tried using the context menu (right mouse) to copy/paste and using Ctrl-C & Ctrl-V.

I'm new to Sunbird, I have very little data.  I currently have 6 local calendars defined (all displayed), but only 2 real events and 1 real task defined, in two different calendars.  The recurring events are brand-new events I've created in a third calendar.

Also, it doesn't seem to matter whether I edit the event after pasting or not.  Either way, the same problem occurs.  The thing is, though, that if you do edit the pasted event, then any data you've added or changed is lost without warning.

Reproducible: Always

Steps to Reproduce:
1.Create a repeating event
2.In the week or month view (maybe others) copy the event using Ctrl-C or the context menu
3.In the week or month view (maybe others) paste the event to another day using Ctrl-V or the context menu
 -- pasted event should appear, though without all data (see other bugs addressing this).
4.Click the left or right arrow at the top of the week or month view to look at either the next or previous time period.
5.Click the opposite arrow to return to the time period in which you pasted the event.
  -- The pasted event is gone.  No sign of it at all.

Actual Results:  
The pasted event is gone.  No sign of it at all.  Not in any of my calendars (all are displayed).  NO error messages, though.  Just loss of data.


Expected Results:  
Saved the pasted event in the calendar from which it was copied, or at least somewhere.

Standard Windows XP Home sp2 configuration.  I also use Firefox and Thunderbird, though I doubt that makes a difference.  I do not have any other calendar software installed.

Comment 1

[Sebastian Schwieger]

Confirming this with Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9a1) Gecko/20061006 Sunbird/0.3

there is an older bug related to this (bug 295017) but I would prefer bug 295017 to be duped against this one.

Comment 2

[Sebastian Schwieger]

*** Bug 355371 has been marked as a duplicate of this bug. ***

Comment 3

[Sebastian Schwieger]

Copy of comment from bug 355371:
>As far as I tried to study this problem, it seems that there is a
>conflict between RECURRENCE-ID attached to the first recurrence and the new
>RRULE line : I think that when copying an event from recurrence, the
>RECURRENCE-ID line should not be copied

Comment 4

[Sebastian Schwieger]

*** Bug 355868 has been marked as a duplicate of this bug. ***

Comment 5

[Sebastian Schwieger]

*** Bug 359524 has been marked as a duplicate of this bug. ***

Comment 6

[Omar Bajraszewski]

I can still reproduce this bug with latest build Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20061128 Calendar/0.4a1. No error in console


I've created an event:

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN
BEGIN:VEVENT
CREATED:20061128T191642Z
LAST-MODIFIED:20061128T191642Z
DTSTAMP:20061128T191642Z
SUMMARY:reevent
CLASS:PUBLIC
RECURRENCE-ID;TZID=/mozilla.org/20050126_1/Europe/Warsaw:20061206T000000
DTSTART;TZID=/mozilla.org/20050126_1/Europe/Warsaw:20061206T000000
DTEND;TZID=/mozilla.org/20050126_1/Europe/Warsaw:20061206T010000
END:VEVENT
BEGIN:VTIMEZONE
TZID:/mozilla.org/20050126_1/Europe/Warsaw
X-LIC-LOCATION:Europe/Warsaw
BEGIN:DAYLIGHT
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
TZNAME:CEST
DTSTART:19700329T020000
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=3
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
TZNAME:CET
DTSTART:19701025T030000
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=10
END:STANDARD
END:VTIMEZONE
END:VCALENDAR

Removing RECURRENCE-ID; and pasting the code into calendar helps and resolves the problem. The event is saved.

The new code looks like:
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN
BEGIN:VEVENT
CREATED:20061128T191739Z
LAST-MODIFIED:20061128T191932Z
DTSTAMP:20061128T191932Z
SUMMARY:reevent
CLASS:PUBLIC
DTSTART;TZID=/mozilla.org/20050126_1/Europe/Warsaw:20061208T000000
DTEND;TZID=/mozilla.org/20050126_1/Europe/Warsaw:20061208T010000
X-LIC-ERROR;X-LIC-ERRORTYPE=PROPERTY-PARSE-ERROR:Parse error in property 
 name: TZID=/mozilla.org/20050126_1/Europe/Warsaw
END:VEVENT
BEGIN:VTIMEZONE
TZID:/mozilla.org/20050126_1/Europe/Warsaw
X-LIC-LOCATION:Europe/Warsaw
BEGIN:DAYLIGHT
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
TZNAME:CEST
DTSTART:19700329T020000
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=3
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
TZNAME:CET
DTSTART:19701025T030000
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=10
END:STANDARD
END:VTIMEZONE
END:VCALENDAR


I can see an error above: X-LIC-ERROR;X-LIC-ERRORTYPE=PROPERTY-PARSE-ERROR:Parse error in property 
 name: TZID=/mozilla.org/20050126_1/Europe/Warsaw

Hope it will help

Comment 7

[Omar Bajraszewski]

oh- but new event doesn't repeat

Comment 8

[Omar Bajraszewski]

Ok, one line is missed. RRULE:FREQ=WEEKLY;COUNT=5;INTERVAL=1

So it should looks like:

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN
BEGIN:VEVENT
CREATED:20061128T191642Z
LAST-MODIFIED:20061128T191642Z
DTSTAMP:20061128T191642Z
SUMMARY:reevent
CLASS:PUBLIC
RRULE:FREQ=WEEKLY;COUNT=5;INTERVAL=1
TZID=/mozilla.org/20050126_1/Europe/Warsaw:20061206T000000
DTSTART;TZID=/mozilla.org/20050126_1/Europe/Warsaw:20061206T000000
DTEND;TZID=/mozilla.org/20050126_1/Europe/Warsaw:20061206T010000
END:VEVENT
BEGIN:VTIMEZONE
TZID:/mozilla.org/20050126_1/Europe/Warsaw
X-LIC-LOCATION:Europe/Warsaw
BEGIN:DAYLIGHT
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
TZNAME:CEST
DTSTART:19700329T020000
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=3
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
TZNAME:CET
DTSTART:19701025T030000
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=10
END:STANDARD
END:VTIMEZONE
END:VCALENDAR

Comment 9

[Omar Bajraszewski]

The line "TZID=/mozilla.org/20050126_1/Europe/Warsaw:20061206T000000" below "RRULE:FREQ=WEEKLY;COUNT=5;INTERVAL=1" should be also removed to get rid of X-LIC-ERROR;X-LIC-ERRORTYPE=PROPERTY-PARSE-ERROR:Parse error in property 
 name: TZID=/mozilla.org/20050126_1/Europe/Warsaw

I would write a patch for it but unfortunately I don't know how to do it... As I guess something should be changed in /cvsroot/mozilla/calendar/resources/content/clipboard.js

Comment 12

[Grant Nakamura]

This bug persists in Calendar v0.5

Comment 13

[richard forth]

(In reply to comment #1)
> Confirming this with Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9a1)
> Gecko/20061006 Sunbird/0.3
> there is an older bug related to this (bug 295017) but I would prefer bug
> 295017 to be duped against this one.


This is also happening on Windows / Sunbird 0.5

Comment 15

[Alessandro Vermeulen]

This bug persists in Calendar/Lightning v0.7.

Comment 16

[Simon Paquet [:sipaq]]

Setting wanted0.8- as the main Calendar developers will not devote any time to
this in the 0.8 timeframe. Patches are, of course, always welcome.

Comment 17

[Majken Connor [:Kensie]]

Late for a couple meetings cuz of this bug. 

 Also, what's the point in giving wanted- if it's a critical bug and you'll take a patch? If it's wanted it's wanted.  Blocking- sure if no one will get to it, but certainly it's wanted+?

Comment 18

[Joe Hurr]

Don't know if anyone else has noticed this, but after pasting an event to cause the bug, if I switch to mail and then back to calendar it forgets the date I was at too.

Example: I switch to calendar to find myself looking at Weeks 16-19. I click Today to go to 31/03/08, Weeks 14-17. I copy and paste a recurring event. I go back to mail, then back to calendar. The data is lost, as we know (!), but I'm looking at Weeks 16-19 again too.

I've only just signed up to Bugzilla, and I'm amazed such a serious flaw has been around since mid-2006...

Comment 19

[Pierre Bernhardt]

Update for v0.8:
Now copy and paste of repeated task did not futher work anymore. The copy action is not a problem. Data is shown in the Clipboard. But the pase action will not work. No new entries are shown.
With a on day task copy and paste is now problem.

I checked the clipboard and removed lines:
UID:ac8004e5-f0dc-4257-b571-9334d692e84e
RECURRENCE-ID;TZID=/mozilla.org/20071231_1/Europe/Berlin:20080331T070000

1. After that the clipboard could be imported by paste in a new task.
2. But now it's a single task instead of a repeated task.

Situation 2. is ok for me because now I can modify the task to an repeated
one.

This problem should be fixed because it's very often used by me.

In my opinion I have a vote of two fixes: UID and RECUREENCE-ID lines
should not export (bad) should filtered by import (better).

Comment 20

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

Pierre, your issue is the same as the similar bugs bug 357399 and bug 392465. If the parser doesn't have the master item available, then it doesn't know what to do with the occurrence you are pasting. 

Duplicate, or are there other issues this bug needs to stay open for?

Comment 21

[Jonatan Cloutier]

this bug is about copying recurent event not importing calendar or accept invitation, I didn't read the two other bug but I don't think that it's the same issue... might be partly related tought

Comment 23

[Stefan Sitter [:ssitter]]

Using Sunbird 0.9 and local ics calendar the behavior is still the same. 

But using a local storage calendar the behavior has slightly changed: 

Copy and paste of repeating event is still not possible. But it doesn't look anymore like it appeared to work. No event is displayed on the target day that disappears after reload. Instead the Error Console shows:

    Error: Assert failed: no parent item passed!
    1: [file:///E:/sunbird/js/calUtils.js:1004] ASSERT
    2: [file:///E:/sunbird/js/calStorageCalendar.js:2165] anonymous
    3: [file:///E:/sunbird/js/calStorageCalendar.js:442] anonymous
    4: [file:///E:/sunbird/js/calStorageCalendar.js:398] anonymous
    5: [null:0] null
     = NS_ERROR_UNEXPECTED
    Source file: file:///E:/sunbird/js/calUtils.js
    Line: 1007

Comment 24

[Daniel Boelzle [:dbo]]

I think this bug is quite similar to bug 357399.

BTW: is there an existing bug to properly copy all vs. copy the single event? I think we should add such a feature, so we can provide the correct ics to the clipboard.

Comment 25

[Martin Schröder [:mschroeder]]

(In reply to comment #24)
> BTW: is there an existing bug to properly copy all vs. copy the single event? I
> think we should add such a feature, so we can provide the correct ics to the
> clipboard.

Maybe in bug 393084?

Comment 26

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

Martin, are you still working on this issue?

Comment 27

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

I looked into this and there is no obvious solution. There is no way to transfer non-text things via the clipboard. I have filed bug 475963 to fix the core issue here, although I doubt it will make 1.9.1 or even 1.9.2.

I have though of some (unfortunately really ugly) workarounds, but I'm not satisfied with them and they aren't really easy to implement:


* call getItem() for each item-unique occurrence to get the parent item from the calendar and add an RDATE.
  - Ugly asynchonous code all over the place.

* create a wrapper around nsIClipboard that saves the nsITransferable and returns
  it if needed
  - I've had Problems with pasting externally
  - A lot of code for a workaround.


I'm not really sure what do about this bug. I'd like to take it off the blocking list since its too much work for too little effect, but the current results don't really look good (Creates "Untitled" events).

Comment 28

[Majken Connor [:Kensie]]

Until the functionality works, can we just disable being able to copy the recurring event?

Comment 29

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

Attachment: Fix - v1

That was my second though too, but without parsing the items on each canPaste() check, we have no way of reliably disabling the Paste and/or Copy menuitems.

Daniel, maybe you have an idea?

Comment 30

[Daniel Boelzle [:dbo]]

Attachment: patch - v1

If I got this bug right, we proceed to follow value semantics when pasting as we currently do for single items (i.e. set a fresh UID).
Thus I think we just need to fix that UID and start-time changes are properly propagated for recurring items. This patch fixes this for me, though I'd appreciate any further testing, since code changes in this area are always highly sensitive.

Comment 31

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

Comment on attachment 359732 [details] [diff] [review]
patch - v1

>+  /**
>+   * If the base item's UID changes, this implicitly has to change all overridden items' UID, too.
>+   *
>+   * @param id new UID 
>+   */
>+  void onIdChange(in AUTF8String aNewId);
Hmm, can't we just make the overridden item get the ID directly from its parent item?

r=philipp with comments considered.

Comment 32

[Daniel Boelzle [:dbo]]

...like we do with the |calendar| attribute.

I thought about that, too, but refreained for now, because I am not sure whether all client code uses the |id| attribute instead of getting the UID property. We need to keep care of serializing, too. I'll further look st the code and think about it.

Comment 33

[Daniel Boelzle [:dbo]]

I am leaving UID/id consolidation up to future patches.

Pushed to comm-central <http://hg.mozilla.org/comm-central/rev/06cf82446ca8>

-> FIXED

Comment 36

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

These bugs are likely targeted at Lightning 1.0b1, not Lightning 1.0. If this change was done in error, please adjust the target milestone to its correct value. To filter on this bugspam, you can use "lightning-10-target-move".