400278 - CalDAV provider issues requests to unselected caldav accounts at startup

Status: RESOLVED FIXED

(Calendar :: Provider: CalDAV, defect)

Description

[Simon Vaillancourt]

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

Comment 1

[Bruno Browning]

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

[Maxime Delorme]

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)

Comment 3

[Simon Vaillancourt]

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

[Bas van den Bosch]

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

[Daniel Boelzle [:dbo]]

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

Comment 6

[Bas van den Bosch]

@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. 

Comment 7

[Daniel Boelzle [:dbo]]

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

Comment 8

[Bruno Browning]

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

[Maxime Delorme]

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

Comment 10

[Maxime Delorme]

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

Comment 11

[Bruno Browning]

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.

Comment 12

[Bruno Browning]

Attachment: don't load calendar until first getItems()

This delays checking and loading the calendar until the first time getItems() is called.

Comment 13

[Daniel Boelzle [:dbo]]

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

Comment 14

[Bruno Browning]

patch checked in on trunk and MOZILLA_1_8_BRANCH
->FIXED