Bug report: PDF public share opens with Collabora after enabling custom permissions

Hello,

I found a reproducible issue with public PDF shares when both files_pdfviewer and richdocuments are enabled.

Environment

Nextcloud version: 33.0.5
Nextcloud Office / richdocuments: 10.1.3
PDF Viewer / files_pdfviewer: 6.0.0
Collabora CODE: unknown / not checked yet
Browser: Microsoft Edge / Chromium
User context: public share link, opened as guest without login

Problem

When I create a normal public share link for a PDF file with “View only” permission, the PDF opens correctly with the standard Nextcloud PDF Viewer (files_pdfviewer).

However, as soon as I enable “Custom permissions” for the same public share link, the PDF no longer opens with the standard PDF Viewer. Instead, it opens with Collabora / Nextcloud Office (richdocuments), even if only the Read permission is enabled.

The problematic part is that this behavior persists even after switching the share back to normal “View only”. The only way to restore the correct PDF Viewer behavior is to delete the public share link completely and create a new one.

Steps to reproduce
Install and enable both apps:
files_pdfviewer
richdocuments
Upload any PDF file to Nextcloud.
Create a public share link for this PDF file.
Leave the share permission as normal “View only”.
Open the public share link in another browser, private window, or as a guest user.
Result: the PDF opens correctly with the standard Nextcloud PDF Viewer.
Go back to the share settings.
Enable “Custom permissions” for the same public share link.
Leave only the Read permission enabled. Do not enable edit/create/upload permissions.
Open the same public share link again as a guest.
Result: the PDF now opens with Collabora / Nextcloud Office instead of the standard PDF Viewer.
Go back to the share settings and switch the share back to normal “View only”.
Open the public share link again as a guest.
Result: the PDF still opens with Collabora / Nextcloud Office.
Delete the public share link completely.
Create a new normal public share link for the same PDF file.
Open it again as a guest.
Result: the PDF opens again with the standard PDF Viewer.
Expected behavior

A PDF public share with read-only permissions should always open with the standard Nextcloud PDF Viewer when files_pdfviewer is installed and enabled.

Enabling “Custom permissions” with only the Read permission should not change the viewer application from files_pdfviewer to richdocuments.

Switching back from “Custom permissions” to normal “View only” should also restore the original behavior.

Actual behavior

After enabling “Custom permissions” on a public PDF share, the PDF opens with Collabora / Nextcloud Office instead of the standard PDF Viewer.

This happens even when only the Read permission is enabled.

The behavior remains even after switching the share back to normal “View only”.

Only deleting and recreating the public share link restores the standard PDF Viewer behavior.

Additional observations

If files_pdfviewer is disabled or removed, PDF files open with Collabora / Nextcloud Office.
If files_pdfviewer is enabled again, newly created normal public PDF shares open correctly with the standard PDF Viewer.

So it looks like the viewer selection for PDF files changes after enabling custom permissions on the public share. It seems that the public share receives some changed metadata or attributes, and after that richdocuments takes over the PDF handling even though the share is still read-only.

This is especially problematic because the “Hide download” option is only available inside the custom permissions/advanced share settings. So users who want to hide the download button for a read-only PDF public share are forced to enable custom permissions, but then the PDF viewer changes unexpectedly to Collabora.

Workaround

Delete the affected public share link and create a new normal “View only” public share link.

But this workaround does not allow using “Hide download” without triggering the issue.

Question

Is this expected behavior, or should read-only PDF public shares with custom permissions still be handled by files_pdfviewer when that app is installed and enabled?

Reproduce the public-share flow with files_pdfviewer and richdocuments enabled, comparing a normal View-only share with one changed to Custom permissions and then changed back. Inspect the share state and viewer selection across those transitions. Done means a read-only PDF continues using files_pdfviewer, including after Custom permissions is disabled again.