518610 - Tasks no longer work in TB3/Lightning with Kerio Mailserver

Status: RESOLVED FIXED

(Calendar :: Provider: CalDAV, defect)

Description

[Tony Fairbanks]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.4pre) Gecko/20090915 Lightning/1.0pre Thunderbird/3.0b4

Tasks used to work properly in TB 2.x and Lightning .9. Using the new TB Beta and the latest Lightning build, tasks to longer show up under any view. 

Reproducible: Always

Steps to Reproduce:
1. Create a task on a CalDAV calendar using Kerio Mailserver
2. Close and re-open TB
Actual Results:  
No tasks appear anywhere.

Expected Results:  
Existing tasks and the new tasks appear.

I can create a task successfully via Lightning as it shows up in the Kerio Webmail view. However, no tasks, new or existing, appear in Lightning.

Comment 1

[Tony Fairbanks]

Attachment: Verbose log debug for TB3

Only entry in the CalDAV calendar is a single task

Comment 2

[Tony Fairbanks]

Attachment: Verbose log debug for TB2

Only entry in the CalDAV calendar is a single task.

Comment 3

[Tony Fairbanks]

Attached are two verbose debug logs, one from TB2/Lightning .9, one from TB3/Lightning nightly. They are both logs against the same server and the same CalDAV account, which has a single Task entry in it.

Comment 4

[Stefan Sitter [:ssitter]]

What do you mean with "any view"? The task list in the Today Pane? The task mode tab? Or the day/week/month calendar view? In the latter case: Have you enabled the Display Tasks In View option? And does the task has a valid start and due date?

Comment 5

[Tony Fairbanks]

By "any view" I mean any place where I could possibly see a listing of tasks. Its basically as if I have no tasks defined at all, even though they exist. Having start/due dates set doesn't make any difference.

Comment 6

[Rolf Eder]

I can confirm this bug with TB3b4 and Lightning 1.0pre (19-Oct-2009 10:05 PST) on Mac OS X 10.5 using Kerio 6.7.2 build 7821 running on Debian Lenny. 

Tasks entered in Lightning disappear after TB restart although they are still available in other CalDAV-Clients or the Kerio Webmail interface. Tasks entered with other clients will never appear in the Lightning CalDAV task list.

Interesting: If you reload the tasks after you entered them in Lightning, the tasks will remain. They will vanish only if you restart TB. Seems there is some different cache purging mechanism at work here.

Comment 7

[Guy Zürcher]

I also confirm, TB3b4, 1.0pre 7-Nov-2009 on MacOSX and Windows XP and Vista. Using Kerio 6.7.2 on Lenny.

If required i can also test on Linux (debian based).

Comment 8

[Martin Schröder [:mschroeder]]

Bruno, could you have a look at this CalDAV issue?

Comment 9

[Bruno Browning]

Attachment: don't assume principal namespaces are paths; Kerio workarounds

This patch
* fixes a Mozilla bug where we were assuming that servers report the principal namespace as a path instead of as an http URI (Kerio does the latter)
* works around Kerio bug(s) where the scheduling in- and outboxes are reported without an HREF element
* works around a Kerio bug where getcontenttype on a VTODO returns text/vtodo instead of text/calendar (the "fix" for the current bug)
Appreciate it if someone could report the Kerio bugs there

Comment 10

[Rolf Eder]

Tx for your fast response!

OK. I have a Kerio ticket for this: EWT-689667.

How can I test your patch (I'm an admin not a programmer)? In which version will it be included?

Comment 11

[Guy Zürcher]

I'll check this, as soon an updated nightly build is available which includes the patch and report here. Unfortunatley i have no TBird/Lightning build-environment here.

Comment 12

[Rolf Eder]

From Kerios point of view that bug seems not very critical. It is now listed as "Suggestion 11790" and might be included in future releases.

Comment 13

[Bruno Browning]

(In reply to comment #12)
> From Kerios point of view that bug seems not very critical. It is now listed as
> "Suggestion 11790" and might be included in future releases.

Yes, I missed it yesterday, but the HREF issue has already been reported to them; see bug #456380. Seems that Mozilla interop is not a high priority in Kerioland.

Comment 14

[Tony Fairbanks]

The patch provided here seems to fix the problems in this bug and bug #456380, from my limited testing so far. I'll keep playing around with it throughout the day but so far so good.

Comment 15

[Philipp Kewisch [:Fallen][☁️📆]]

Comment on attachment 411099 [details] [diff] [review]
don't assume principal namespaces are paths; Kerio workarounds

>+                try {
>+                    ibUrl.path = thisCalendar.ensurePath(response..*::["schedule-inbox-URL"]..*::href[0].toString());
>+                } catch (ex) {
>+                    // most likely this is a Kerio server that omits the "href"
>+                    ibUrl.path = thisCalendar.ensurePath(response..*::["schedule-inbox-URL"].toString());
>+                }
I'd prefer explicitly checking for the href node here instead of swallowing the error. Sames goes for the outbox.

Otherwise r=philipp.
This patch has a191, please check into both comm-central and comm-1.9.1

Comment 16

[Bruno Browning]

While I agree that simply swallowing the error is a bad idea, paragraph 13.2.1 of the CalDAV spec says that the HREF ought to be there, so I disagree that checking for the HREF explicitly is the way to go: we should assume that it is there, and treat its absence as an error. My take is that the inbox check ought to look like:

                try {
                    ibUrl.path = thisCalendar.ensurePath(response..*::["schedule-inbox-URL"]..*::href[0].toString());
                } catch (ex) {
                    try {
                        ibUrl.path = thisCalendar.ensurePath(response..*::["schedule-inbox-URL"].toString());
                        LOG("CalDAV: Non-RFC-compliant server that omits HREF element in schedule-inbox-URL; coping");
                    } catch (ex2) {
                        LOG("CalDAV: unexpected and unparseable response to schedule-inbox-URL query");
                        ibUrl = null;
                    }
                }

Comment 17

[Philipp Kewisch [:Fallen][☁️📆]]

Yeah, I agree that would be the most verbose form (maybe change LOG to cal.LOG and the middle LOG to cal.WARN though).

Does a missing href element even cause an exception? My take was that e4x is pretty forgiving.If this is the case, then you could also just go with:

let ibPath = (response..*::["schedule-inbox-URL"]..*::href[0] ||
              response..*::["schedule-inbox-URL"]).toString()
ibUrl.path = thisCalendar.ensurePath(ibPath);

This way we don't swallow exceptions that happen due to other problems (i.e we mess up ensurePath) and still catch both cases.


I'll leave the final decision to you, I don't have too strong feelings on this one.

Comment 18

[Tony Fairbanks]

Any chance of this making it into the upcoming beta/RC?

Comment 20

[Philipp Kewisch [:Fallen][☁️📆]]

Pushed to comm-central <http://hg.mozilla.org/comm-central/rev/1>

and comm-191: f2425461d4da (1.0b1 relbranch) / 1a83118eb07 (default)

-> FIXED

Comment 21

[Philipp Kewisch [:Fallen][☁️📆]]

comm-central rev is not 1, but cfd5cdb3bf17

Comment 22

[matthias]

Free/Bussy Patch in Lightning 1.0b2 does not work with Kerio 7.1.

Comment 23

[Philipp Kewisch [:Fallen][☁️📆]]

These bugs are likely targeted at Lightning 1.0b1, not Lightning 1.0. If this change was done in error, please adjust the target milestone to its correct value. To filter on this bugspam, you can use "lightning-10-target-move".