Closed Bug 529771 Opened 15 years ago Closed 12 years ago

Task list don't display when a remote calendar fails

Categories

(Calendar :: Tasks, defect)

defect
Not set
major

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: cesar.alba, Assigned: mmecca)

References

(Blocks 1 open bug)

Details

Attachments

(1 file, 2 obsolete files)

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.5) Gecko/20091105 Fedora/3.5.5-1.fc11 Firefox/3.5.5
Build Identifier: thunderbird-lightning-1.0-0.8.20090715hg.fc11.i586.rpm

I  have a number of remote calendars from a CalDav server (Chandler) to which I can access only under certain conditions (a SSH tunnel open). I also have a "local" calendar (moz-profile-calendar://) for the times I have not that tunnel.

If I launch TB with the tunnel created and the remote tunnels on all the tasks display both on the Today Pane and on the Task Tab. If the tunnel is closed and the remote calendars are not set to display, the tasks in the local calendar tasks show.

But when I launch with the tunnel closed and the remote cals unset or I set on one of the remote calendars, the task list appears empty and I have to set a "sane" configuration and restart TB to access the local calendar.

When the list is broken, I can create tasks and they will store all right.

Reproducible: Always

Steps to Reproduce:
1. Configure a remote calendar (Dav) and a local one (moz).
2. Enter a task in the local one.
3. The local task is visible.
5. Shut TB down.
6. Make the remote calendar unreachable.
7. Start TB

Actual Results:  
The task list is empty.

Expected Results:  
Lists of tasks in local calendar available.
What Thunderbird and Lightning version do you use? Released builds of Thunderbird 2.0 with released builds of Lightning 0.9? Or test builds of Thunderbird 3.0 with nightly test builds of Lightning 1.0pre? In the latter case please test with the most recent test builds first.
The about in the thunderbird shows:

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.4pre) Gecko/20091014 Fedora/3.0-2.8.b4.fc11 Lightning/1.0pre Thunderbird/3.0b4

It was the latest update from Redhat for Fedora 11.

I've downloaded the latest lightly build from http://ftp.mozilla.org/pub/mozilla.org/calendar/lightning/nightly/latest-comm-1.9.1/linux-xpi/ (Nov,16th). And the about shows exactly the same test. Is it enough with the Nov,16th data?

I've tried the nightly build and the results are somehow different but worse.

Now the calendar tab also show nothing BUT the month view on the left show bold numbers the days when there are appointments for the local data.

One more thing: if you add a new task when the view is broken, the new task appears in the list. I haven't tried with events.
Please check your error console for errors and messages, preferably with debugging enabled. (calendar.debug.log / calendar.debug.log.verbose)
I did and here is what it shows:

$ thunderbird 
[calTimezoneService] using /home/calba/.thunderbird/o0k48pjm.default/extensions/{e2fda1a4-762b-4020-b5ad-a41df1933103}/timezones.sqlite                                                 
[calTimezoneService] timezones version: 1.2009p   
CalDAV: send: <D:propfind xmlns:D="DAV:" xmlns:CS="http://calendarserver.org/ns/">          
<D:prop>                                                                      <D:resourcetype/>    <D:owner/>                                                                      <CS:getctag/>                                                                   
</D:prop>
</D:propfind>
**** Four of these ***
[calAlarmService] starting...                                                               
CalDAV: Error without status on initial PROPFIND for calendar Cumples                       
Warning: There has been an error reading data for calendar: Cumples. Error code: DAV_NOT_DAV. Description: The resource at http://localhost:15000/chandler/dav/collection/456f5930-2102-11de-a567-a59b223edba9 is either not a DAV collection or not available                      
Warning: There has been an error reading data for calendar: Cumples. Error code: READ_FAILED. Description:                                                                              
CalDAV: Error without status on initial PROPFIND for calendar Trabajo                       
Warning: There has been an error reading data for calendar: Trabajo.  However, this error is believed to be minor, so the program will attempt to continue. Error code: DAV_NOT_DAV. Description: The resource at http://localhost:15000/chandler/dav/collection/5a2f652a-22f8-11de-f3b1-9c5ea74170f3 is either not a DAV collection or not available                           
Warning: There has been an error reading data for calendar: Trabajo.  However, this error is believed to be minor, so the program will attempt to continue. Error code: READ_FAILED. Description:
...
*** One of this for each failed calendar***

So far, it shows the local calendar and the remote ones are marked to display but show the failed icon.

I untick the remote calendars. The tasks and calendar entries still showing.

I tick one of the remote calendars. The calendar entries and tasks disappear. Nothing on the logfile.

I reopen the tunnel and reload the remote calendars. Everything shows as expected.

The logfile seems normal.

CalDAV: send: <D:propfind xmlns:D="DAV:" xmlns:CS="http://calendarserver.org/ns/"> <D:prop>                                                                        <D:resourcetype/>                                                             <D:owner/>                                                                    
<CS:getctag/>                                                              </D:prop>                                                                       
</D:propfind>                                                                   
CalDAV: Status 207 on initial PROPFIND for calendar Trabajo                       
CalDAV: Authentication scheme for Trabajo is Basic                                
CalDAV: recv: <?xml version="1.0" encoding="UTF-8"?>                              

The rest of the log is the retrieval of the entries and tasks.
Whiteboard: qawanted
I had the same problem and here is what I discovered.

I have only one remote calendar (Google) where I store some events that I must access while on the go.

For privacy concern, I delete in Lighning all past event I have on that remote calendar. So those past events are also deleted on Google.

Yesterday I deleted the last event I had on that calendar. Not longer after, I shutdown my computer. This morning when I opened Lighning, I find that no task was showing in the Today Panel nor in the Task Tab. I can only see it on the Calendar Tab with the option "show task in calendar" at "on".

So all my task are there, but nowhere to be seen (except on the calendar, but that not pratical). They trigger an alarm thought.

Then, I added (in Google) an event on the calendar that sync with Lighning and then tadam! all my tasks show up in the Today Panel and the Task Tab.

My conclusion is you must have an event on a remote calendar to be able to show the task on the Today Panel and the Task Tab. I don't know the behavior if you have some events but you can't reach the remote calendar (like Cesar Alba).

--------------

While writing this comment, I tried to reproduce the bug but the task was showing in the Task Tab... But not in the Today Panel. I'll do more test and if I have something new I'll add a comment.
Finaly, I think my bug is different from this one because the connexion to a remote calandar does'nt fail, and it does affect only the Today Panel.

So I created a new bug: bug 538960.
Is that really all you get in the error console? Could you retest with the latest 1.0b2pre nightly?
To test this bug, I prefer reproduce the steps from bug 538960. So here is what I have in the console (there is no error, only messages).
Steps to Reproduce:
1. Set-up a Google Calendar in Lighthing using CalDAV.
2. Add an event in that Calendar.
3. Add some tasks in another offline calendar.
4. Close and reopen Thunderbird to be sure everything is fine.
5. Check on Google Calendar to be sure your event is there.
6. In Lightning, delete the event on your Google Calendar.
7. Sync your calendar.

-----------------------
CalDAV: Deleting https://www.google.com/calendar/dav/e7nlql920uvteuufbr3b9ctlv0@group.calendar.google.com/events/51d33c41-375a-4973-91ad-814f5cd87dc0.ics

CalDAV: Item deleted successfully from calendarCalendrier test avec google

CalDAV: send(https://www.google.com/calendar/dav/e7nlql920uvteuufbr3b9ctlv0@group.calendar.google.com/events/): <D:propfind xmlns:D="DAV:" xmlns:CS="http://calendarserver.org/ns/">
  <D:prop>
    <CS:getctag/>
  </D:prop>
</D:propfind>

CalDAV: Status 207 checking ctag for calendar Calendrier test avec google

CalDAV: recv: <?xml version="1.0" encoding="UTF-8"?>
<D:multistatus xmlns:D="DAV:">
  <D:response>
    <D:href>/calendar/dav/e7nlql920uvteuufbr3b9ctlv0@group.calendar.google.com/events/</D:href>
    <D:propstat>
      <D:status>HTTP/1.1 200 OK</D:status>
      <D:prop>
        <CS:getctag xmlns:CS="http://calendarserver.org/ns/">63403839508</CS:getctag>
      </D:prop>
    </D:propstat>
  </D:response>
</D:multistatus>

CalDAV: send(https://www.google.com/calendar/dav/e7nlql920uvteuufbr3b9ctlv0@group.calendar.google.com/events/): <?xml version="1.0" encoding="UTF-8"?>
<D:propfind xmlns:D="DAV:">
  <D:prop>
    <D:getcontenttype/>
    <D:resourcetype/>
    <D:getetag/>
  </D:prop>
</D:propfind>

CalDAV: ctag mismatch on refresh, fetching data for calendar Calendrier test avec google

CalDAV: recv: 
<D:multistatus>
  <D:response>
    <D:href>/calendar/dav/e7nlql920uvteuufbr3b9ctlv0@group.calendar.google.com/events/</D:href>
    <D:propstat>
      <D:status>HTTP/1.1 200 OK</D:status>
      <D:prop>
        <D:getcontenttype>text/calendar; component=vevent</D:getcontenttype>
        <D:resourcetype>
          <D:collection></D:collection>
          <C:calendar></C:calendar>
        </D:resourcetype>
      </D:prop>
    </D:propstat>
    <D:propstat>
      <D:status>HTTP/1.1 404 Not Found</D:status>
      <D:prop>
        <D:getetag></D:getetag>
      </D:prop>
    </D:propstat>
  </D:response>
</D:multistatus>
------------------------------

Then I did those steps:
8. Close Thunderbird.
9. Check on Google Calendar to be sure your event is gone.
10. Open Lightning.

And the Today Panel should did not show any task.

Here is what I have in the console:

-----------------------------------
[calTimezoneService] using D:\Paramètres\Mozilla\Thunderbird\extensions\{e2fda1a4-762b-4020-b5ad-a41df1933103}\timezones.sqlite

[calTimezoneService] timezones version: 1.2009p

CalDAV: send: <D:propfind xmlns:D="DAV:" xmlns:CS="http://calendarserver.org/ns/">
  <D:prop>
    <D:resourcetype/>
    <D:owner/>
    <CS:getctag/>
  </D:prop>
</D:propfind>

[calAlarmService] starting...

... (some calAlarmService message) ...

CalDAV: Status 207 on initial PROPFIND for calendar Calendrier test avec google

CalDAV: Authentication scheme for Calendrier test avec google is Basic

CalDAV: recv: <?xml version="1.0" encoding="UTF-8"?>
<D:multistatus xmlns:D="DAV:">
  <D:response>
    <D:href>/calendar/dav/e7nlql920uvteuufbr3b9ctlv0@group.calendar.google.com/events/</D:href>
    <D:propstat>
      <D:status>HTTP/1.1 200 OK</D:status>
      <D:prop>
        <D:resourcetype>
          <D:collection />
          <C:calendar xmlns:C="urn:ietf:params:xml:ns:caldav" />
        </D:resourcetype>
        <D:owner>
          <D:href>/calendar/dav/e7nlql920uvteuufbr3b9ctlv0%40group.calendar.google.com/user</D:href>
        </D:owner>
        <CS:getctag xmlns:CS="http://calendarserver.org/ns/">63403839508</CS:getctag>
      </D:prop>
    </D:propstat>
  </D:response>
</D:multistatus>

CalDAV: initial ctag 63403839508 for calendar Calendrier test avec google

CalDAV: send: OPTIONS https://www.google.com/calendar/dav/e7nlql920uvteuufbr3b9ctlv0@group.calendar.google.com/

CalDAV: DAV header: 1, calendar-access, calendar-schedule, calendar-proxy

CalDAV: Calendar Calendrier test avec google generally supports calendar-schedule

CalDAV: send: PROPFIND https://www.google.com/calendar/dav/e7nlql920uvteuufbr3b9ctlv0%40group.calendar.google.com/user/
<D:propfind xmlns:D="DAV:" xmlns:C="urn:ietf:params:xml:ns:caldav">
  <D:prop>
    <C:calendar-home-set/>
    <C:calendar-user-address-set/>
    <C:schedule-inbox-URL/>
    <C:schedule-outbox-URL/>
  </D:prop>
</D:propfind>

CalDAV: recv: <?xml version="1.0" encoding="UTF-8"?>
<D:multistatus xmlns:D="DAV:">
  <D:response>
    <D:href>/calendar/dav/e7nlql920uvteuufbr3b9ctlv0%40group.calendar.google.com/user/</D:href>
    <D:propstat>
      <D:status>HTTP/1.1 200 OK</D:status>
      <D:prop>
        <C:calendar-home-set xmlns:C="urn:ietf:params:xml:ns:caldav">
          <D:href>/calendar/dav/e7nlql920uvteuufbr3b9ctlv0%40group.calendar.google.com/</D:href>
        </C:calendar-home-set>
        <C:calendar-user-address-set xmlns:C="urn:ietf:params:xml:ns:caldav">
          <D:href>mailto:e7nlql920uvteuufbr3b9ctlv0@group.calendar.google.com</D:href>
          <D:href>/calendar/dav/e7nlql920uvteuufbr3b9ctlv0%40group.calendar.google.com/user/</D:href>
        </C:calendar-user-address-set>
        <C:schedule-inbox-URL xmlns:C="urn:ietf:params:xml:ns:caldav">
          <D:href>/calendar/dav/e7nlql920uvteuufbr3b9ctlv0%40group.calendar.google.com/inbox/</D:href>
        </C:schedule-inbox-URL>
        <C:schedule-outbox-URL xmlns:C="urn:ietf:params:xml:ns:caldav">
          <D:href>/calendar/dav/e7nlql920uvteuufbr3b9ctlv0%40group.calendar.google.com/outbox/</D:href>
        </C:schedule-outbox-URL>
      </D:prop>
    </D:propstat>
  </D:response>
</D:multistatus>

CalDAV: send(https://www.google.com/calendar/dav/e7nlql920uvteuufbr3b9ctlv0@group.calendar.google.com/events/): <?xml version="1.0" encoding="UTF-8"?>
<D:propfind xmlns:D="DAV:">
  <D:prop>
    <D:getcontenttype/>
    <D:resourcetype/>
    <D:getetag/>
  </D:prop>
</D:propfind>

CalDAV: recv: 
<D:multistatus>
  <D:response>
    <D:href>/calendar/dav/e7nlql920uvteuufbr3b9ctlv0@group.calendar.google.com/events/</D:href>
    <D:propstat>
      <D:status>HTTP/1.1 200 OK</D:status>
      <D:prop>
        <D:getcontenttype>text/calendar; component=vevent</D:getcontenttype>
        <D:resourcetype>
          <D:collection></D:collection>
          <C:calendar></C:calendar>
        </D:resourcetype>
      </D:prop>
    </D:propstat>
    <D:propstat>
      <D:status>HTTP/1.1 404 Not Found</D:status>
      <D:prop>
        <D:getetag></D:getetag>
      </D:prop>
    </D:propstat>
  </D:response>
</D:multistatus>
----------------------------------------

I hope this help.
I did my test with
Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.1.7) Gecko/20100111 Lightning/1.0b2pre Thunderbird/3.0.1
Keywords: qawanted
Whiteboard: qawanted
I can confirm this bug on
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110516 Lightning/1.0b2 Thunderbird/3.1.10

I could narrow down 2 symptoms when it occurred:
- a CalDAV calendar could not be loaded (and produces a warning in the error console)
- all CalDAV calendars could be loaded, but the error console is filled with ~100 'too much recursion' errors from various calendar scripts

When it happens I can create a task in my local calendar it is displayed. When I then disable the local calendar the task disappears, but re-enabling the local calendar does not bring it back.
I do reproduce this bug with TB5 and Lightning 1.0b5rc3. When connection to a remote calendar(webdav for RTM) fails, all tasks disappears including local one
OS: Linux → All
Hardware: x86 → All
I can confirm webdav issue reported in comment #12 - filed bug 678930

There are 2 parts to this problem:

1) An unhandled exception or another problem in the provider prevents the composite calendar from sending onOperationComplete to the listener after a getItems call. This is the case with the ICS provider when the connection is unavailable, and I suspect similar problem(s) may be behind the CalDAV errors reported.

2) The task tree only completes a refresh operation once the listener receives onOperationComplete. All subsequent refresh operations are blocked until the pending refresh completes.
Assignee: nobody → matthew.mecca
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Depends on: 678930
The task tree already has the same mechanism as the other views to cancel a pending refresh when the next operation is called, but we haven't been returning the operation when the refresh job is executed.

This doesn't completely fix the problem - if a refresh hangs, the task list won't be updated until the next refresh operation is started, but it should prevent the list from being completely locked until tb is restarted. It should also handle intermittent connection issues much better.
Attachment #553101 - Flags: review?(philipp)
One possible fix for this would be to load the tasks into the tree as they are retrieved rather than once at the end, but I think load performance would take a big hit.

Also, this shouldn't be an issue with caching enabled, since the cached calendars don't need to block getItems requests while refreshing. When caching is enabled by default this likely won't be a problem.

In either case, I think the current outstanding issues can be handled in the providers, so we probably don't need to block 1.0 on this.

I suspect Bug 676540 may be an example of this with the CalDAV provider. To those who reported this issue with CalDAV calendars, are you still able to reproduce this with current builds?
Attachment #553101 - Attachment description: Allow pending refresh operations to be cancelled → [post1.0] Allow pending refresh operations to be cancelled
(In reply to Matthew Mecca [:mmecca] from comment #15)
> One possible fix for this would be to load the tasks into the tree as they
> are retrieved rather than once at the end, but I think load performance
> would take a big hit.
Could you elaborate on this? I would rather be thinking that it might smoothen up the UI a bit since not everything is gathered and one big operation is done at the end. It might also improve memory usage.
Comment on attachment 553101 [details] [diff] [review]
[post1.0] Allow pending refresh operations to be cancelled

r=philipp
Attachment #553101 - Flags: review?(philipp) → review+
(In reply to Philipp Kewisch [:Fallen] from comment #16)
> Could you elaborate on this? I would rather be thinking that it might
> smoothen up the UI a bit since not everything is gathered and one big
> operation is done at the end. It might also improve memory usage.

I think the task list would end up having similar problems as the Today Pane in bug 709532 - the initial loading of the tree would be smoother, but the items would visibly be removed and added back in on every calendar refresh.

A different approach that might work would be to set a timeout that would update the list at a specific interval during a refresh operation, that would leave the list usable for the other working calendars in the case of an intermittent failure of a single calendar at the provider level.
Attached patch Fix v2 (obsolete) — — Splinter Review
If we refresh from each calendar instead of from the composite calendar, the task tree should handle individual calendar failures better. Using the modifyItems function will unify some of the item loading code as well.
Attachment #553101 - Attachment is obsolete: true
Attachment #615116 - Flags: review?(philipp)
Depends on: 728759
Blocks: 746524
Blocks: 779867
Comment on attachment 615116 [details] [diff] [review]
Fix v2

Review of attachment 615116 [details] [diff] [review]:
-----------------------------------------------------------------

Sorry for the long delay. I've done some simple testing and couldn't observe any memory increase and I had the feeling CPU usage even decreased. Lets give this a try and see how it goes.

::: calendar/base/content/calendar-task-tree.xml
@@ +1056,5 @@
> +              },
> +
> +              cancel: function() {
> +                  if (this.operation && this.operation.isPending) {
> +                      this.operation.cancel(null);

Optional bonus: Make the parameter [optional] in the IDL, then you don't have to pass null.

@@ +1112,5 @@
> +          cals.forEach(function(calendar) {
> +              if (!calendar.getProperty("disabled")) {
> +                  this.refreshFromCalendar(calendar, aFilter);
> +              }
> +          }, this);

No need to construct an extra function object here, you can just use a normal for each() loop.
Attachment #615116 - Flags: review?(philipp) → review+
Attached patch Fix v3 — — Splinter Review
Attachment #615116 - Attachment is obsolete: true
Attachment #655328 - Flags: review+
Pushed to comm-central - http://hg.mozilla.org/comm-central/rev/e45f156127ae
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → 1.9
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: