User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:80.0) Gecko/20100101 Firefox/80.0

Steps to reproduce:

• Repeatedly restarted Thunderbird
• Restarted machine
• Waited until next event with a reminder to pop up
• Created new events with reminders

Actual results:

Reminders would not dismiss unless the reminder in question was removed from the event in the calendar.

Expected results:

Event reminder should have dismissed.

(Note: Thunderbird version 78.2.2 (64-bit) on Macbook Pro running macos Catalina version 10.15.6)

I am experiencing the same problem with trying to dismiss reminders with a different service provider.
Calendar events with for a CalDAV synchronised calendar do not be dismissed and continue to pop up.

Thunderbird 78.3.2 (32-bit)
Calendar via: zoho.com
The calendar correctly synchronises events in the calendar.
Workarounds: edit the event to remove the reminder or delete the event
I did not have this problem with Thunderbird v68.x.x and it is not related to a specific CalDAV calendar or account.

Steps to reproduce:
Add the CalDav Calendar: (File>New>Calendar>On the Network>Select CalDAV>Enter username & the location e.g. https://calendar.zoho.com/caldav/<calendar ID>/events >Enter the password)
Add an event (Today) say now + 7 minutes with a reminder for 5 minutes.
When the reminder pops up, try to dismiss (click 'Dismiss' or 'Dismiss All' or 'Snooze for (5min)' or 'Snoose All for (5min)')
The reminder disappears for about 1 second but then pops back up. Similarly if just closing the reminder window, it just pops back up.

Thunderbird Console error log

I attached an file with some console log events that may or may not be relevant.
Synopsis:
Lightning: Parsing failed for parts of the item
No value for DESCRIPTION property.
No value for LOCATION property.
Parse error in property name: IMPORTANT

Got a VALUBEGIN:VALARM
ACTION:DISPLAY
TRIGGER;VALUE=DURATION;RELATED=START:-PT5M
X-LIC-ERROR;X-LIC-ERRORTYPE=PARAMETER-VALUE-PARSE-ERROR:Got a VALUE parameter with an illegal type for property: VALUE=DURATION
END:VALARME parameter with an illegal type for property: VALUE=DURATION

All these bugs seem to be describing the same problem. Not sure how to mark them as duplicates here so I'm listing them here.

bug 1634617
bug 1655245
bug 1666156
bug 1667087
bug 1670526
bug 1673219

(please use bug NNNN format)

I was going to file this as well, this is very annoying...

Will take care of duping.

I'm still having a problem, but not sure it's the same. The symptom is the same but I'm also seeing a 403 error in the log:

16:51:16.828 Lightning: [calGoogleCalendar] Modifying item EVENT (master item) gdataCalendar.jsm:467
16:51:16.830 Lightning: [calGoogleRequest] Requesting PATCH https://www.googleapis.com/calendar/v3/calendars/USER%40gmail.com/events/EVENTID gdataRequest.jsm:206
16:51:16.831 Lightning: [calGoogleCalendar] Setting Upload Data (application/json; charset=UTF-8):
{"start":{"dateTime":"2020-05-11T15:00:00","timeZone":"America/Los_Angeles"},"end":{"dateTime":"2020-05-11T15:15:00","timeZone":"America/Los_Angeles"},"summary":"EVENT","description":"<a href=\"LINK</a>","status":"confirmed","reminders":{"overrides":[{"method":"popup","minutes":0},{"method":"popup","minutes":10},{"method":"popup","minutes":30}],"useDefault":false},"extendedProperties":{"private":{"X-MOZ-LASTACK":"2021-01-24T00:51:16Z","X-GOOGLE-SNOOZE-RECUR":"{\"1587679200000000\":\"20200522T230719Z\",\"1608073200000000\":\"20210115T070204Z\"}"}},"recurrence":["RRULE:FREQ=DAILY","EXDATE:20200808T220000Z"]} gdataRequest.jsm:273
16:51:16.832 Lightning: [calGoogleCalendar] Sending request headers: ({}) gdataRequest.jsm:302
16:51:17.130 Lightning: [calGoogleCalendar] Request PATCH https://www.googleapis.com/calendar/v3/calendars/USER%40gmail.com/events/EVENTID responded with HTTP 403 gdataRequest.jsm:383
16:51:17.131 Lightning: [calGoogleCalendar] Login failed for USER HTTP Status: 403 Reason: forbidden gdataRequest.jsm:416
16:51:17.132 Lightning: [calGoogleCalendar] Modifying item EVENT failed:2147500037: {
 "error": {
  "errors": [
   {
    "domain": "global",
    "reason": "forbidden",
    "message": "Forbidden"
   }
  ],
  "code": 403,
  "message": "Forbidden"
 }
}
gdataCalendar.jsm:567

​
I'm able to view/add/remove events and some other event reminders have no problems being dismissed

Using https://addons.thunderbird.net/en-US/thunderbird/addon/provider-for-google-calendar/

Duplicate of: bug 1634617

presumably a regression?
can someone find it? https://mozilla.github.io/mozregression/

Could this bug depends on Bug 1560151 ?

Have same problems for last 3 weeks or so. Is this a corrupt cache or caused by a missed update of Lightening?

(In reply to ronward from comment #15)

Have same problems for last 3 weeks or so. Is this a corrupt cache or by a missed update of Lightening?

Suspect V78.6.1 11th Jan 2021 update possible cause.

I have a similar problem in TB 85.0b3 (x64) with CalDAV network calendar (ReadOnly OFF, Show Reminders ON, Offline Support OFF).

If I dismiss an event reminder, it disappear, but then after few seconds it would re-appears in the Reminders windows. If I dismiss it again, then it disappears.

Here is a perf profile recorded when dismissing twice the event reminder if that can help finding the root cause...
https://share.firefox.dev/3a31HXE

I encounter this issue with Thunderbird 78.7.0 (Debian package). This issue doesn't occur with 78.5.0.

(In reply to Wayne Mery (:wsmwk) from comment #13)

presumably a regression?
can someone find it? https://mozilla.github.io/mozregression/

Does mozregression allow to bisect using ESR releases (https://archive.mozilla.org/pub/thunderbird/releases/) ?

Not sure what's causing this problem but it has been going on for years but does not seem to effect everyone. But I don't and don't want to link to Goggle as I consider it public domain and bug ridden. Maybe it's the 32bit version that i'm using? Why has it started now after including Lightening?

Hi u670291 and Ronward,

(In reply to ronward from comment #15)

Have same problems for last 3 weeks or so. Is this a corrupt cache or caused by a missed update of Lightening?

What type of network calendar are you using? CalDAV?

Is the Offline Support option in Calendar property ticked (enable) or unticked (disabled)?

My first attempt at mozregression finding failed as I could not reproduce the issue, until I found out in my case on Windows, I have noticed the issue seems to only appear when Offline Support is unticked (disabled) basically when working with the CalDAV network calendar in online mode.

Do you get the same behaviour if offline support is ticked or not?
Or like me you get it only if Offline Support is unticked (disabled)?

@Ronward,

• Which version of TB are you using?
• On which platform (win, mac, linux)?

Regards,

Here are the steps to reproduce the issue with TB 85.0b3 (x64) on Windows 10 and some earlier versions of TB as per mozregresion test for period 2020-11-01 till 2021-01-31 (all affected).

With CalDAV network calendar setup with the following properties:

• ReadOnly OFF
• Show Reminders ON
• Offline Support OFF

1. Look at the current date and time (e.g 02/02/2021 5pm)
2. Create a new calendar event tomorrow with a start time before current time e.g 3pm
3. Set a reminder that would cause the event to pop up in the reminder window immediately - e.g 1 day before
4. Save and close the event
5. The reminder windows appears shortly after with the event ready to be snooze or dismissed
6. Press Dismissed button on the event you just created
7. Event disappear for while (if it was the only one in the last, the reminder window also disappear)
8. Wait a bit
9. The reminder window re-appear with the same event ready to be snooze or dismiss again
10. Dismiss it again so it disappear (as well as reminder window if only one in the list)
11. Wait a bit
12. The reminder window do not re-appear and your are no longe reminded about the event...

Did not found the mozregression yet but the above should help investigate further...

If your reproduce the same step with Offline Support ticked (enabled):

1. When created and saved the event is automatically dismissed while it should not
2. If you edit event and change the reminder to '2 day before' then save and close, the event appear in the reminder window
3. If you dismiss it, it disappear and do no longer re-appear

So behaviour seems not consistent between online and offline mode, one would expect that in both cases when event is created it should appear in reminder window immediately, and once dismissed, disappear for good.

(In reply to pilou from comment #19)

I encounter this issue with Thunderbird 78.7.0 (Debian package). This issue doesn't occur with 78.5.0.

(In reply to Wayne Mery (:wsmwk) from comment #13)

presumably a regression?
can someone find it? https://mozilla.github.io/mozregression/

Does mozregression allow to bisect using ESR releases (https://archive.mozilla.org/pub/thunderbird/releases/) ?

I think so. An example for command line usage would be
mozregression --repo comm-esr78

But a regression range against comm-central (nightlies) would be equally helpful

(In reply to Richard Leger from comment #14)

Could this bug depends on Bug 1560151 ?

Perhaps, but I don't know. Perhaps Geoff has a keener eye.

(In reply to Richard Leger from comment #21)

Hi u670291 and Ronward,

(In reply to ronward from comment #15)

Have same problems for last 3 weeks or so. Is this a corrupt cache or caused by a missed update of Lightening?

What type of network calendar are you using? CalDAV?

Is the Offline Support option in Calendar property ticked (enable) or unticked (disabled)?

My first attempt at mozregression finding failed as I could not reproduce the issue, until I found out in my case on Windows, I have noticed the issue seems to only appear when Offline Support is unticked (disabled) basically when working with the CalDAV network calendar in online mode.

Do you get the same behaviour if offline support is ticked or not?
Or like me you get it only if Offline Support is unticked (disabled)?

@Ronward,

• Which version of TB are you using?
• On which platform (win, mac, linux)?

Regards,

V78.7.0 (32 bit)
Win10 64bit

I run a bisection but it seems mozregression was not able to find enough data to bisect...

Though in the attachment you would find the time frame when issue start to appear...

• red one version are affected by the issue
• green one not affected by the issue...

Hope that may help the dev team find the culprit...

OK
app_name: thunderbird
build_date: 2020-11-23
build_file: C:\Users\richard.mozilla\mozregression\persist\2020-11-23--comm-central--thunderbird-85.0a1.en-US.win64.zip
build_type: nightly
build_url: https://archive.mozilla.org/pub/thunderbird/nightly/2020/11/2020-11-23-10-54-30-comm-central/thunderbird-85.0a1.en-US.win64.zip
changeset: 4bf90269ae49c565041017b4064c59e08dd6546f
pushlog_url: https://hg.mozilla.org/comm-central/pushloghtml?fromchange=4bf90269ae49c565041017b4064c59e08dd6546f&tochange=d2dcf467b8f9c138a09bcf24fe6d3be241d68e74
repo_name: comm-central
repo_url: https://hg.mozilla.org/comm-central

KO
app_name: thunderbird
build_date: 2020-11-25
build_file: C:\Users\richard.mozilla\mozregression\persist\2020-11-25--comm-central--thunderbird-85.0a1.en-US.win64.zip
build_type: nightly
build_url: https://archive.mozilla.org/pub/thunderbird/nightly/2020/11/2020-11-25-10-14-35-comm-central/thunderbird-85.0a1.en-US.win64.zip
changeset: d2dcf467b8f9c138a09bcf24fe6d3be241d68e74
pushlog_url: https://hg.mozilla.org/comm-central/pushloghtml?fromchange=4c8d82dc0948dd9aaedbc9e21f63ef5f8d96736c&tochange=d2dcf467b8f9c138a09bcf24fe6d3be241d68e74
repo_name: comm-central
repo_url: https://hg.mozilla.org/comm-central

(In reply to Wayne Mery (:wsmwk) from comment #24)

(In reply to Richard Leger from comment #14)

Could this bug depends on Bug 1560151 ?

Perhaps, but I don't know. Perhaps Geoff has a keener eye.

Hi Geoff,

Looking at what changed during the period https://hg.mozilla.org/comm-central/pushloghtml?startdate=2020-11-23&enddate=2020-11-26 I am wondering if the issue may come from: Ping Chen — Bug 1514666 - Replace nsISAXXMLReader with DOMParser in CalDavRequestHandlers. r=mkmelin,darktrojan (https://hg.mozilla.org/comm-central/rev/d2dcf467b8f9c138a09bcf24fe6d3be241d68e74)?

Regards,
Richard

Question for … anyone really: does the problem go away if the pref calendar.icaljs is set to true?

Compare the timestamp of comment 4 with bug 1514666 comment 16, this can't be regressed by bug 1514666.

(In reply to Ping Chen (:rnons) from comment #29)

Compare the timestamp of comment 4 with bug 1514666 comment 16, this can't be regressed by bug 1514666.

What about if you compare with bisection in Comment 26?

(In reply to Geoff Lankow (:darktrojan) from comment #28)

Question for … anyone really: does the problem go away if the pref calendar.icaljs is set to true?

I re-run the same bisection (new profile re-use) as in Comment 26 and in the first version of TB encountering the issue, this value is already set to True (which seems the default value). That is also the case in other version of TB not affected by the issue. So this value set to True would not fix it.

Here are some perf profiles if that can help...

from TB 85.0a1-2020-11-22-64-bit not affected by the issue - save new event once, reminder appear once, dismissed once
https://share.firefox.dev/2MWA0YH

from TB 85.0a1-2020-12-02-64-bit affected by the issue (since 2020-11-25-10-14-35) - save event once, reminder appear once, dismissed twice
https://share.firefox.dev/3oTexx0

(In reply to ronward from comment #15)

... Is this a corrupt cache or caused by a missed update of Lightening? (sic)

If I am not mistaken, there is no separate update of "Lightning", as that no longer exists. It is now just Thunderbird; so the answer would be no.

(In reply to ronward from comment #25)

(In reply to Richard Leger from comment #21)

Hi u670291 and Ronward,

(In reply to ronward from comment #15)

Have same problems for last 3 weeks or so. Is this a corrupt cache or caused by a missed update of Lightening?

What type of network calendar are you using? CalDAV?

Is the Offline Support option in Calendar property ticked (enable) or unticked (disabled)?

My first attempt at mozregression finding failed as I could not reproduce the issue, until I found out in my case on Windows, I have noticed the issue seems to only appear when Offline Support is unticked (disabled) basically when working with the CalDAV network calendar in online mode.

Do you get the same behaviour if offline support is ticked or not?
Or like me you get it only if Offline Support is unticked (disabled)?

@Ronward,

• Which version of TB are you using?
• On which platform (win, mac, linux)?

Regards,

V78.7.0 (32 bit)
Win10 64bit

The problem has been resolved by Thunderbird 78.8.0 (20210217204255) Installed on 24 Feb 2010 07:58:41
I hope as it's all working OK.

After updating to TB 78.8.0 (64 bit) on macOS 10.15.7 it works fine now. Thank you!

It also works fine in TB 87.0b1 (64-bit) on Windows 10.