Closed Bug 1599602 Opened 2 years ago Closed 2 months ago

Lightning: Do not assume that a scheduling user who has CalDAV-OUTBOx does have CalDAV-INBOX


(Calendar :: Provider: CalDAV, defect)

Lightning 68
Not set


(thunderbird_esr78 fixed)

88 Branch
Tracking Status
thunderbird_esr78 --- fixed


(Reporter: dpa-mozilla, Assigned: dpa-mozilla)



(1 file, 1 obsolete file)

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.0 Safari/605.1.15 Epiphany/605.1.15

Steps to reproduce:

Per , when setting up an account for nobody (either just with hostname or with anonymous@domain ) user in TbSync/DAV-4-TbSync, the createt pseudo user can have Scheduling-OUTBOX, as it can make sense to query for FREEBUSY information of other users, if this information is intentionally not proteced by password.

However for the anonymous user it makes no sense to have Scheduling-INBOX.

The code in Lightning assumes, that if there is only one calendar-home-set then the user must have Scheduling-INBOX. This is first incorrect. If a user has Scheduling-INBOX then it can have several homesets and probably the user can have no home-sets but still have a scheduling-outbox or Inbox.

So the work-around is to return one more empty home-set and then Lightning just fetches the data.

Component: Untriaged → General
Product: Thunderbird → Calendar
Version: 68 → unspecified
Component: General → Provider: CalDAV
Version: unspecified → Lightning 68
Attached patch pr1599602.patch (obsolete) — Splinter Review

I use Thunderbird 78.8.0. I unzipped omni.ja, modified as shown in the attachment, zipped again omni.ja and now it works.

Rationale: my system offers unauthenticated CalDAV access (no WWW-Authorization headers are set). The unauthenticated user gets one calendar-home-set in the answer, one schedule-outbox-URL (as the unauthenticated user is in theory entitled to query the free busy status of some users), but no schedule-inbox-URL. This lead to calling “this.mInboxUrl = createBoxUrl(null)” which threw an exception.

  • Handle the case, when a CalDAV user has no scheduling-inbox
  • e.g. by setting mShouldPollInbox to false

I will appreciate very much if the fix in included in the next minor release.

I've updated your patch and approved it to land.

Attachment #9207666 - Flags: review+
Attachment #9206847 - Attachment is obsolete: true
Assignee: nobody → geoff
Ever confirmed: true
Target Milestone: --- → 88 Branch
Assignee: geoff → dpa-mozilla

Pushed by
Do not assume the presence of a CalDAV inbox URL. r=darktrojan

Closed: 2 months ago
Resolution: --- → FIXED

Can this be backported to ESR78?

I want to offer anonymour CalDAV access to calenders, but due to this bug, the CalDAV server currently has to return two calendar-home-sets. The second calendar-home-set must be returned, but can be empty. Iterating over the empty calendar-home-set is extra HTTP calls, both for server and client. These calls are done by all CalDAV clients (not only TB), as the server returns two calendar-home-sets. I want to avoid these extra PROPFIND calls on the empty calendar-home-set. The proposed patch does avoid them.

Therefore I ask to backport the change to ESR.

The change is really minimal.

I kindly ask to backport this trivial fix to ESR78. Using open standards with open source software is a chicken-egg problem. To get it working under Thunderbird 78, the server has to return two calendar-home-sets. When Apple devices see two calendar-home-sets, they handle the first one and ignore the others.

So to get this all working, under Thunderbind ESR and Apple, the server has to return two calendar-home-sets and all the content must be in the first calendar-home-set, while the second calendar-home-set is ignored by Apple. but required by TB78. It is really very hard to build a server, that works around bugs in all CalDAV clients.

Resolution: FIXED → ---

Please don't change the status of bugs. Use the "request information from" box at the bottom. I'll request uplift to 78 now.

Closed: 2 months ago2 months ago
Resolution: --- → FIXED

Comment on attachment 9207666 [details] [diff] [review]

[Approval Request Comment]
Regression caused by (bug #):
User impact if declined: Just a bug fix for some configurations of calendar
Testing completed (on c-c, etc.): Will be in 88 beta
Risk to taking this patch (and alternatives if risky): Very little.

Attachment #9207666 - Flags: approval-comm-esr78?

Comment on attachment 9207666 [details] [diff] [review]

[Triage Comment]
Approved for esr78

Attachment #9207666 - Flags: approval-comm-esr78? → approval-comm-esr78+
You need to log in before you can comment on or make changes to this bug.