User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:220.127.116.11) Gecko/20070914 Firefox/18.104.22.168 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:22.214.171.124pre) Gecko/20071016 Sunbird/0.7 When starting Sunbird, PROPFINDs and REPORTs are issued to the CalDAV server even if the CalDAV account are not "checked". Reproducible: Always Steps to Reproduce: 1.Subscribe to 2 CalDAV calendars 2.Unselect 1 3.Restart Sunbird Actual Results: When restarting Sunbird, the client will issue reports for the unselected calendar Expected Results: nothing should be sent to the unselected calendars
This is actually by design: unselecting a calendar does not disable it so much as supress its display, which prevents alarms in unselected calendars from being lost. I agree that the UI is confusing on this and should be improved. See also bug 385914, at least.
But when unchecked calendars are not yours, it's no very usefull to load it at startup, because I don't care of alarms and TODO of my friends. I've already enough with mines :-) I think the main problem is that Lightning / Sunbird as no way to say . This calendar/these calendar is/are mine and those ones are not Same issue when accepting invitation, you accept on your calendar or for your boss if you are his secretary but, IMHO you don't accept an event send to you to put in a calendar of a friend ( more over when you don't have write access on it ;-D)
Could we then add another "state", currently we have: - Selected: Calendar items are displayed in the views - Unselected: Calendar items are not displayed in the views but are fetched to pop up alarms. I would add one so it ends up like that: - Selected: Calendar items are displayed in the views - Hide from calendar views (was "Unselected"): Calendar items are not displayed in the views but are fetched to pop up alarms. - Disable account: Keep account information but never generate requests for this account.
Imho calendars which are unselected shouldn't fire alarms and shouldn't load the remote calendars. But we now have a special option for alarms so I don't think anyhting needs to be done when chosen these calendars should fire alarms.
You could switch off firing popup alarms via the properties page of a calendar. Wouldn't this help here?
@Daniel: no, it wouldn't. As the performance of Lightning is rather bad still, big calendars are switched off by default at our place. However, they still reload so there's networking capacity and processing of events. If a calendar is deselected, it shouldn't be loaded and processed.
Status: UNCONFIRMED → NEW
Ever confirmed: true
(In reply to comment #6) But this should only happen every 30 minutes I assume.
I just tested this with a current Sb nightly, and if both the calendar and its "Show Alarms" checkbox are deselected, Sb generates no traffic to the calendar either on load or on refresh(). If "Show Alarms" is selected, the calendar is loaded and refresh()ed, which of course both show network traffic. This is the behavior I would expect, and if I were reporter Simon I'd be closing this bug. ;-) Bas is correct that our CalDAV performance is pretty dismal for large calendars; that's one of the things being worked on in bug 393817 and will doubtless be the subject of follow-on bugs as well.
I've check with last lightning and even with "Show Alarms" deselected Lightning generates traffic
By the way with all my CalDav Calendars and the size of each, the startup up of Lightning is very long 3mn at least.
Okay, I see what's going on here now: we need to not start our calendar-init chain in the URI setter. I'll take the bug; too late to fix this for 0.8, I think, but it will get fixed shortly after.
Status: NEW → ASSIGNED
Created attachment 314741 [details] [diff] [review] don't load calendar until first getItems() This delays checking and loading the calendar until the first time getItems() is called.
Attachment #314741 - Flags: review?(daniel.boelzle)
Comment on attachment 314741 [details] [diff] [review] don't load calendar until first getItems() I think it would be good to also queue the other operations, e.g. much like the ics provider does. Even though, since caldav's caching mechanism is supposed to be merged with the experimental caching, we don't need it. r=dbo
Attachment #314741 - Flags: review?(daniel.boelzle) → review+
patch checked in on trunk and MOZILLA_1_8_BRANCH ->FIXED
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
OS: Windows XP → All
Hardware: PC → All
Target Milestone: --- → 0.9
You need to log in before you can comment on or make changes to this bug.