Describe the bug
When a multi-page PDF file is shared through a public ownCloud Web / oCIS link, the recipient is shown the ownCloud web viewer instead of the PDF being opened directly by the browser or the native mobile PDF viewer.
On smartphone-sized viewports this is misleading. The interface initially shows the first PDF page, while page navigation and the download/open action are not obvious. The download action is hidden behind the small three-dot menu in the top-right corner.
Many non-technical recipients do not discover this menu and therefore believe that the PDF only contains the first visible page, although the shared PDF actually contains multiple pages.
This creates real communication problems: senders have to explain repeatedly that the file must be downloaded through the hidden menu before it can be read properly.
This is a usability bug, not a feature request. The current mobile public-link PDF viewer causes recipients to misinterpret the document.
Steps to reproduce
1. Upload a multi-page PDF file to oCIS.
2. Create a public link for this PDF file.
3. Open the public link on a smartphone or in a browser with a smartphone-sized viewport, for example an iPhone viewport.
4. Observe the initial public-link PDF viewer interface.
5. Try to determine, as a non-technical external recipient, whether the document has more than one page.
6. Try to find the download/open action without prior knowledge of the three-dot menu in the top-right corner.
Expected behavior
Public links to PDF files should provide a recipient-safe mobile experience.
For multi-page PDFs, the public-link interface should make it immediately obvious that the document contains multiple pages and how the recipient can access the complete file.
At least one of the following would solve the problem:
- Open public PDF file links directly as PDF resources, so that the browser or native mobile PDF viewer handles the file.
- Provide a server-side or web-app configuration option to make public PDF links open or download directly by default.
- Show a clearly visible primary action such as "Download PDF" or "Open PDF" on the public-link page, especially on mobile.
- Improve the mobile PDF viewer so that multi-page navigation is obvious and discoverable without using the hidden three-dot menu.
Actual behavior
The recipient lands in the ownCloud Web public-link interface.
On mobile, the PDF is embedded inside the ownCloud web viewer. The first page is visible, but the interface does not make it sufficiently clear that the document has additional pages.
The download/open action is hidden behind the small three-dot menu in the top-right corner.
As a result, many external recipients believe that the PDF only contains one page. This is incorrect for multi-page PDFs and causes misunderstandings in normal business communication.
Setup
- Web version: unknown
- oCIS version: 7.3.1
- Browser: mobile browsers / smartphone-sized viewport, observed with public PDF links
Deployment:
- oCIS bare-metal installation
- Ubuntu 24.04
- Public share use case: external recipients opening PDF files through public links
Additional context
Example public share URL:
https://file.conserve.de/s/FKXEDQuCTxNUrsQ
The main problem is not that opening or downloading the file is technically impossible. The problem is that the current mobile public-link PDF viewer creates a misleading recipient experience: users believe that a multi-page PDF only contains the first visible page.
This is related to, but not the same as:
A pragmatic implementation direction could be a configuration option such as:
- PUBLIC_LINK_PDF_DIRECT_OPEN=true
- PUBLIC_LINK_PDF_DIRECT_DOWNLOAD=true
or a MIME-type based rule for public links, for example:
application/pdf => direct open/download
This would allow administrators to choose the safer recipient UX for public PDF links without changing general public-link behavior for folders or other file types.
Describe the bug
When a multi-page PDF file is shared through a public ownCloud Web / oCIS link, the recipient is shown the ownCloud web viewer instead of the PDF being opened directly by the browser or the native mobile PDF viewer.
On smartphone-sized viewports this is misleading. The interface initially shows the first PDF page, while page navigation and the download/open action are not obvious. The download action is hidden behind the small three-dot menu in the top-right corner.
Many non-technical recipients do not discover this menu and therefore believe that the PDF only contains the first visible page, although the shared PDF actually contains multiple pages.
This creates real communication problems: senders have to explain repeatedly that the file must be downloaded through the hidden menu before it can be read properly.
This is a usability bug, not a feature request. The current mobile public-link PDF viewer causes recipients to misinterpret the document.
Steps to reproduce
Expected behavior
Public links to PDF files should provide a recipient-safe mobile experience.
For multi-page PDFs, the public-link interface should make it immediately obvious that the document contains multiple pages and how the recipient can access the complete file.
At least one of the following would solve the problem:
Actual behavior
The recipient lands in the ownCloud Web public-link interface.
On mobile, the PDF is embedded inside the ownCloud web viewer. The first page is visible, but the interface does not make it sufficiently clear that the document has additional pages.
The download/open action is hidden behind the small three-dot menu in the top-right corner.
As a result, many external recipients believe that the PDF only contains one page. This is incorrect for multi-page PDFs and causes misunderstandings in normal business communication.
Setup
Additional context
Example public share URL:
https://file.conserve.de/s/FKXEDQuCTxNUrsQ
The main problem is not that opening or downloading the file is technically impossible. The problem is that the current mobile public-link PDF viewer creates a misleading recipient experience: users believe that a multi-page PDF only contains the first visible page.
This is related to, but not the same as:
A pragmatic implementation direction could be a configuration option such as:
or a MIME-type based rule for public links, for example:
application/pdf => direct open/download
This would allow administrators to choose the safer recipient UX for public PDF links without changing general public-link behavior for folders or other file types.