After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 510169 - evolution should not block when trying to access CalDAV calendars
evolution should not block when trying to access CalDAV calendars
Status: RESOLVED FIXED
Product: evolution-data-server
Classification: Platform
Component: Calendar
1.12.x (obsolete)
Other All
: Normal normal
: ---
Assigned To: evolution-calendar-maintainers
Evolution QA team
evolution[caldav]
: 530203 530302 553943 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2008-01-17 12:58 UTC by Mark Edgington
Modified: 2009-08-04 14:43 UTC
See Also:
GNOME target: ---
GNOME version: 2.19/2.20



Description Mark Edgington 2008-01-17 12:58:25 UTC
Please describe the problem:
When one or more CalDAV calendars are set up with evolution, something happens which causes evolution (or something else??) to block if the server on which the CalDAV calendars reside is unreachable.  This is most notable when trying to view the calendar in the Clock panel applet.  It hangs when you click on it, and causes the rest of the panel to hang as well.  This problem also occurs if there is a very slow connection to the CalDAV server, in which case it hangs until a connection has been established all of the necessary data has been transferred.

Steps to reproduce:
1. Set up a CalDAV calendar with evolution
2. Disable the server on which the CalDAV calendar is hosted.
3. Try to view the Gnome Clock applet calendar by clicking on the time-display. (I'm using applet rev 2.20.1).


Actual results:
The calendar view of the applet will not appear.

Expected results:
The calendar pops up instantly, and if and when CalDAV data is available, the calendar is updated with the data asynchronously.

Does this happen every time?
yes.

Other information:
Comment 1 Milan Crha 2009-01-29 10:36:25 UTC
*** Bug 553943 has been marked as a duplicate of this bug. ***
Comment 2 Milan Crha 2009-04-02 18:10:59 UTC
*** Bug 530302 has been marked as a duplicate of this bug. ***
Comment 3 Milan Crha 2009-04-02 18:24:54 UTC
*** Bug 530203 has been marked as a duplicate of this bug. ***
Comment 4 Milan Crha 2009-06-23 16:07:27 UTC
I just committed a change to evolution-data-server master, commit aeb6bed, which removes lock from the caldav_set_mode call. It should help here, I guess, though I hope it'll not break anything else. Let's see.
The version of a commit is 2.27.4+
Comment 5 Milan Crha 2009-08-04 14:43:32 UTC
I tried this once again, with actual master, which is slightly after 2.27.5, and I see the above commit fixed the issue. I'm closing this bug as such. Please reopen if any you discover I'm wrong. Thanks in advance.