User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:220.127.116.11) Gecko/20071025 Firefox/18.104.22.168 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a9pre) Gecko/2007110306 Calendar/0.6a1 Saving a new Event or Task before using "Save and Close" creates a new Event/Task each time you save the it. Reproducible: Always Steps to Reproduce: 1. Push the New Task button in the toolbar. 2. Push File->Save or Ctrl+S in the new task window. 2.1 This creates the new Task. 3. Push File->Save or Ctrl+S again. 3.1 This creates another new task. Actual Results: Saving creates serveral new tasks/events. Expected Results: Saving should create ONE new task/events while saving the first time and then edit the new event.
Confirmed also with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:22.214.171.124pre) Gecko/20071103 Calendar/0.8pre
Status: UNCONFIRMED → NEW
Ever confirmed: true
Changing request flag into wanted. It can also be reproduced with 0.7
Flags: blocking-calendar0.8? → wanted-calendar0.8?
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.
Flags: wanted-calendar0.8? → wanted-calendar0.8-
All items have equal values for CREATED and DTSTAMP. LAST-MODIFIED and UID are different. Affected are events and items in all storage providers I tested: Storage DB, local ICS file and Google Provider
I tested this and it works for me, please reopen if the problem persists.
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → WORKSFORME
Reproducible using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:126.96.36.199pre) Gecko/20090830 Lightning/1.0pre Shredder/3.0b4pre with STR from comment#0.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Created attachment 432530 [details] [diff] [review] Fix - v1 This patch takes care. A new item doesn't have an id before it is saved, so the listener didn't save the item. Something I noticed here: if the server does any server-side changes to a newly added item, then the event dialog will not be updated to these changes (i.e loadDialog is not called after save). It would be quite simple to add a loadDialog call in the changed listener too, but this also means that if the user has a slow network connection and does more changes, they will probably be reverted when the item finally commits. Definitely something to fix in a different bug, and I can imagine the solution will be quite ugly.
Assignee: nobody → philipp
Status: NEW → ASSIGNED
Attachment #432530 - Flags: review?(ssitter)
Created attachment 432572 [details] [diff] [review] Fix - v2 Forgot to qref
Comment on attachment 432572 [details] [diff] [review] Fix - v2 As often, the solution of one bug points to another: Since we landed Bug 392021 in the meantime, the delete function has to be taken into account. If I save the event and then press the delete button, the window closes, but the event is not deleted. So the delete function also has to check if the Item has been saved in the meantime. r- because of this
Attachment #432572 - Flags: review?(ssitter) → review-
Created attachment 440173 [details] [diff] [review] Fix - v1 Setting the mode to modify helps
Attachment #440173 - Flags: review?(Mozilla)
Attachment #432572 - Attachment is obsolete: true
Comment on attachment 440173 [details] [diff] [review] Fix - v1 looks good. r=markus
Attachment #440173 - Flags: review?(Mozilla) → review+
Pushed to comm-central <http://hg.mozilla.org/comm-central/rev/88a7728b9305> -> FIXED
Status: ASSIGNED → RESOLVED
Last Resolved: 9 years ago → 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → 1.0b2
Pushed to comm-1.9.2 <http://hg.mozilla.org/releases/comm-1.9.2/rev/8f1a68311a5c> -> FIXED
You need to log in before you can comment on or make changes to this bug.