User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:70.0) Gecko/20100101 Firefox/70.0

Steps to reproduce:

(Version is Lightning 68.2.0, couldn't select in dropdown menu)

• Create recurring event in remote calendar (with location set)
• Open single occurrence to edit (the dialog box shows the location of the series)
• Add description and save

Actual results:

• The updated event lost its location information (I have to edit it again to add it again)

Expected results:

• The location should have been kept from the recurring event

More details, including versions, when it happens, how it affects import/export is here: https://support.mozilla.org/en-US/questions/1272332

From the linked forum post:

These are my software versions, although this problem has been persisted for a month:
Thunderbird Version: 68.2.1 (32-bit)
Lightning Version: 68.2.0
TbSync Version: 2.7

Dear community,

My weekly routine involves adding descriptions to recurring events. Before migrating to Thunderbird/Lightning (Remote Calendar via CalDAV hosting provider) from Outlook (Remote Calendar via Exchange/Office Enterprise), it was the easiest and quickest way to have detailed recurring events: The meeting itself is recurring, and always at the same location, just every week I add a description. The modified event itself was not part of the recurrence anymore, but that was fine.

Now, in Thunderbird, I run into this problem: If I have a recurrent event (with time and location set) and modify a single occurrence (adding a description), the modified occurrence will have "forgotten" its location. Even worse, while the editing dialog is still open, it will show the location, but when I then save and close it, the location is gone (both in the calendar view, and when I open it again).

The problem is appearing using both Lightning CalDAV as well as TbSync CalDAV.

If I change the description and the location for a single occurrence, it remembers both correctly.

If I use my web-based CalDAV interface from the hosting provider, editing a single occurrence keeps the location, and it also syncs back correctly to Thunderbird.

I have tried the same for local calendars and the problem is not appearing in this case.

Editing a single event keeps the location information correctly in Thunderbird 60.9.1 (32-bit) / Lightning 6.2.9.1.

If I export the local test calendar, which only includes the series as well as the modified event (and appears correctly in Lightning), the .ics file (attached below) does not contain the location information in the modified VEVENT. Importing it (even to another, local test calendar) also does not reload the location from the reoccurring event.

Cheers,

PBB

Hello,
a kindly reminder about this problem. Many of our users report this, is there any news?

We are using Thunderbird client updated to last available stable version (78.10.0 (64 bit)) and on server side we use Sogo calendar with caldav protocol.
On a recurrent event, if we modify a specific occurence and we inspect source code of that (ics), there is a correctly filled location field but we cannot see it in the Thunderbird calendar UI, but we still see it in next occurences of the event (i.e. next week).

Could you help us, please?

Thanks

When modifying an occurrence of a repeating event, we use a minimal copy of the event with not much properties. This is what is loaded in the various event dialogs. You would not notice the missing properties at first because they are sourced from the parent item in getProperty() once the occurrence has not been modified.

Once the event has been modified however, it's no longer considered a "proxy" of the parent event and those properties will not be available. What we send to remote calendars is the minimal event without the unmodified properties of the parent resulting in the exception missing some properties. I suspect this may also be the reason for some of the other caldav recurrence bugs I have been beaten up by.

We could probably avoid these kinds of bugs by refactoring item editing code to happen in one place (instead of all the cloning and item/parentItem re-assignments etc.), having a "single source of truth" as some call it.

Storage calendars are not affected because of the fix for bug 1664731 which retrieves all the properties for the occurrences. Basically every other kind of calendar is affected including the local ics one.

Ok so what's actually taking place here is that this line here:
https://searchfox.org/comm-central/source/calendar/base/src/calItemBase.js#1141

overrides this line here:
https://searchfox.org/comm-central/source/calendar/base/src/calItemBase.js#446

to provide the properties of an item. The former does not take into consideration that the item may be a recurring event or rather a "proxy" and some of its properties are sourced from the parent object (the latter does). Because of this, we end up sending only some of the properties to remote servers and even ics files when an event has been modified, resulting in data loss.

Thanks for looking into this, and keeping us posted about what's the culprit!

Because of how deep this bug goes, and that it influences ics files, I think it's then actually also related to the other bug I reported back then (https://bugzilla.mozilla.org/show_bug.cgi?id=1595334), so I added it to this bug as a "See Also".

Pushed by thunderbird@calypsoblue.org:
https://hg.mozilla.org/comm-central/rev/005b8b023593
Use the real properties getter to provide the properties of recurring events. r=darktrojan

The tests do not like this. Specifically calendar/test/browser/eventDialog/browser_eventDialogEditButton.js and calendar/test/browser/recurrence/browser_weeklyWithException.js complain that Property X-MOZ-GENERATION not set. X-MOZ_GENERATION is a number that increments every time an event changes, so that if you have two copies you know which is the later copy. There are XPCShell test failures too.

I'm not sure quite what's causing this failure, so I'm going to back it out until it's figured out.

Backed out:
https://hg.mozilla.org/comm-central/rev/77acd01883a526dbbc4619b95d4d00d48a646e19

Made a change to getParameterNames() and updated a test.

Pushed by geoff@darktrojan.net:
https://hg.mozilla.org/comm-central/rev/3787e583daf7
Use the real properties getter to provide the properties of recurring events. r=darktrojan

Comment on attachment 9231671 [details]
Bug 1595332 - Use the real properties getter to provide the properties of recurring events. r=darktrojan

[Triage Comment]
Taking for 91b4.

Thunderbird 91.0b4:
https://hg.mozilla.org/releases/comm-beta/rev/3ed31b89f582