Modifying recurring events in CALDAV calendars while offline doesn't work reliably (when 2 or more calendars)
Categories
(Calendar :: Provider: CalDAV, defect)
Tracking
(Not tracked)
People
(Reporter: bugs.mozilla, Unassigned)
References
Details
(Keywords: dataloss, regression)
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0
Steps to reproduce:
-
switch TB into online mode
-
create at least two CalDAV (tested against DAViCal) calenders in TB
- enable offline support
-
create recurring event in one of the calendars (e.g. weekly)
-
sync to server (to make sure)
-
switch to offline mode
-
delete just 1 event of the recurring event (e.g. the one next week)
-> event is not shown in TB anymore -
switch to online mode
-
sync to server (if not done automatically)
-
check on different device/client, whether the 1 deleted event is really gone
Actual results:
deleted event is still visible on different device/client
Expected results:
deleted event should not be shown anymore on different device/client
Reporter | ||
Comment 1•4 years ago
|
||
Everything was working as expected with TB 68.x and Lightning as a separate add-on.
Problem occurred after updating to Thunderbird 78.x with integrated calendar.
Problem can be reproduced with:
- TB 78.x (TB 78.6.0 as of this writing)
- DAViCal as calendar server (both versions 1.1.1 and 1.1.8)
The problem does not occur with just one calendar.
Setting both calendar.debug.log
and calendar.debug.log.verbose
to true
gives me following in the error console after having modified a recurring event (i.e. by removing one occurrence) offline and switching TB back to online mode:
Lightning: [calCachedCalendar] Performing playback operation add on 0 items to TESTTB Calendar calCachedCalendar.js:647
Lightning: [calCachedCalendar] Performing playback operation modify on 0 items to TESTTB Calendar calCachedCalendar.js:647
Lightning: [calCachedCalendar] Performing playback operation delete on 0 items to TESTTB Calendar calCachedCalendar.js:647
If doing the modification while permanently online the line with Performing playback operation modify on
correctly reports 1 items
.
Upon restart in the test case I created TB seems to finally sync the modification to the server. But that does not work for the setup where I encountered the bug (there are a lot more than just 2 remote calendars).
The workaround is to disable offline support for those calendars - but that's quite a nuisance.
Non-recurring events seem to work fine.
Reporter | ||
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Comment 2•4 years ago
|
||
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0
I may confirm Till Dörges issue (this Bug 1684359) on my agent as well. The way he describes the issue is the best one I found here and in other forums so far.
@lasana feel free to contact me in case you need additional inputs regarding the problem description.
I was following the Bug 1664731 which from my point of view is related and not comprehensively fixed.
Non-recurring events work fine.
Best, Stephan
Comment 3•4 years ago
|
||
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0
The original problem with the description of recurring events with no end (infinity) occured with the TB version update from 68.x to 78.x. In order to avoid backward compatibility problems I created new recurring events and performed modification activities like changing the description.
Steps to reproduce and (interim) outcomes:
- the following steps are performed directly in the TB calender (in contrary to directly on the calender on a mobile device)
- assure during reproduction that you UPDATE and only READ the mobile calender.
- Please see my corresponding comment at the end!
- CREATE NEW recurring event e.g. bi-weekly with no end date on Wednesday, starting on 3rd of February 2021 and wait until event is updated on the server and visible on the mobile device
- ADD individual description to a spezific event of recurring event (e.g. "hello world first" on 3rd of February 2021)
- SAVE changes to spezific event and check results in TB and on mobile device
Interim outcome:
In TB and mobile device
Expected outcome: individual description "hello world" appears in spezific calender event on 20th of February
Actual outcome MEETS expected outcome
- PRESS 'SYNCHRONIZE' button in TB calender
Interim outcome:
In TB and mobile device
Expected outcome: individual description "hello world" appears in spezific calender event on 20th of February
Actual outcome MEETS expected outcome
- ADD individual description to a spezific event of recurring event (e.g. "hello world second" on 20th of February 2021)
- SAVE changes to spezific event and check results in TB and on mobile device
Interim outcome:
In TB and mobile device
Expected outcome: individual description "hello world second" appears in spezific calender event on 20th of February
Actual outcome MEETS expected outcome
- PRESS 'SYNCHRONIZE' button in TB calender and check TB and on mobile device
Outcome (BUG identification):
In TB
Expected outcome: individual description "hello world second" DOESN'T appear in spezific calender event on 20th of February
Actual outcome DEVIATES from expected outcome in the way that it isn't displayed anymore
In mobile device
Expected outcome: individual description "hello world second" appears in spezific calender event on 20th of February
Actual outcome MEETS expected outcome
Conclusion: Changes (SAVING after ADDING descriptions) are successfully transferred to the server. After the synchronizing action the content of the description isn't displayed in thunderbird anymore, however the change is correct and available on the server and also correctly displayed on the mobile device.
@ step 3. DON'T perform any changes to events on the mobile device. If you do so it becomes really messy up to dataloss! I didn't go into that issue yet.
Best,
Stephan
Comment 4•4 years ago
•
|
||
I was able to reproduce this after some fiddling but it seems like the synchronization takes place if you restart Thunderbird.
Comment 5•4 years ago
|
||
Dear Lasana,
since I'm running TB 78.8.0 the above mentioned issue is solved.
However, there is another bug that remains unsolved. There is DATALOSS if I move a specific event of a recurring event series to another day. Here is the testcase on version TB 78.8.0
- create a recurring event with a description 'global note hello world' e.g. 12th of March on a weekly base
- SAVE & SYNCRONIZE
- MOVE specific event from 19th of March to 20th of March (doesn't matter whether via drag-n-drop or double clicking and manually changing the date for the specific event
- SYNCHRONIZE
in TB and on Mobile
Expected result: specific event on 2oth of March should contain the description 'global note hello world'
Actual result: specific event on 20th of March DOESN'T has an EMPTY DESCRIPTION
Conclusion: when changing the date of a specific event from the generic recurring event series the description is lost. Specific events of the same recurring event series, that WERE ALREADY changed (e.g. adding a specific description) ARE NOT affected!
Best, Stephan
Comment 6•4 years ago
|
||
(In reply to Stephan Richter from comment #5)
Dear Lasana,
since I'm running TB 78.8.0 the above mentioned issue is solved.
However, there is another bug that remains unsolved. There is DATALOSS if I move a specific event of a recurring event series to another day. Here is the testcase on version TB 78.8.0
- create a recurring event with a description 'global note hello world' e.g. 12th of March on a weekly base
- SAVE & SYNCRONIZE
- MOVE specific event from 19th of March to 20th of March (doesn't matter whether via drag-n-drop or double clicking and manually changing the date for the specific event
- SYNCHRONIZE
in TB and on Mobile
Expected result: specific event on 2oth of March should contain the description 'global note hello world'
Actual result: specific event on 20th of March DOESN'T has an EMPTY DESCRIPTIONConclusion: when changing the date of a specific event from the generic recurring event series the description is lost. Specific events of the same recurring event series, that WERE ALREADY changed (e.g. adding a specific description) ARE NOT affected!
Best, Stephan
Hi Stephan, thanks for the information. If this is the behavior you are still seeing, can you file another bug for this? Be sure to mention it's with the Caldav calendars. The local calendars have a different back-end I believe so it may not be the same cause as bug 1664731.
Comment 7•4 years ago
•
|
||
I can no longer reproduce the bug. Till Dörges are you still encountering this issue? I'll close if you are not.
Updated•4 years ago
|
Comment 8•4 years ago
|
||
I have been unable to reproduce this anymore and the reporter seems to have moved on. Closing for now.
Updated•4 years ago
|
Reporter | ||
Comment 9•4 years ago
|
||
Apologies for being unresponsive (many things to do and test environment not handy).
I just reproduced the issue with TB 78.11.0 against DAViCal 1.1.8-1+deb10u1.
Reporter | ||
Updated•4 years ago
|
Updated•3 years ago
|
Comment 10•3 years ago
|
||
Hi Martin,
I'm wondering why you opened this bug again? I tried to reproduce the original issue and everything works fine.
User-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.3.2
Best, Stephan
Reporter | ||
Comment 11•3 years ago
|
||
I just checked in my test environment (currently Thunderbird 78.13.0). The problem is still present:
If I create a recurring event with no end date and modify this event while offline (i.e. delete just one event of the series) this modification is not synced with the servers (i.e. is not shown on other devices).
Using non-recurring events work fine in my tests on all devices (with or without offline support).
Please note that I only encountered the problem when using at least two CalDAV calendars (one is not enough).
Comment 12•3 years ago
|
||
(In reply to Stephan Richter from comment #10)
Hi Martin,
I'm wondering why you opened this bug again? I tried to reproduce the original issue and everything works fine.
I did not re-open the bug report but changed its status from "REOPENED" to "NEW".
Comment 13•3 years ago
|
||
Recently I came across a strange issue where CalendarRefreshJob
s sometimes get stuck in the queue during testing causing timeouts. Clicking the synchronize button repeatedly and quickly enough cleared it up. According to this comment bug 872063 "has modified the behavior of setDateRange, which doesn't always refresh the view anymore".
That may not be related to this but I'm setting it as see also for now just in case.
Description
•