375383 - WCAP event with category lost all data after view refresh

Status: VERIFIED FIXED

(Calendar :: Provider: WCAP, defect)

Description

[Andreas Treumann]

REPRODUCTION:
=============

- use a WCAP calendar to create an event
- fill out all fields, choose a catrgory e. g. 'Anniversery'
- save this event
- refresh the view

RESULT:
=======

- all data is lost, the event named 'New Event' again

EXPECTED RESULT:
================

- a view refresh should not cause a data loss when a WCAP event gets a category 

REPRODUCIBLE:
=============

- always


Same scenario with a local home calendar works.

Comment 1

[Michael Büttner (no reviews TFN)]

Attachment: patch v1

The problem is that a modification on an item gets the old item as well as the new item (see [1] for the idl definition). The providers are free to rely on this fact, where WCAP does just that. Daniel introduced recently that only the differences of the items are send to the server. Unfortunately, it is likely that the new item is passed as both arguments (new/old). This happens if the item to be modified is mutable, since the old item only gets cloned if it is not mutable, see [2]. this results in the old item being modified and being passed to modifyItem, the same instance disguised with different variable names. The problem exists in the standard dialog as well in the prototype dialog.

[1] http://lxr.mozilla.org/seamonkey/source/calendar/base/public/calICalendar.idl#208
[2] http://lxr.mozilla.org/seamonkey/source/calendar/prototypes/wcap/sun-calendar-event-dialog.js#2191

Comment 2

[Michiel van Leeuwen (email: mvl+moz@)]

Comment on attachment 259673 [details] [diff] [review]
patch v1

r=mvl

Comment 3

[Michael Büttner (no reviews TFN)]

Checked in on trunk and MOZILLA_1_8_BRANCH

-> FIXED

Comment 4

[Andreas Treumann]

I checked this issue in the latest nightly build 2007040406 at Windows and linux. The task is fixed.

Comment 5

[Damian Szczepanik]

Litmus testcase 4439 created