1653874 - Calendar does not sync in TB 78 using DavMail

Status: RESOLVED DUPLICATE of bug 1649036

(Calendar :: Provider: CalDAV, defect)

Description

[David Potterveld]

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/83.0.4103.116 Safari/537.36

Steps to reproduce:

I am using a CalDAV data source previously working perfectly in TB 68 with Lightning. The source is 3rd party app "DavMail", which in turn is sourcing data from Office365.

I configured the TB78 calendar exactly like the one in TB68.
I performed the following sequence of operations:

1. Syncing the calendar in TB78
2. Creating a new calendar event in TB78
3. Modifying the created event in O365
4. Syncing the calendar in TB78
5. Modifying the event in TB78

I can provide packet capture trace of the communication between TB78 and DavMail if that would help. I see the initial communication between TB78 and the CalDAV service, but TB78 stops after the initial dialog, whereas TB68/Lightning has lengthy dialog with all the event data being transferred. For some reason, TB78 is not downloading anything. I suspect TB78 is not parsing the data returned in the initial dialog in the same way as TB68/Lightning.

Actual results:

1. No calendar data in the existing calendar is displayed in TB78.
2. The new event is created as expected, and I can see it in O365.
3. Nothing expected in TB78 until the next step.
4. The sync failed, ie, TB78 still shows the old event data.
5. AHA! TB78 complains that the change being proposed conflicts with the change made externally. If I allow the change to be made, it completes successfully.

Expected results:

1. All existing events in the calendar should have been fetched and displayed.
2. Same as what actually happened.
3. Nothing expected until the next step.
4. The changed event should have been synced into TB78.
5. There should have been no warning, because the event was previously synced, and the change loaded into the upstream calendar.

Comment 1

[David Potterveld]

To elaborate a bit further:

WIth TB68+Lightning, I see the following packets being exchanged:

Out: HTTP/XML, PROPFIND /users/dpotterv%40anl.gov/calendar/ HTTP/1.1
In: HTTP, HTTP/1.1 401 Unauthorized
Out: HTTP/XML, PROPFIND /users/dpotterv%40anl.gov/calendar/ HTTP/1.1 (with authentication data)
In: HTTP/XML, HTTP/1.1 207 Multi-Status
Out: HTTP, OPTIONS /users/dpotterv%40anl.gov/ HTTP/1.1
In: HTTP, HTTP/1.1 200 OK

and it goes on, a normal looking dialog.

With TB78, I only see the beginning of this. There is the first PROPFIND, the Unauthorized response, the second PROPFIND with authorization data, and the Multi-Status response. After that, nothing. TB78 sends nothing further.

So I'm guessing there's something in the Multi-Status response that TB78 doesn't like. There's quite a bit of data in all the XML payloads that I could provide, if it helps.

Comment 2

[Paul Morris [:pmorris]]

Thanks for the details David. Do you see any messages or errors in the console? Could you try setting some logging preferences to get more details on what's going on? Here's how:

In Thunderbird, go to preferences (called options on windows), then to the general section, scroll all the way down, press config editor button, accept the risk, search for "calendar.debug.log" and "calendar.debug.log.verbose" and set them both to true. Then you should see more details in the console about what's happening.

Edit: Any other details you can provide would be appreciated, particularly what's in that multi-status response where things are breaking down.

Comment 3

[David Potterveld]

Attachment: TB78 calendar verbose debug console log

Comment 4

[David Potterveld]

Thanks, Paul, for the tip about logging to the console. I've attached the entirety of what was logged in verbose mode for an attempted calendar sync. I'm not sure how relevant the "TypeError: impl is null" entries are. I think the problem is the "TypeError: response.firstProps['D:supported-report-set'] is undefined" entry. You can see the multi-status response just above that.

From my quick browse of RFC4791, I would conclude that this is a mandatory response that is missing from the DavMail server, and that TB is blameless for stopping as a result, even if in earlier versions (TB68+Lightning) it didn't complain. (I have also done the same console logging for TB68+Lightning and it did NOT throw this error.)

I await expert conclusion, but I suspect I am going to have to take this up with the DavMail maintainer(s) and suggest they are not in compliance with the RFCs.

Many thanks again!

Comment 5

[Paul Morris [:pmorris]]

Thanks David, looking at the log I see that this is a duplicate of bug 1649036. The fix should make its way to 78 soon. I would encourage you to report it to the DavMail maintainer(s) as well.