I cannot say if that issue occurs for 1 week or 1 month, just that it 90% was introduced some time in September or October 2025. I usually snooze some (often more than 10 in parallel) appointments to the next 2 hours over the course of days or sometimes weeks, and process them when I have some time to spare. Some time ago, I opened my Thunderbird in the morning and no appointments had been there. I knew for sure several that should have been shown. However, I expected I just accidentally clicked "dismiss all" or so and no longer considered it (so don't know for sure the exact time). But I then saw that regularly appointments I snoozed disappear, usually not immediately when I snooze them the first time, but usually the next day. So in the evening, I snooze them once more, and in the morning they are gone. I thought first the persistent constant is the "day" or so, but then I tested more explicitly with two test appointments: I snoozed them around 5 times. Once in between, I closed Thunderbird and re-opened it immediately. It always reappeared at the expected time, also in the latter case. But once I kept Thunderbird closed at the very moment the reminder should have opened again, and opened Thunderbird 5 minutes after that instead, the reminders were lost and no longer appeared. I expect this is why the reminders of the night disappear, as the 2 hours I snooze will be over before Thunderbird is reopened the next morning. However, when I tried to quickly reproduce this again, one appointment, snooze it the first time, close Thunderbird and wait until the reminder should be opened and open Thunderbird AFTER the reminder should have been opened, the reminder still was there at this one quick test. Today, I tested again: one appointment, snoozed 5 minutes, it reopened as it should, then I snoozed again 5 minutes and then I closed Thunderbird for 6 minutes (so one minute more), and reopened it: its lost again. At this final test, I ran Thunderbird through the terminal, but it does not contain any output except at some time the (in my opinion unrelated line) "Crash Annotation GraphicsCriticalError: |[0][GFX1-]: RenderCompositorSWGL failed mapping default framebuffer, no dt (t=99.8309) [GFX1-]: RenderCompositorSWGL failed mapping default framebuffer, no dt". Another interesting phenomenon: I had a reminder of one appointment that got lost during the day (called for reminder 12 hours earlier) with the others. But at the very moment of the appointment, the reminder was opened again. To avoid false presumptions in the troubleshooting: I cannot exclude due to the nature of this very appointment that I dismissed it at the first reminder and so that the issue is that it was re-opened despite dismissal instead of snoozing with subsequent unintended disappearing and then reappearing at the time of the appointment (cannot say for sure which of the two). Most reminders I use are snoozed beyond the very time of the appointment. So I would not experience a reappearance at the very time of the appointment usually anyway given that that time is already passed when the disappearance takes place. As mentioned I can say for sure 100% only at this time that when the machine shuts down in the evening and boots at the next morning, all reminders that I shift with 2 hours are gone, and I think I have not yet isolated / reproduced the exact condition that provokes the phenomenon. The issue seems to not impact if and when reminders are opened the first time: issues start with snoozing. I consider this severe as people might not recognize the issue and miss appointments or forget about things. It is a matter of the user how severe consequences of this could be. Unlikely to be related, but when I just closed the GUI-opened Thunderbird and tried to open my Thunderbird through a terminal to produce the final test with logs for you, the calendar mixed US with German calendar layout, and Sunday became the first day of the week rather than Monday. When I opened it again through the GUI-button, the layout was again a week beginning on Monday (I presume a locale issue, unlikely related, but mentioned for your consideration, just in case). As mentioned in the tests, both ways of opening Thunderbird seem affected anyway. It does not correlate in time, but for some (about) months Thunderbird suffers from strong performance issues. From one moment to the next, I opened Thunderbird and it started to take several seconds to open the calendar and it regularly freezes several seconds in the beginning. Creating and opening appointments takes several seconds (it feels like up to half a minute) in the beginning, but once the Thunderbird calendar is open and one or two appointments had been opened, it works (my feeling is that it is always two calendar-related actions that freeze after opening Thunderbird, and then it works). I didn't report as I have not much time, but this one is unfortunately more severe. The user journal logs of the current boot for `journalctl -r --boot=0 | grep thunderbird` (to avoid to miss anything that mentions thunderbird), which includes the final test, are (Due to the test I opened and closed Thunderbird more often than usual): ``` Oct 12 13:18:16 fedora thunderbird[24793]: Locale not supported by C library. Oct 12 13:18:16 fedora thunderbird[24793]: Using the fallback 'C' locale.: 'glib warning', file /builddir/build/BUILD/thunderbird-140.3.0-build/thunderbird-140.3.0/toolkit/xre/nsSigHandlers.cpp:201 Oct 12 13:18:16 fedora thunderbird[24793]: [24793, Main Thread] WARNING: Locale not supported by C library. Oct 12 12:20:40 fedora thunderbird[7060]: Crash Annotation GraphicsCriticalError: |[0][GFX1-]: RenderCompositorSWGL failed mapping default framebuffer, no dt (t=120.183) [GFX1-]: RenderCompositorSWGL failed mapping default framebuffer, no dt Oct 12 12:18:40 fedora thunderbird[7060]: Locale not supported by C library. Oct 12 12:18:40 fedora thunderbird[7060]: Using the fallback 'C' locale.: 'glib warning', file /builddir/build/BUILD/thunderbird-140.3.0-build/thunderbird-140.3.0/toolkit/xre/nsSigHandlers.cpp:201 Oct 12 12:18:40 fedora thunderbird[7060]: [7060, Main Thread] WARNING: Locale not supported by C library. ``` A comparison to a boot from April: ``` May 05 00:34:17 fedora thunderbird[18357]: Locale not supported by C library. May 05 00:34:17 fedora thunderbird[18357]: Using the fallback 'C' locale.: 'glib warning', file /builddir/build/BUILD/thunderbird-128.10.0-build/thunderbird-128.10.0/toolkit/xre/nsSigHandlers.cpp:187 May 05 00:34:17 fedora thunderbird[18357]: [18357, Main Thread] WARNING: Locale not supported by C library. ``` Let me know if you need more data or if I shall test something specific. Reproducible: Sometimes Steps to Reproduce: Elaborated above, as far as possible. Reproducible not always / exact conditions not yet identified/isolated, though in some rough conditions it can be reproduced almost for certain (still reminders existing in the evening, snoozed for 2 hours, and thunderbird reopened the next morning many hours later). As the title says, 1 "constant" that is always there, when the issue occurs, is that TB is closed during the exact time the snoozed reminder is to be opened again, but this "constant" on itself does not always reproduce the bug. At least in one test it did not (though I now consider the possibility that the Thunderbird is sooooo much slower than my clock that I accidentally opened Thunderbird before its own clock would have called the reminder of the test in which the condition did not lead to the bug: maybe the performance issues are here also involved, not sure). Actual Results: After some snoozes, reminders of appointments no longer appear, get lost and the user does not know about it Expected Results: Reminders of appointments disappear only after the user dismissed them Additional Information: My Fedora is up to date (F42 KDE), I update everything daily. I use only one calendar, which is a sqlite of Thunderbird in the backend. Current version: Name : thunderbird Epoch : 0 Version : 140.3.0 Release : 1.fc42 Architecture : x86_64 Installed size : 321.3 MiB Source : thunderbird-140.3.0-1.fc42.src.rpm From repository : updates
Minor update due to a behavior that has not yet occurred in the very manifest: I had today three appointments for 12:00 (system time), all should have been reminded 2 hours earlier. I booted my Fedora, logged in and started Thunderbird within 5 minutes after booting, so between 11:16 and 11:20 (user logs begin at 11:15:53). However, Thunderbird did not remind me of any of the three. Nevertheless, at or after 12:00 (I assume it was exactly 12:00 but didn't see the reminder immediately on its screen), so the time of the appointments, all three have been reminded.
The issue worsened after the upgrade to F43. The same for the performance issues, which I aim to write a dedicated report if no one else does, but can barely spare time at the moment: Thunderbird now needs at least 2 seconds for every click to process (for some actions much more, up to half a minute so far), and takes the majority of CPU computation in this time. E.g., opening an email takes 2 seconds and seems to need a lot to process according to `top`. Just moving the cursor over the email list without clicking anything also takes massive amounts of computation power from the CPU, and it takes also about 2 seconds until an email the cursor is upon is highlighted with the slight grey background that indicates the very email that would be opened in the current cursor position. At this time, I can rely that only appointments are called that occur at the very moment Thunderbird is open (may they have been snoozed before, or are now reminded for the first time). So even if an appointment has not been reminded yet at all (so no snoozes yet), it will not be reminded at a later time if Thunderbird is closed at the very moment the reminder is set. However, I also experienced increased issues with Firefox, worsened performance and it always crashes when I try to save a PDF. Don't know if and how far the two use a common backing as of today, so I mention it. Now I'm on Name : thunderbird Epoch : 0 Version : 140.3.0 Release : 1.fc43 Architecture : x86_64 My hardware is an AMD Ryzen 7 PRO 6850U (= 6800U with some additions) with 8 cores / 16 threads and 32 GB LPDDR5 (6400 MT/s), so this machine should not be vulnerable to performance issues of that type.
Supplement: Since the upgrade to F43, the header of the window is broken too: the three buttons on the top right to minimize, maximize and quit are no longer visible. They still exist and can be clicked and work, but there is no sign except I sweep with the mouse over it, then the respective button the mouse is on becomes a grey circle, while the sign for minimize, maximize or quit remains hidden, so its then an empty grey circle. Due to BZ#2412225 , I cannot upload a screenshot because the button to upload the file in bugzilla leads to a crash of Firefox. However, Firefox is not affected by the hidden three buttons.
I have tested the upstream Thunderbird build (thunderbird-144.0.1.tar.xz) from Mozilla as suggested in https://fedoraproject.org/wiki/How_to_debug_Firefox_problems#Testing_Mozilla_binaries When I started it, it created a new profile and I tested it: the performance issues are the same as at the Fedora Thunderbird build (default thunderbird from Fedora repositories; no flatpak or so). Then I closed it, copy/pasted all files from my real profile to the profile of the upstream build (I removed all files of the old profile before that). Then I started that in order to test the reminders & snoozes: while the design of the upstream build remains a little different to that of the Fedora build, everything else behaved exactly the same. So, still the severe performance issues and the reminders / snoozes are broken. I tested it several times with the upstream build and was using it throughout last evening and then today in the morning without using the Fedora build in between. I returned to the Fedora build when all snoozed reminders of yesterday were not invoked in today's morning. The new reminders whose appointments have already passed some time when I opened it the first time were not invoked too. So the very same as the Fedora build.
I identified another indication that BZ#2412225 and BZ#2403355 might be the same issue, or at least overlapping: I have not used this function for long, but today I wrote an email with thunderbird and wanted to attach a file: at the moment I clicked this, it took the usual 2-3 seconds to process the click, and then thunderbird crashed -> so it crashed the moment a file manager should have opened to select the file that was to be attached.
Is someone working on this at the moment? I am aware that this issue is not widespread and therefore other issues might be more urgent, so I can understand if maintainers have to emphasize other tickets, but it would be good to know if that is the case and therefore if I need to find alternatives, as BZ#2412225 and BZ#2403355 are seriously hindering my workflow.
Created attachment 2116189 [details] coredumpctl debug 5222 |& tee backtrace.log While I am not sure if the disappearing of reminders, the massive performance issues and the crashes when I try to attach a file are the same issue (only the last of the three symtpoms reproduces equally in BZ#2412225), it seems coredumpctl is able to document the crashes of thunderbird but not those of firefox. I attach the output of a crash of thunderbird from the moment the file manager should have opened after I clicked on "attach" in an email draft (it is the same file as the file I just uploaded in BZ#2412225). The file is the output from the command `coredumpctl debug 5222 |& tee backtrace.log`.
While BZ#2412225 has been effectively solved, BZ#2403355 with the latency issues around all calendar functions and the disappearing (or, "unintended auto-dismiss") of reminders remains on thunderbird-145.0-1.fc43.x86_64. While most is unchanged, the snoozing seems to have worsened: occasionally, even the snooze of single events can now take up to a minute (while sometimes it works immediately - mostly it's in between the extremes: a short freeze). The same for creating new events in the calendar: when I start writing the text for the new reminder, it can take a minute, seldomly even more, until TB comes back from the freeze and the text I typed is actually added. A second (usually shorter) freeze comes after I clicked to add the new event to the calendar. So the issue is unchanged, but in several circumstances the freezes have increased in length. It would be good to know if anyone is working on this or if more/other data is necessary: I certainly can understand if the team has to focus on other issues, but it would be good to know if I need to migrate to another client, as this costs a lot of time (and brings unreliability to reminders I need to rely on), which I cannot afford on the long term. Thanks :)