Closed Bug 1791228 Opened 2 years ago Closed 2 years ago

Reminder window not closing after reminders dismissed or snoozed

Categories

(Calendar :: Alarms, defect)

Thunderbird 102
defect

Tracking

(thunderbird_esr102+ fixed, thunderbird106 fixed)

RESOLVED FIXED
107 Branch
Tracking Status
thunderbird_esr102 + fixed
thunderbird106 --- fixed

People

(Reporter: wr63r5i9ft0h, Assigned: lasana)

Details

Attachments

(2 files)

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:104.0) Gecko/20100101 Firefox/104.0

Steps to reproduce:

Responded to Lightening Calendar reminders
Dismissed or snoozed all items either via Snooze/Dismiss All or individually

Actual results:

Empty reminder window did not then close (as it did with v92)
Had to close manually (I hope this is not an intended "dis-improvement" - why?)

Expected results:

Empty Reminder window should then have closed (as it did in v92 - I think I jump upgraded from v92 to v101)

Component: Untriaged → Alarms
Product: Thunderbird → Calendar

This seems to be happening because CalAlarmService keeps some calendars marked as "loading". Looking into it further.

I have figured out the reason for the dialog window remaining open and I think I know the cause of it. Can the reporter (or anyone else experiencing this) go to Help > Troubleshooting Information and tell me what calendar types they have listed? I suspect it's caused by older calendars created by the gdata plugin that's keeping the dialog open.

I have an older installation where this bug occurs and it seems I had several calendars of type "gdata" but the plugin was not installed. They may have been added when TB shipped with the google provider support. To get rid of this behavior you may have to remove the calendar and re-add it or update to the latest version of the plugin if you are still using it. Note: This applies for any other provider plugin that needs to be updated as well.

Wayne, I think this may be something to advise users about in the release notes rather than a bug fix.

Flags: needinfo?(wr63r5i9ft0h)
Flags: needinfo?(vseerror)

(In reply to Lasana Murray from comment #2)
Can the reporter (or anyone else experiencing this) go to Help > Troubleshooting Information and tell me what calendar types they have listed? I suspect it's caused by older calendars created by the gdata plugin that's keeping the dialog open.

I have various calendar types:
| Type | No | Comment |
| ics | //// | Public Holiday Calendars 3 from gov.uk one from mozilla.net |
| storage | /////////// | Created through TB - manually maintained |
| thunderbirthday | / | disabled - add-in no longer installed (probably redundant - replaced by birthdaycalendar |
| todotxt | / | disabled - via add-in no longer installed |
| ext-birthdaycalendar@rsjtdrjgfuzkfg.com | //// | via add-in birthdaycalendar@rsjtdrjgfuzkfg.com v1.1. 24 August 2022 |

Does that help? I am reading Type from the Troubleshooting box for each of my calendars

Flags: needinfo?(wr63r5i9ft0h)
Assignee: nobody → lasana
Status: UNCONFIRMED → NEW
Ever confirmed: true

(In reply to Cassandra from comment #3)

Does that help? I am reading Type from the Troubleshooting box for each of my calendars

Yes, thank you. If any of the add-on calendars were not updated to the latest calendar APIs you can run into this error. In retrospect, we can avoid the issue for calendars whose provider are no longer installed at least.

Flags: needinfo?(vseerror)
Status: NEW → ASSIGNED
Target Milestone: --- → 107 Branch

Pushed by geoff@darktrojan.net:
https://hg.mozilla.org/comm-central/rev/c75361130bfa
Add getItems() to base calendar provider. r=#thunderbird-reviewers,darktrojan

Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED

Comment on attachment 9295437 [details]
Bug 1791228 - Add getItems() to base calendar provider. r=#thunderbird-reviewers

[Triage Comment]
APproved for beta.
(lassna just asked me about it, so I assume it's good to go)

Attachment #9295437 - Flags: approval-comm-beta+

does the patch also apply to 102? (which I anticipate building this this week)

Flags: needinfo?(lasana)

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

does the patch also apply to 102? (which I anticipate building this this week)

Does not seem so. I'll do a 102 version.

Flags: needinfo?(lasana)
Attached patch esr102.patch — — Splinter Review

[Approval Request Comment]
User impact if declined: The alarm dialog will remain empty on 102 when empty until the user closes it.
Testing completed (on c-c, etc.): comm-central
Risk to taking this patch (and alternatives if risky): Low risk.

Attachment #9297029 - Flags: approval-comm-esr102?

Comment on attachment 9297029 [details] [diff] [review]
esr102.patch

[Triage Comment]
Approved for esr102

Attachment #9297029 - Flags: approval-comm-esr102? → approval-comm-esr102+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: