Closed Bug 373439 Opened 18 years ago Closed 16 years ago

Contents caldav calendars disappear after restarting Thunderbird. Sunbird works fine!

Categories

(Calendar :: Provider: CalDAV, defect)

Product:
Calendar
Component:
Provider: CalDAV
Version:
Lightning 0.3.1
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: elteck10, Unassigned)

Details

(Whiteboard: [0.5 disappearing events]) 

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; nl; rv:1.8.1.2) Gecko/20070225 BonEcho/2.0.0.2
Build Identifier: Lightning  0.3.1 on Thunderbird 1.5.0.10

We user the rscds caldav Calender server, which works great with Sunbird 0.3.1.. However, on with Lightning on Thunderbird, the contents of the calender appears only after creation of the Calendar. As soon as you close and restart Thunderbird,  the contents is not reloaded. We see this behavior on both Linux and Windows. 
Lightning on Linux and Windows works nicely!

Reproducible: Always

Steps to Reproduce:
1.Create a calender on a caldav server (rscds Version 0.7)
2.Notice the contents is visible, and you can add and remove items.
3.Close Thunderbird, and restart it again.
4.Notice that the contents has disappeared, and it is impossible to load it again.
Actual Results:  
Calender contents has disappeared

Expected Results:  
Calender contents visible

On Sunbird version 0.3.1. everything works fine. This is our current work around.
Version: unspecified → Lightning 0.3.1
do you see anything in the error console in steps 3, 4?

Sorry for responding so late.

No, the error console gives no information. The only version of Lightnigh that works for us is the nightly build 0.4a1 version. I've tried the 0.5a version too, and that one (looks beautiful) has exactly the same behavior as 0.3.1. Initially it works, but after a restart of Thunderbird all is gone again.

With Sunbird 0.3.1 however, everything works nice, we have over 50 users now, and no complains about sunbird.
I'm not able to reproduce this using Lightning 0.3.1 (Linux) and current RSCDS. With older versions of rscds you might see something like this if your calendar URL does not end in a slash. Is it possible that the URLs you are using in Lightning lack the trailing slash? Or to test with a current version of RSCDS?

I did update a few weeks ago to the latest version 0.7.1.of RSCDS, hoping that would fix it. But the behavior is still the same. 

However, I haven't tried a trailing slash, I'll try that next monday. 

Now we do use PHP4 (Redhat ES3 server doesn't support PHP5). Could that influence the behavior?

Thanks,

George
The fix in RSCDS for allowing an unterminated URL as if it was terminated with a trailling '/' is in revision control, and will be in 0.7.2.

With 0.7.1 it is still necessary to explicitly terminate collection URLs with a trailling slash, so I would certainly recommend testing if this resolves your problems.

Regards,
Andrew McMillan.
Indeed we haven't added a trailing slash to the calendar urls, I had never realized that would be essential. I'll try tomorrow (Monday), that would be a very simple fix.

Thanks,

George
I have added the trailing slash, but the behavior with lightning 0.3.1 and 0.5a stays the same. Immediately after adding the calender, they work fine. But as soon as we restart Thunderbird, the calendars disappear. You need to unsubscribe and re-subscribe to get them working. 
After restarting, it doesn't even ask for a password, so it doesn't seem to try to contact the Caldav server. 

With Sunbird 0.3.1. everything works perfect, also with the trailing slashes. 

Do we need to recreate the calendars, to get it also working in Lightning? 

The version we use now are:

- Thunderbird 1.5.0.10 on Linux (Redhat WS4)

- We tried Lightning 0.3.1., and the nightly builds 0.5a and 0.4a1. Of these only version 0.4a1 works.

CalDav server:
OS: Redhat ES3 64 bit. 
- RSCDS 0.7.1. with awl 0.16
- postgresql 8.2.3
- Apache httpd 2.2.4
- php 4.4.6

Regards,

George
I'm not able to reproduce this (RSCDS 0.8, Fedora 7, postgresql 8.2.4, httpd 2.2.4, php 5.2.2). The 0.4a1 works / 0.5a doesn't business makes me wonder if this isn't at least in part a trunk/branch issue, in which case there's a good chance the new 0.5 release will work for you. Please advise.

I have no clue where it goes wrong. I've now upgraded to:

RSCDS 0.8
Thunderbird 2.0.0.4
Lightning 0.5 (the released one)

The trailing slash is there. And we do have this calendar address:

http://www-delft/caldav.php/delftcal/delft/

where "delftcal" is the user and "delft" one of the four calendars owned by this user.

But still we have the same problem.After initial creation, the calendar does appear and we can edit and use them. However, as soon as we close Thunderbird, and restart it again, the calendars appear empty and read only, except in this 0.4a1 release and Sunbird 0.3.1.. The behavior on Windows is exactly the same as on Linux.

Also the contents of the local user calendar is not displayed. I need to remove the remote calendars to be able to display the local user calendar. 

Does lightning have a debug mode, or is there some other way that I could extract more information about this problem?

(In reply to comment #9)
> I've now upgraded to:
> 
> RSCDS 0.8
> Thunderbird 2.0.0.4
> Lightning 0.5 (the released one)
> 

I'm using this combination successfully

>
> http://www-delft/caldav.php/delftcal/delft/
> 
> where "delftcal" is the user and "delft" one of the four calendars owned by
> this user.
> 

When I try to look at this URL in Ff I get redirected to 
http://www.www-delft.com/caldav.php/delftcal/delft/
and a complaint that www.www-delft.com can't be found. I suppose it may be possible to use RSCDS with a redirect instead of the virthost described in the docs (karora?), though I've only used it with a virtual host. But it would not surprise me if the problem was connected with the redirect.

> restart it again, the calendars appear empty and read only, except in this
> 0.4a1 release and Sunbird 0.3.1.. The behavior on Windows is exactly the same
> as on Linux.
> 

If the calendar is getting thrown read-only (and it's configured as a CalDAV calendar) there really ought to be something about that in the Javascript/Error Console, at least in 0.5

> Does lightning have a debug mode, or is there some other way that I could
> extract more information about this problem?
> 
For now, I think the error console is about the best you're going to do without cracking open calDavCalendar.js and adding some dump()s.


You're right an error does show up in the error console. 

These two:

Error: [Exception... "'Component does not have requested interface' when calling method: [nsIInterfaceRequestor::getInterface]"  nsresult: "0x80004002 (NS_NOINTERFACE)"  location: "<unknown>"  data: no]

Error: [Exception... "'The resource at http://www-delft.nsc.com/caldav.php/delft_cal/delft/ is either not DAV or not available
' when calling method: [nsIWebDAVOperationListener::onOperationComplete]"  nsresult: "0x8057001e (NS_ERROR_XPC_JS_THREW_STRING)"  location: "<unknown>"  data: no]

What can be the cause of this? Because if I type www-delft.nsc.com in Ff I do get the administrator website of RSCDS. And in Sunbird it works without any problem.

Regards

George
I just checked the Sunbird (V 0.5) error console, and that one is also not empty. Although Sunbird works fine, we see the following errors:

Error: [Exception... "Component returned failure code: 0x804a0001 [calIRecurrenceItem.icalProperty]"  nsresult: "0x804a0001 (<unknown>)"  location: "JS frame :: file:///home/dapps/local_lnx/sunbird/js/calItemBase.js :: anonymous :: line 586"  data: no]
Source File: file:///home/dapps/local_lnx/sunbird/js/calItemBase.js
Line: 586

Error: this.mObserver has no properties
Source File: file:///home/dapps/local_lnx/sunbird/components/calDavCalendar.js
Line: 969

Error: [Exception... "Component returned failure code: 0x804a0001 [calIRecurrenceItem.icalProperty]"  nsresult: "0x804a0001 (<unknown>)"  location: "JS frame :: file:///home/dapps/local_lnx/sunbird/js/calItemBase.js :: anonymous :: line 586"  data: no]
Source File: file:///home/dapps/local_lnx/sunbird/js/calItemBase.js
Line: 586

Error: this.mObserver has no properties
Source File: file:///home/dapps/local_lnx/sunbird/components/calDavCalendar.js
Line: 969

Regards,

George
Given that Sb works and Ltn does not, with the same CalDAV code, and that we're dealing with only one server here, I have to wonder if the difference isn't Thunderbird. Are you maybe using a RedHat Thunderbird build and a Mozilla Lightning one (different toolchains, possible ABI problems)? Tried using Lightning in a new Thunderbird profile?

I'm running Tb 2.0.0.4 with Lightning 0.5 on Windows 2000. After restarting Tb, my CalDAV calendar gets marked read-only, my events disappear, and I also see bug 386197 - my local events disappear after the first navigation. The Error console has:
Error: [Exception... "'Component does not have requested interface' when calling method: [nsIInterfaceRequestor::getInterface]"  nsresult: "0x80004002 (NS_NOINTERFACE)"  location: "<unknown>"  data: no]

EError: [Exception... "'The resource at http://yaminon:8080/ucaldav/user/jamesa/calendar is either not DAV or not available
' when calling method: [nsIWebDAVOperationListener::onOperationComplete]"  nsresult: "0x8057001e (NS_ERROR_XPC_JS_THREW_STRING)"  location: "<unknown>"  data: no]

My CalDAV server is bedework on Tomcat, and the access logs show the following:

ip.add.res.ss - - [11/Jul/2007:18:45:43 +0800] "PROPFIND /ucaldav/user/jamesa/calendar/ HTTP/1.1" 401 948
ip.add.res.ss - jamesa [11/Jul/2007:18:45:43 +0800] "PROPFIND /ucaldav/user/jamesa/calendar/ HTTP/1.1" 207 723

So it tries to access it the first time, 401s, retries successfully but by that point it's barfed and doesn't get any of the events.
Hi Bruno,

No, we're not using a Redhat build Thunderbird, it's a binary from the Mozilla web pages. However the response is exactly the same on both Linux and Windows. 
Also in the Windows version, the stand alone Sunbird works and Lightning
does not work.
And after upgrading from Thunderbird 1.5.0.10 to 2.0.0.4 did not make any difference. 

Could there be some other dependency? We are for example behind a proxy server.

IT'S the PROXY!!

Apparently Tb with Lightning handles the proxy differently than Sunbird. 

When I configure the network for both with proxy (manually ) Sunbird works
and only Version 0.41a of Lightning works. (I've just tried)

When I say "direct internet connection" suddenly Tb with Lightning does work!! Both the 0.3.1. and the 0.5 version work in this manner.

However, I must admit, there is a bug in our network. Because also our browsers work with the proxy disabled, and we can access our Web-mail (MSN, Yahoo) which are blocked if we use the proxy server. 

So I wonder, can Lightning work in combination with a proxy? I thought it uses the standard port 80? I hope that can be fixed, because I'm sure we'll be behind the proxy here soon.

I can confirm that having a proxy set is the cause of the problem. Even if the proxy isn't used - our proxy autoconfig says not to use the proxy for local hosts, and the logs show the request goes direct from the client to the CalDAV server. If I change to no proxy then it all works fine.
Whiteboard: [0.5 disappearing events]
I can confirm that the issue in both - Sunbird 0.5 and Lightning 0.5 - is related somehow to the proxy configuration. 
I ever had issues with using remote calendars so I am unsure if testing nightly builds will solve this issue.
So I did some network traces and found, that the initial PROPFIND Request is slightly different between the NON-Proxy config and the configuration using a Proxy (we use auto-proxy). 
When requesting the initial data running WITH Proxy the Request looks like:

PROPFIND /caldav.php/jgrotepass/home/ HTTP/1.1
Host: calsrv.sagadc.int
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; de; rv:1.8.1.4pre) Gecko/20070524 Sunbird/0.5
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: de-de,de;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Content-Length: 96
Content-Type: text/xml; charset=utf-8
Authorization: Basic *justsomebasicauth*
<?xml version="1.0"?>
<D:propfind xmlns:D="DAV:"><D:prop><D:resourcetype/></D:prop></D:propfind>
-------------
For the sake of reading - I removed some blank lines - these lines are not relevant

Now the same Request *WITHOUT* a Proxy configured:
PROPFIND /caldav.php/jgrotepass/home/ HTTP/1.1
Host: calsrv.sagadc.int
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; de; rv:1.8.1.4pre) Gecko/20070524 Sunbird/0.5
Accept: text/xml
Accept-Language: de-de,de;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: utf-8,*;q=0.1
Keep-Alive: 300
Connection: keep-alive
Content-Length: 96
Content-Type: text/xml; charset=utf-8
Depth: 0
Authorization: Basic *againsomebasicauthstring*
<?xml version="1.0"?>
<D:propfind xmlns:D="DAV:"><D:prop><D:resourcetype/></D:prop></D:propfind>
-----------------------------------------------------
As you can see, this request is provided with the "Depth: 0" Flag which requests the collection. 
We are currently testing with RSCDS 0.8 - and also testing a Cosmo installation. 
Looking into the RSCDS code, the request without a "Depth" Parm will only return a single entity.

Maybe somebody can try to find where the Depth-Parm is being set. This seems (for me) the trigger that results in the missing remote calendar.

I don't know if it is Lightning and Thunderbird. With the proxy configured, Sunbird 0.5 and 0.3.1. work fine at my place.

However, if I configure the Proxy for Thunderbird, the lightning calendars become empty. However, E-mail that contains contents from internet does show nicely. So it is really the lightning part that seems to have a problem with a proxy server.

(In reply to comment #18)

> Maybe somebody can try to find where the Depth-Parm is being set. This seems
> (for me) the trigger that results in the missing remote calendar.
> 

Thanks for the sleuthing! I think, though, that the question is more where Depth: is getting stripped than where it is getting set. I can trigger what I assume is the same bug in Sunbird (current code) by setting proxy to auto-detect (and not providing an autoconfiguration URL). At any rate doing so causes the Depth: header to disappear. Using a debug Sunbird build, it's clear that the CalDAV provider is requesting the Depth: 0 header, and the nsIWebDAVService is setting it properly before calling AsyncOpen(). I'm not at all familiar with the code after that point; posting here hoping that someone who actually has a measurable amount of necko-fu can voice an opinion.
Status: UNCONFIRMED → NEW
Ever confirmed: true
(In reply to comment #20)
> I think, though, that the question is more where
> Depth: is getting stripped than where it is getting set. 

From what I can see in the network traces, I believe (something that I dont like) that the attempt to access the CalDav Server is not using the Caldav Mechanism when any kind of AutoProxy (either automatic discovery or autproxy-url) is being used. My assumptions are based upon the fact, that the "Accept:" Mime-type used when connecting via the Auto-Proxy mechanism is the default "Accept" Mime of the HTTP-Function. 
I am an absolutely newbie on the whole Mozilla structure and therefore not familar with building a debug version on either the Linux or (preferred) Mac Environment. I currently try to figure out where the Proxy-Stuff is being decided, to continue from there. 
Since last Thursday I am looking for an developing setup that works for Sunbird and/or Lightning (Sunbird prefered - because Lightning is my production piece).

As far as I can see, any Proxy-Setting that does not depend on Auto-Discovery (PAC) seems to work.

When I set the proxy manually, Sunbird (latest 0.5 release) still works, while Thunderbird /lightnings (0.5) stops working. This is where they differ in behavior at me place.

I tested Lightning (official version - build 2007062503) with Thunderbird 2.0.0.5 under Mac OS X with all four proxy-settings. I have found that the manual proxy settings seems to ignore the "No Proxy"-Host list because I can see the request being sent against our proxy. This is forwarding the request internally (thats how I configured them). So I can see the correct behavior at least here. As soon as any kind of Auto-Proxy is being involved it changes the HTTP request (removing the Depth and different Accept-Header). 
I assume that in most situations it depends how requests are being handled when it comes to accessing the CalDav Server. I can provide wireshark traces against our internal caldav server(s) if this would be interesting at any kind. We should be able to identify the component that handles the autoproxy stuff. 

Same issue with WebDAV calendars too. This problem I see in all of 0.31, 0.5 and the new 0.7 pre. With 0.5 and 0.7 even reload calendars does not work. All of 0.31, 0.5 and 0.7 work fine without a proxy.

WebDAV: Version? How do you tell?
Apache: 2.0.53
Fedora Core 3.
I also have a problem with the proxy, the error message in the errorconsole:

Fout: [Exception... "Component returned failure code: 0x80040111 (NS_ERROR_NOT_AVAILABLE) [nsIHttpChannel.requestSucceeded]"  nsresult: "0x80040111 (NS_ERROR_NOT_AVAILABLE)"  location: "JS frame :: file:///C:/Program%20Files/Mozilla%20Sunbird/components/calICSCalendar.js :: anonymous :: line 383"  data: no]
Bronbestand: file:///C:/Program%20Files/Mozilla%20Sunbird/components/calICSCalendar.js
Regel: 383

Dutch Sunbird version: Mozilla/5.0 (Windows; U; Windows NT 5.1; nl; rv:1.8.1.4pre) Gecko/20070614 Sunbird/0.5
Windows XP

When I close sunbird and start it again, all "agenda's" are disappeared.

Does the issue still exists using Lightning 0.7 Release Candidate 1?
<http://releases.mozilla.org/pub/mozilla.org/calendar/lightning/releases/0.7rc1/>
Under Lightning 0.7 RC1 it seems to get much better. Only during the start of Thunderbird there is an error raised 0x804a0301 - which seems to be an timing issue because the calendar is available after the start completes. 

Same here - Error 0x804x301, "The resource at http://yaminon:8080/ucaldav/user/jamesa/calendar is either not a DAV collection or not available" but the calendar works fine after that.
I just installed 0.7 and the calendar contents from 0.5 disappeared.  I reinstalled 0.5, and then the calendar contents (events I mean) reappeared.  Then I exported the calendar as .ics file, and reinstalled 0.7.  When I tried to import the .ics file, I received the following error:
QUOTE
106 Items were ignored since they exist in both the destination calendar and c:\Documents and Settings\Joseph\LightningExport.ics
END QUOTE
Interesting since if it existed in the destination calendar then why did they NOT show up and save me from jumping through these hoops?  After all that, still no events.
SO: I reinstalled 0.5, exported the calendar again as a .CSV file, reinstalled 0.7, and this time the data was imported and I once again have the events showing up in my calendar.

This Lightning 0.7 upgrade is not ready for prime time, at least until the upgrade properly transfers the events already in the prior version calendar.
Joseph, just enable your calendar as written in <http://www.mozilla.org/projects/calendar/releases/lightning0.7.html#issues>. See <http://forums.mozillazine.org/viewtopic.php?t=596376> if you don't know how to do this.
Did that first.  No calendar events were displayed.
That is why it was necessary to jump through the hoops to
1. get the prior calendar exported (twice in fact, since the default .ics file did not work for the import
2. file the bug report.

By the way, I use Win XP Pro with SP2 with gobs of hard disk and RAM space available.


Maybe I should open a separate bug report on the failure of the .ICS file to import.
Joseph, were you using caldav in the first place (that's what this bug is about)?  If so, upgrading lightning doesn't affect the server which holds the events afaik. If not, please file a new bug. 

If you file a bugreport, please note which type of storage you use (local, webdav, caldav, wcap, ftp or file-path). Also note in your report wether after the succesfull import of the csv wether your ics contains the data twice (export to ics and check some events for doublures). The csv-export doesn't include id's so every event added gets a new id and imports succefully (no check for doublures). Finally, attach some of your events plus your vtimezone definition from your ics so we might see if there's a problem with the ics. 
I get the same Error 0x804x301 with Thunderbird version 2.0.0.12 (20080227), Lightning 0.7 build 2007120901, automatic proxy.

The problem disappears in Sunbird, or when the proxy settings are turned off.

I can get to the CalDAV resource using Firefox and identical proxy settings just fine.

The server is a Scalix 11.3 CalDAV server, and is on the local network (no proxy required.)

I'm in charge of the automatic proxy settings server, so I'm sure the CalDAV server is excluded from the proxy list.

In order to use Thunderbird and Lightening with Scalix, you must use Scalix v11.4 as Scalix v11.3 contains server side bugs. Thunderbird and Lightening v0.8 are required for use with Scalix v11.4. Please note that due to the bugs in v11.3 information provided via the CalDAV interface has errors, entries made after upgrading to v11.4 will be correct.
While the Windows versions of Lightening and Sunbird v0.8 do work correctly with Scalix v11.4, the Solaris x86 version of Lightening v0.8 does not work but the Sunbird v0.8 does.
There have been some changes to relevant parts of the CalDAV code recently, and it would be useful if someone who uses a proxy could re-test and report.

Build 2008080720 works fine with a proxy set, Bedework as the calendar server.
Resolving WFM based on numerous comments that its the proxy and we have some proxy code fixed. Please file a new bug if this problem persists (since it has a lot of comments)

-> WFM
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.