Spinner hangs on forbidden CalDAV write (Nextcloud Calendar frontend)

Steps to reproduce

1. Log in to Nextcloud as the calendar owner (e.g. alice).
2. Open the Calendar app (/apps/calendar) and hard-reload (Cmd+Shift+R) to avoid stale SPA state.
3. Navigate to a month containing such a locked event (e.g. April 2026).
4. Click the event to open its popup.
5. Open the “…” menu and click Delete (Löschen).
6. Observe the network request and the UI.

Expected behavior

On a 403 (or any 4xx) response, the spinner should stop and the app should surface an error message (e.g. “Could not delete event”), leaving the event intact and the UI in a usable state — rather than hanging indefinitely.

Actual behavior

Request: DELETE /remote.php/dav/calendars//.ics → 403 Forbidden.
Response body is a well-formed DAV error:
<d:error xmlns:d="DAV:" xmlns:s="http://sabredav.org/ns">
<s:exception>Sabre\DAV\Exception\Forbidden</s:exception>
<s:message>…</s:message>
</d:error>
UI: a loading spinner appears in the popup and never disappears (still spinning after 10+ seconds). No error toast / message is shown. The event is not removed.
The same happens for Edit: change the event’s end date and save → the change is never persisted and the UI gives no error feedback (a “Discard changes?” dialog appears, but no save/error path resolves).

Calendar app version

6.5.0

CalDAV-clients used

none

Browser

Chrome

Client operating system

MacOS

Server operating system

Web server

Apache

Database engine version

MySQL

PHP engine version

PHP 8.4

Nextcloud version

34

Updated from an older installed version or fresh install

Fresh install

List of activated apps

Nextcloud configuration

Web server error log

Log file

Browser log

Additional info

When the Nextcloud Calendar web app sends a DELETE (or PUT) for a calendar object and the server responds with HTTP 403 Forbidden, the app shows a loading spinner in the event popup that never resolves and no error message is shown to the user. The object is correctly left unchanged on the server.
The server behaves correctly (rejects the operation with a 403 and a descriptive message); the issue is purely the frontend’s handling of the error response.
The Calendar app also shows Edit/Delete controls for events whose per-object ACL grants only {DAV:}read, i.e. it does not consult the object’s {DAV:}current-user-privilege-set when deciding which controls to show. This is what lets the user trigger the operation in the first place.

Reproduce the forbidden DELETE and PUT flows in the Calendar app and trace the frontend handling of those requests and the event popup controls. Confirm that 4xx responses stop the spinner and show an error, leave the event unchanged, and that controls respect the reported read-only privilege state.