CalDAV provider issues requests to unselected caldav accounts at startup

RESOLVED FIXED in 0.9

Status

Calendar
Provider: CalDAV
RESOLVED FIXED
11 years ago
10 years ago

People

(Reporter: Simon Vaillancourt, Assigned: Bruno Browning)

Tracking

unspecified
Bug Flags:
wanted-calendar0.9 +

Details

Attachments

(1 attachment)

(Reporter)

Description

11 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.7) Gecko/20070914 Firefox/2.0.0.7
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.8pre) 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
(Assignee)

Comment 1

11 years ago
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.

Comment 2

11 years ago
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)
(Reporter)

Comment 3

11 years ago
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. 

Comment 4

11 years ago
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.

Comment 5

11 years ago
You could switch off firing popup alarms via the properties page of a calendar. Wouldn't this help here?

Comment 6

11 years ago
@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

Comment 7

11 years ago
(In reply to comment #6)
But this should only happen every 30 minutes I assume.
(Assignee)

Comment 8

11 years ago
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.

Comment 9

10 years ago
I've check with last lightning and even with "Show Alarms" deselected Lightning generates traffic

Comment 10

10 years ago
By the way with all my CalDav Calendars and the size of each, the startup up of Lightning is very long 3mn at least.
(Assignee)

Comment 11

10 years ago
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
(Assignee)

Updated

10 years ago
Assignee: nobody → browning
Status: ASSIGNED → NEW

Updated

10 years ago
Flags: wanted-calendar0.9?

Updated

10 years ago
Flags: wanted-calendar0.9? → wanted-calendar0.9+
(Assignee)

Comment 12

10 years ago
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+
(Assignee)

Comment 14

10 years ago
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.