can only choose iCalendar (ics) - should offer CalDAV under the “Multiple calendar types”
Categories
(Calendar :: Provider: CalDAV, enhancement)
Tracking
(thunderbird_esr78 unaffected)
Tracking | Status | |
---|---|---|
thunderbird_esr78 | --- | unaffected |
People
(Reporter: dpa-mozilla, Assigned: rnons)
References
(Regression)
Details
(Keywords: regression)
Attachments
(1 file)
(deleted),
text/x-phabricator-request
|
Details |
User Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:81.0) Gecko/20100101 Firefox/81.0
Steps to reproduce:
In TB82.0b2 I select “+ add calendar” and enter as URL https://aaa.bapha.be:444/dav/calendars/user/aaa@bapha.be/9383fd0a-4a99-4409-8d3b-51e516d945a5/ . This URL can deliver the data over CalDAV or as one big file/icalendar VCALENDAR stream. Thunderbird says:
Multiple calendar types are available for this location. Please select the calendar type, then mark the calendars you would like to subscribe to.
Calendar Type:
The only choice is iCalendar (iCS).
Moreover TB makes two PROPFIND calls on that URL.
First PROPFIND call:
<D:propfind xmlns:D='DAV:' xmlns:A='http://apple.com/ns/ical/'>
<D:prop>
<D:getcontenttype/><D:resourcetype/><D:displayname/><A:calendar-color/>
</D:prop>
</D:propfind>
second PROPFIND call
<?xml version="1.0" encoding="UTF-8"?>
<D:propfind xmlns:D='DAV:' xmlns:A='http://apple.com/ns/ical/' xmlns:C='urn:ietf:params:xml:ns:caldav'>
<D:prop><D:resourcetype/><D:owner/><D:displayname/><D:current-user-principal/><A:calendar-color/><C:calendar-home-set/>
</D:prop>
</D:propfind>
What does TB do with the OWNER property?
Actual results:
There shall be only one PROPFIND call on the URL and resourcetype shall not be queried twice.
TB shall offer CalDAV under the “Multiple calendar types”. Since mortals do not know what is the difference between iCalendar stream, which is updated as a whole based on ETag logic, and CalDAV, such complicated questions shall not be asked to the users. There is no reason, why shall one prefer iCalendar over CalDAV and cause more traffic for the client and for the server.
When CalDAV is offered (or pure WebDAV sync without CalDAV) , use CalDAV (webdav sync).
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Assignee | ||
Comment 2•4 years ago
|
||
(In reply to Дилян Палаузов from comment #0)
Calendar Type:
The only choice is iCalendar (iCS).
This should be fixed by bug 1652984.
There shall be only one PROPFIND call on the URL and resourcetype shall not be queried twice.
TB shall offer CalDAV under the “Multiple calendar types”. Since mortals do not know what is the difference between iCalendar stream, which is updated as a whole based on ETag logic, and CalDAV, such complicated questions shall not be asked to the users. There is no reason, why shall one prefer iCalendar over CalDAV and cause more traffic for the client and for the server.
I think we should default to CalDAV when it's available. Because if ics is selected for a CalDAV, a few things don't work.
Comment 3•4 years ago
|
||
I just tested TB 84.0b3 and successfully created a CalDav calendar for my iCloud calendar. For me the issue is resolved.
Assignee | ||
Comment 4•4 years ago
|
||
Regressed by D78371.
Assignee | ||
Updated•4 years ago
|
Assignee | ||
Updated•4 years ago
|
Pushed by geoff@darktrojan.net:
https://hg.mozilla.org/comm-central/rev/ebf5c9f64b85
Fix calendar creation dialog to default to CalDAV when available. r=darktrojan
Updated•4 years ago
|
Description
•