Closed Bug 445287 Opened 16 years ago Closed 16 years ago

Cache combined with read-only calendar spawns error flood

Categories

(Calendar :: General, defect)

defect
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: ts.bugzilla, Assigned: dbo)

Details

Attachments

(3 files, 1 obsolete file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0
Build Identifier: Lightning 1.8 2008071020

I'm subscribed to the Mozilla schedule calendar as an iCal/ICS. Since I can't edit it, I marked it read-only. It is a big calendar, for which reloads lag noticeably.

After turning on caching for this read-only subscription Thunderbird on startup spawns error messages for (I suspect) each event in the calendar. Screenshots are coming up.

Expected results: the calendar parsing/cache code should not alert(), or at least not for *every* event, but leave this to the UI.

Reproducible: Always
An error message for each event in the calendar, very hard to recover from that.
"An error occurred when writing to the calendar Mozilla!
Error Number: MODIFICATION_FAILED
Description:   "
needs investigation
Flags: blocking-calendar0.9+
Assignee: nobody → philipp
I cannot reproduce this with my ICS calendar. Could you provide the url of the calendar you are using? Did you maybe receive alarm notifications for that calendar and try to dismiss them all? Just starting the application should not cause any writes.
The Mozilla Schedule calendar is linked from
http://wiki.mozilla.org/Firefox3.1/Schedule
it's on Google Calendar, strangely enough (no idea if that "convert to GDataProvider" feature messed with it).

The URL is
http://www.google.com/calendar/ical/pdighgf028nmbjbrno8oed8vsg@group.calendar.google.com/public/basic.ics
Please check out the event dialog if the attach button is enabled. If so, then it is still an ICS calendar, otherwise its a gdata calendar.
Thanks for the quick hint...
The "Attach" toolbar button is enabled. (and I checked my Google Calendar subscription, where it indeed is disabled)

In the calendar properties I have "show alarms" disabled... maybe this is similar to dismissing all alarms?

Sidenote:
Meanwhile I have the Mozilla calendar still cached, but set to writable. No error flood.
Ok, was able to confirm.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Attached patch Fix - v1 (obsolete) β€” β€” Splinter Review
This should take care. The following situation:

In the cached calendar wrapper code, items are added to the cached calendar using addItem/adoptItem() during sync. The calendar is readonly, which is checked at the beginning of those functions in the storage calendar. Both the cached and uncached calendar are readonly when the uncached calendar is set readonly, since they share the same ID.
Attachment #330045 - Flags: review?(daniel.boelzle)
Comment on attachment 330045 [details] [diff] [review]
Fix - v1

r- as discussed; I'd prefer to properly decouple the cached and uncached calendar instance. I'd suggest that the cached storage calendar doesn't make any of its properties persistent, e.g. by adding a boolean attribute calICalendar::transientProperties. Setting up the cached (storage) calendar in calCachedCalendar.js, we would set that flag, thus relaxedMode, readOnly etc are not mixed up with the uncached calendar's properties (and the caching facade).
Attachment #330045 - Flags: review?(daniel.boelzle) → review-
Status: NEW → ASSIGNED
Attached patch fix - v2 β€” β€” Splinter Review
as discussed, introducing a transientProperties attribute
Assignee: philipp → daniel.boelzle
Attachment #330045 - Attachment is obsolete: true
Attachment #332551 - Flags: review?(philipp)
Comment on attachment 332551 [details] [diff] [review]
fix - v2

Thanks for taking over,

r=philipp
Attachment #332551 - Flags: review?(philipp) → review+
Checked in on HEAD and MOZILLA_1_8_BRANCH => FIXED.
Target Milestone: --- → 0.9
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Checked in lightning 2008080803 and sunbird 20080807 -> VERIFIED
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.