Error snoozing or dismissing calendar alarm causes calendar to be marked read-only
Categories
(Calendar :: Alarms, defect)
Tracking
(Not tracked)
People
(Reporter: fouuqibwtn, Unassigned)
References
(Blocks 1 open bug)
Details
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:103.0) Gecko/20100101 Firefox/103.0
Steps to reproduce:
Delete or dismiss a calendar event alarm from the Reminders window. (I think it may also happen sometimes when the event is edited and an error happens.)
Actual results:
Some error occurs, and then the calendar is changed to read-only. To get the calendar back to a normal state, I have to unset read-only and restart Thunderbird.
Expected results:
Either no error should happen at all (it's never clear what the error is, and doing the exact same thing after restarting Thunderbird causes no error) or the calendar should not be set to read-only.
|
Reporter | |
Comment 1•2 years ago
|
||
All the calendars in question are in files, and are accessed via a "file://" URI.
This happens very unpredictably, and not that often, so when it happens next I will take a screen shot and put it in with a description of what triggered the error. I don't remember the specific error message that shows up, but it's something quite generic, along the lines of "something went wrong", so it might be helpful to add some sort of error codes and specific parameters or something to enable better bug reports.
As I mentioned above, when I do the exact same dismissal, snooze, or edit on the event after restarting Thunderbird, I never get another error, but trying the operation again before a restart never works, so I suspect something about the handling of whatever this error is puts Thunderbird in a state where it doesn't retry the operation "cleanly" without a complete restart.
I set the version to 102 because that's what I'm using, but I've been seeing this problem for years, with many versions and on many different computers.
|
||
Updated•2 years ago
|
|
||
Comment 2•2 years ago
|
||
Hello, thank you for reporting this issue. May you provide us with some more details in order to assist in determining the cause and a potential solution. Specifically:
- Are these calendar files on your local disk or a networked drive etc?
- Do you have write access to the file?
- Can you successfully make any changes to the events in the calendar manually before a restart?
- If you are able to reproduce the problem, the details of the error should be dumped to the console. You can access the console via the menu Tools > Developer Tools > Developer Toolbox. When the error occurs, first review what is logged for any sensitive information then please share the details here.
|
|
Reporter | |
Comment 3•2 years ago
|
||
(In reply to Lasana Murray from comment #2)
Hello, thank you for reporting this issue. May you provide us with some more details in order to assist in determining the cause and a potential solution. Specifically:
- Are these calendar files on your local disk or a networked drive etc?
They're all on the the local disk, configured in calendar via "file://" URIs.
- Do you have write access to the file?
Yes.
- Can you successfully make any changes to the events in the calendar manually before a restart?
I have never tried making manual changes to the calendars when this happens, so I don't know. If you'd like me to try to make some manual changes, please describe a very specific test case and I will try it when/if this happens again. Do you want me to do the manual modification after shutting Thunderbird down or before shutting it down, and what kind of modification do you want me to make? For example, snoozing an alarm looks like it involves setting some sort of non-standard property on the event of the form "X-MOZ-SNOOZE-TIME-<Unix epoch time>:<ISO 8601 time>", but I don't know the semantics of that.
- If you are able to reproduce the problem, the details of the error should be dumped to the console. You can access the console via the menu Tools > Developer Tools > Developer Toolbox. When the error occurs, first review what is logged for any sensitive information then please share the details here.
I tried to activate this toolbox, and got a pop-up asking if I wanted to allow a connection from some port on 127.0.0.1 to some other port on 127.0.0.1. I clicked on "Disable", and now I can't get that pop-up to come back up. The Error Console has a message in it saying "Could not start Browser Toolbox, you need to enable it.", but I don't know how to enable it now that I'm not getting the pop-up, and I don't like enabling port accesses for debuggers if it's going to be sticky like this, especially if it's got something to do with my browser instead of just Thunderbird. So, maybe you can tell me how to enable and disable this port access if that's what you want me to do, because I'm not going to enable it permanently. This would, of course, be obviated by a more informative message in the original error pop-up.
If, on the other hand, you only want information that's in the Error Console, I can see that without starting the toolbox, so maybe I just need to look at the Error Console after I see this bug manifest? Let me know. In any case, this problem doesn't manifest frequently, so it may be a while.
|
|
Reporter | |
Comment 5•2 years ago
|
||
This bug just manifested. Below are the relevant entries from the Error Console. I didn't actually modify the "Walk" event; I moved a different event in a different calendar to a different starting date.
Here's the error text:
Calendar: There has been an error reading data for calendar: To_Do. It has been placed in read-only mode, since changes to this calendar will likely result in data-loss. You may change this setting by choosing 'Edit Calendar'. Error code: 0x80004005. Description: old item mismatch in modifyItem. storedId:BEGIN:VEVENT
CREATED:20191002T012121Z
LAST-MODIFIED:20220921T065846Z
DTSTAMP:20220921T065846Z
UID:b9a25a01-e846-4412-af76-12029c1b3363
SUMMARY:Walk
RRULE:FREQ=DAILY
X-MOZ-LASTACK:20220921T065846Z
DTSTART;TZID=America/Chicago:20220710T120000
DTEND;TZID=America/Chicago:20220710T121500
TRANSP:OPAQUE
X-MOZ-GENERATION:2874
SEQUENCE:46
X-MOZ-SNOOZE-TIME-1656781200000000:20220710T062847Z
BEGIN:VALARM
ACTION:DISPLAY
TRIGGER:PT0S
DESCRIPTION:Default Mozilla Description
X-LIC-ERROR;X-LIC-ERRORTYPE=PARAMETER-VALUE-PARSE-ERROR:Got a VALUE paramet
er with an illegal type for property: VALUE=DURATION
END:VALARM
END:VEVENT old item:BEGIN:VEVENT
CREATED:20191002T012121Z
LAST-MODIFIED:20220921T020210Z
DTSTAMP:20220921T020210Z
UID:b9a25a01-e846-4412-af76-12029c1b3363
SUMMARY:Walk
RRULE:FREQ=DAILY
X-MOZ-LASTACK:20220921T020200Z
DTSTART;TZID=America/Chicago:20220710T120000
DTEND;TZID=America/Chicago:20220710T121500
TRANSP:OPAQUE
X-MOZ-GENERATION:2873
SEQUENCE:46
X-MOZ-SNOOZE-TIME-1656781200000000:20220710T062847Z
X-MOZ-SNOOZE-TIME-1661792400000000:20220921T021700Z
BEGIN:VALARM
ACTION:DISPLAY
TRIGGER:PT0S
DESCRIPTION:Default Mozilla Description
X-LIC-ERROR;X-LIC-ERRORTYPE=PARAMETER-VALUE-PARSE-ERROR:Got a VALUE paramet
er with an illegal type for property: VALUE=DURATION
END:VALARM
END:VEVENT CalCalendarManager.jsm:828
|
|
||
Comment 6•2 years ago
|
||
(In reply to fouuqibwtn from comment #5)
This bug just manifested. Below are the relevant entries from the Error Console. I didn't actually modify the "Walk" event; I moved a different event in a different calendar to a different starting date.
...
Seems like the memory calendar internally checks the contents of the stored version of the item and new version before modifying. I'm not sure why this necessary. Based on the ical data dumped to the console, X-MOZ-LASTACK and X-MOZ-SNOOZE-TIME-* are the changed properties that can make that check fail (the other changed properties are ignored). I'm not too certain what's going on here yet but elsewhere I noticed write operations fail on ics calendars if they are modified externally.
Did you perhaps have another instance of Thunderbird open or another program modifying the file?
|
|
Reporter | |
Comment 7•2 years ago
|
||
I absolutely, positively did not have another instance of Thunderbird or any other program modifying this file. I never modify any of the calendar files "manually", and I don't actually know how I'd get another instance of Thunderbird running on a Windows 10 machine. It's not like clicking on the Thunderbird icon when Thunderbird is already running causes another Thunderbird window to open up. So, to reiterate: my running something else concurrently that was modifying my .ics files is not what caused this. BTW, even if I ever did modify the .ics files manually, I wouldn't be modifying any of the X-MOZ-* properties, because I have no idea what their semantics are.
|
|
||
Comment 8•2 years ago
•
|
||
I didn't actually modify the "Walk" event; I moved a different event in a different calendar to a different starting date.
Could you expand on this a little. You said "a different event". Did you mean the Walk event that was logged to the console or another unrelated event? Did you move the event to/from the same ics calendar that is having this error?
Feel free to be describe the steps you took in detail if you can. Thanks.
Edit (this part is more of a mental note): This has something to do with caching and synchronization. The error message the reporter shared indicates the value stored in the memory cache is different from the one passed to modifyItem() as the old item. That value likely came from the cached calendar because that's where calCachedCalendar reads from.
Perhaps somewhere along the line, an alarm was snoozed, recorded in the cache (storage) but not reflected in the memory calendar? While trying to reproduce this I ran into the "ID for modifyItem doesn't exist, is null or is from different calendar" branch. Seems that somewhere along the line snoozing/dismissing exceptions get confused.
|
|
Reporter | |
Comment 9•2 years ago
|
||
(In reply to Lasana Murray from comment #8)
I didn't actually modify the "Walk" event; I moved a different event in a different calendar to a different starting date.
Could you expand on this a little. You said "a different event". Did you mean the Walk event that was logged to the console or another unrelated event? Did you move the event to/from the same ics calendar that is having this error?
Feel free to be describe the steps you took in detail if you can. Thanks.
There was an event X in calendar Y. There was also the "Walk" event in calendar "To_Do". Y != "To_Do". I changed the start date of event X (moved it a month into the future), and got the above-logged event related to the "Walk" event in calendar "To_Do", and had the "To_Do" calendar changed to read-only. So, the point is, a change to an event in one calendar caused an error related to an event in a different calendar.
This is obviously consistent with the hypothesis that some cache of calendars is getting out of sync with the calendar on disk. I not infrequently snooze all alarms, so if there's just something wrong with the code that syncs the cache with the disk when the app snoozes all alarms, then the logged error could happen with any alarm that was snoozed in any calendar.
|
|
Reporter | |
Comment 10•2 years ago
|
||
In case it's relevant: I don't have "Offline Support" enabled for any of my calendars, and I wasn't operating in offline mode when any of this happened.
|
||
Comment 11•2 years ago
|
||
Does this issue still reproduce for you when using version 102.6.1 or newer?
|
|
Reporter | |
Comment 12•2 years ago
|
||
First, I largely stopped using Thunderbird calendar shortly after this, due to the many bugs I've found in it. I've gone back to using it now, but with periodic synchronization turned off, as bugs with that were very annoying. However, as you can see from the entries above, after I initially reported this bug, it took on the order of 2 months for it to manifest again so I could provide more details. Thus, I won't feel confident in reporting it's no longer manifesting until at least 2 months have gone by without it manifesting again, if not more.
|
|
Reporter | |
Comment 13•2 years ago
|
||
This bug just manifested again. I snoozed all alarms for 10 minutes, and one of the calendars became read-only. This was with version 102.6.1.
Description
•