Closed Bug 1709055 Opened 3 years ago Closed 3 years ago

Can not dismiss repetitive modified CalDav event notification

Categories

(Calendar :: Alarms, defect)

Product:
Calendar
Component:
Alarms
Version:
Thunderbird 78
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 1595332

People

(Reporter: haertl.mike, Unassigned)

References

Details

Attachments

(1 file)

Error log with private data replaced by ***
9.01 KB, text/plain
Details

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.93 Safari/537.36

Steps to reproduce:

  • I received an .ics invitation via E-Mail.
  • I accepted the invitation
  • I received a modification for that event
  • I accepted the update to the existing event

I'm unsure if the last 2 steps are really neccessary.

This has worked before and seems to have started with some 78.x Version. I'm currently using 78.10.0 on Linux Mint.

Actual results:

  • The reminders for the event can not be dismissed. I can only close the reminder window.
  • The reminder comes up again and again after some minutes

Expected results:

  • I should be able to dismiss the reminder notification

I forgot to mention:

  • I have configured a CalDAV calendar to connecto to my Google Calendar via the CalDAV API-URL
  • After the error occurs I can not remove that calendar anymore. The "Unsubscribe calendar" in the context menu is grayed out.

The issue perists:

  • The behavior described above continued for some days. A notification came up every couple of minutes and I had to click the "x" to close it. Then it stopped.
  • Now the issue is back at another repetitive event

I'm surprised to see no reaction on this issue, given that I tried to give as much information as I can. I'm also very willing to help with any further debugging.

@Lasana I found you are active on some other issues, so maybe you can help out: Is this project still maintained? Or is there a better place to report problems?

Flags: needinfo?(lasana)

(In reply to haertl.mike from comment #2)

...
I'm surprised to see no reaction on this issue, given that I tried to give as much information as I can. I'm also very willing to help with any further debugging.

@Lasana I found you are active on some other issues, so maybe you can help out: Is this project still maintained? Or is there a better place to report problems?

Hello. If by this project you mean Thunderbird, then yes. :) This is the place to report bugs but there is only so much of us on the core team and a lot of bugs to handle. It can sometimes take a while before issues are addressed.

Flags: needinfo?(lasana)

@Lasana Thanks. I actually meant the Calendar project. I see many issues here that are not adressed.

Some update:

  • Even though the repetitive event had 3 dates in the past I still get notifications that I can not dismiss.

I'm afraid that I will not be able to provide more debug information once the issue heals itself like it did last time. So any hint how I can provide more useful information is very welcome.

Confirming this happens, I'm not sure why yet but looks like the reminders come back on each refresh. I suspect the fact that we dismissed the alarm may be lost at the server but I need to look into this further.

Edit: Yup, this is not happening with my fastmail account but it does with my gmail.

Assignee: nobody → lasana
Status: UNCONFIRMED → NEW
Ever confirmed: true

Their API guide states that it "Does not support arbitrary (user-defined) WebDAV properties." so if we are storing that the alarm was dismissed in the event it may be that it gets lost on the server. If that's the case, it will be difficult for us to do anything as we have to keep in sync with what the server reports.

https://developers.google.com/calendar/caldav/v2/guide

But then why has this worked before in older versions of Calendar?

Also is there a way that I can verify if this is really causing my problem? I know how to use the debugger but not sure where to look or what to look for.

(In reply to haertl.mike from comment #7)

But then why has this worked before in older versions of Calendar?

I can't say for sure, maybe someone with more experience can. I tested with a copy of 68 and got the same behavior.

Also is there a way that I can verify if this is really causing my problem? I know how to use the debugger but not sure where to look or what to look for.

If you look at the traffic on the network tab you'll see a PUT followed by a REPORT request each time you attempt to dismiss the dialog. The outgoing PUT includes a X-MOZ-LASTACK which indicates when we acknowledged the alarm. If you look at the REPORT response you'll see that property missing.

Not sure there is much we can do here except either lobby Google to preserve custom properties or perhaps start storing them locally (in sqlite) and reconciling with the server on sync. I believe that Google Calendar not storing some properties is an already known issue?

Flags: needinfo?(geoff)
Flags: needinfo?(philipp)

Weird if this works for events (it does) but not invitations. We store alarm_last_ack in the cal_events table, so maybe that's not happening for invitations.

Flags: needinfo?(geoff)

But then why has this worked before in older versions of Calendar?

I can't say for sure, maybe someone with more experience can. I tested with a copy of 68 and got the same behavior.

I didn't know that invitations are handled differently (at least that's how I read Geoff's comment). So it's very well possible that I never received an invitation with a recurring event before. So this probably also never worked before for me. Dismissing my own recurring events always worked and still does.

FWIW I did a bit of naive debugging and inspected some the DBs in my profile's calendar-data directory. I found the problematic event in the cache.sqlite DB's cal_events table and indeed its alarm_last_ack is NULL.

See Also: → 356002
Flags: needinfo?(philipp)
See Also: → 1666156
See Also: → 1691885

Ok what I have learned so far, is that it appears that Google will preserve the custom properties if you are the organizer of the event. This is usually not the case for invitations hence this not happening with own events.

We store alarm_last_ack in the cal_events table, so maybe that's not happening for invitations.

It looks to me that the way the caching is implemented, the cache will be replaced with the result of updating the server. This makes sense for avoiding conflicts but could get in the way if the server does not give us back all our properties.

https://searchfox.org/comm-central/rev/6c2198602b5c9fca956173df16c8a948d653a213/calendar/base/src/calCachedCalendar.js#830

For this bug I'm going to have the cached calendar restore lost X-MOZ properties from the cache, I'm thinking that should be safe because that's a Thunderbird specific prefix.

Status: NEW → ASSIGNED

Sigh, too much indirection for me to figure out what's going on here. I'm not sure where to actually preserve the property. I'll have to come back to this. If anyone knows what's going on, feel free to chime in.

Assignee: lasana → nobody
Status: ASSIGNED → NEW
See Also: → 1595332

The patch for bug 1595332 should fix this. I tested locally

Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: