1666036 - Network calendar detected as ICS instead of CALDAV type

Status: RESOLVED DUPLICATE of bug 1670420

(Calendar :: Provider: CalDAV, defect)

Description

[Richard Leger]

This bug was created following suggestion from Paul in Bug 1543953 Comment 22

"...This could be somewhat related to the work in bug 1663399.
That is troubling that you expected a CalDAV calendar but got an ICS one instead..."

Steps to reproduce:

• Updated when prompted to 81.0b4 (64-bit) from 81.0b3 (64-bit)
• Create a new empty profile
• Skip Integration
• Skip Creating new email account
• Go to Calendar Tab
• Right click in Calendar column
• Select New Calendar in context menu
• Select On the Network + Next
• Username: richard
• Location: https://remote.myserver.com/davical/caldav.php/richard/home
  (this is the address I always had to use in the past)
• Untick Online Support
• Click Find Calendars
• Enter Password
• OK
• Multiple calendar type available for this location... window appear
• In the Calendar Type selection box only iCalendar(ICS) appears listed - nothing else...
  (likely because the detection was done via GET request toward my calendar URL which Davical would return as .ics file if that is the case)
• My calendar appear listed below it and ticked already
• I click Subscribe button

Comment 1

[Richard Leger]

I think they are three major differences compared to previous TB behaviour:

• 1st - Previously when I was creating a network calendar, I was asked to choose via radio button if I wanted to set an ICS Calendar, a CalDAV one or a Google Calendar... those options no longer exist prior entering Username and Location information... it is now auto-detected.

• 2nd - Previously when I was creating a new CalDAV calendar, I could not just set the Location to the server, I had to put the full URL to the calendar resource I wanted to add - as I did in this Bug Description above... the problem is now because of 1st issue, the calendar type is auto-detected and no longer an end-user choice but when using Davical CalDAV server and setting the location to URL of the resource, a GET request would return the calendar in .ICS format causing the auto-detection system to detect it this way without allowing any longer end-user to change Calendar Type to CalDAV instead of ICS.

• 3rd - Now as I am no longer obliged to enter the full URL to the resource but can enter just the server name/path e.g remote.myserver.com/davical/caldav.php, if I do so, then all my available calendar are detected and I can choose those I want added or not. Once added, those appears and behave like CalDAV calendar type.

The confusion come from the fact that the user interface (aka Wizard) has changed slightly and the auto-detection is no longer allowing end-user to choose calendar type like before when using an URL to a specific resource. One would argue that it is not longer required but from the interface not very clear that end-user would obtain such behaviour from TB... it looks like a but and is a bug in a way...

The quick fix is not to use an URL to a specific resource but in theory this should still be possible and still allow end-user to choose calendar type CalDAV after the auto-detection has happened.

The great advantage of ICS type is that that my network calendar with 4000+ items loads in about ~20seconds compare to 7mn+ with CalDAV type calendar!!! So that has a great impact on performance but the drawback of ICS is that it is read-only while CalDAV allow to sync changes to the calendar.

Hope that clarify.

Comment 2

[Richard Leger]

I would also suggest to clarify direcltly in the selection box the level of access that the listed Calendar Type provide in TB something like:

iCalendar ICS - Read Only
CalDAV Calendar - Read & Write

This way it may be clearer to end user what's the difference between the two...

Also the type of calendar + level access could appear in the calendar Properties window once added.

It would be great also to:

• Allow end-user to enter Password directly in the add Calendar Wizard the same it is done for add Email Wizard:
  -- Location <-- It would make more sense to place Location in first position
  -- Username
  -- Password
• The add Calendar Wizard could be Layout/Theme the same way as the add Email Wizard
• In Location if you enter a Hostname e.g remote myserver.com TB should run a CalDAV auto-detect to find the CalDAV server URL (e.g https://remote.myserver.com/davical/caldav.php) in DNS or .well-known file on server. I think TBSync add-on does it.

Comment 3

[Richard Leger]

Hi Alex,

In my Bug 1666036 Comment 2 there are some UX/Theme suggestions you may want to look at for add Calendar Wizard.

Regards,

Comment 4

[Paul Morris [:pmorris]]

It sounds like you are seeing a "Calendar Type" selection box/menu after calendar detection happens, but it only has an ICS and not a CalDAV option in it. Does anything change if you check the "online support" checkbox?

Comment 5

[Richard Leger]

Attachment: profind.png

(In reply to Paul Morris [:pmorris] from comment #4)

It sounds like you are seeing a "Calendar Type" selection box/menu after calendar detection happens, but it only has an ICS and not a CalDAV option in it. Does anything change if you check the "online support" checkbox?

Checking the "online support" checkbox does not change the outcome.
I can still only see the ICS option and not the CALDAV option in Calendar Type selection box after auto-detection...

I was wondering if the issue could be linked to the following...

(In reply to Paul Morris [:pmorris] from Bug 1663399 comment 1)

The problem is the ICS calendar detection code tries various requests, including PROPFIND, HEAD, and PUT, but not a GET. Not all servers support HEAD, so the solution is to also try a GET request. That succeeds for e.g. the Thunderbird event calendar in the description above.

As Philipp mentioned on chat, ideally we could cancel the GET request after the headers were complete, since all we need for detection is the headers. I looked into this but couldn't figure out a way to do it, so I'm going ahead with a simple GET solution to fix the regression.

Try run in progress: https://treeherder.mozilla.org/#/jobs?repo=try-comm-central&revision=ae6e106803426423ec060176b2fde3870bde60fa

Adding "cancel GET request after headers" can be done as a follow-up improvement. Below are some notes about that.

How to cancel a request: https://searchfox.org/mozilla-central/source/netwerk/base/nsIRequest.idl#66

...but as you see in attachment, only two PROFIND requests are sent over the network during the auto-detection... no GET request... and no error appears in the console...

Comment 6

[Alex ARNAUD]

I also reproduce this issue but in a worst case. I use NextCloud Caldav private URL of an agenda shared with me and I've two issues:

• I couldn't select CalDav from the list as mentioned by Richard
• Even with ICS chosen I don't see any events on the newly added calendar

Comment 7

[Paul Morris [:pmorris]]

To comment 5: just two PROPFIND requests. The code is sending one of those for CalDAV and one for ICS, and since no other requests are made, it appears they both succeed. In that case the problem is that CalDAV is not offered as an option (and the default one) in the drop down menu on the final "calendars found" view in the dialog.

Comment 8

[Alex ARNAUD]

Hello Paul,

Do you plan to work on this issue?

I "just" ask here because currently I use my phone to see calendar because I could no longer add new CalDav calendar and see / manage events on them. I could "only" manage calendars added before this issue happened.

My implicit question is to determine whether or not I should switch to Thunderbird stable instead of Daily and it will depend of the future of this issue.

Thanks in advance.

Comment 9

[Wayne Mery (:wsmwk)]

(In reply to Alex ARNAUD from comment #8)

Hello Paul,

Do you plan to work on this issue?

This awaits a new developer

Comment 10

[Magnus Melin [:mkmelin]]

Is this a duplicate of bug 1670420 which we fixed. (85 beta and up has it fixed)
Can you check if it's working now?

Comment 11

[Alex ARNAUD]

(In reply to Magnus Melin [:mkmelin] from comment #10)

Is this a duplicate of bug 1670420 which we fixed. (85 beta and up has it fixed)
Can you check if it's working now?

It now works correctly, indeed, I was able to add a new calendar, many thanks.

I don't know if we want to wait a feedback of Richard Leger before closing this one but it works based on my tests.

Comment 12

[Magnus Melin [:mkmelin]]

Duping this. Please reopen if you still see the problem.

Comment 13

[Richard Leger]

Attachment: cakdav_detected.png

Just tested in a new blank profile in TB 85.0b3 (64-bit) and it is now correctly detected as CalDAV see attached.

Though as you would see on the picture, some data in the window seems truncated somehow... layout issue?

Not a big issue as this bug is fixed, but just thought to mention it... for info... likely a CSS margin issue somewhere perhaps...