Regarding the error message itself feel free to improve the wording :-) After several tries this is the best I could come up with :shrug:
Finally, note that before Nextcloud 28 when the PDF viewer was opened in public pages for a single share the UI was directly injected. When it was changed to use the viewer instead a fallback to directly inject the UI was left just in case the viewer was not available. This pull request only handles the disabled download permissions when the viewer is used, but not in the fallback case:
The viewer already provides the needed file info, so handling the error without the viewer is more involved, as the file info would need to be fetched before loading the file in PDF.js, or a handler in PDF.js for loading errors would need to be used (which I have not found how :shrug: I am sure there is an easy way and I just simply missed it, but it is not worth spending more time on that due to the next point)
In Nextcloud 31 public.js will go away (in another pull request) because it is no longer needed, so there will be no fallback at all. But also in Nextcloud 28 to 30 the fallback should never be used anyway; the viewer is expected to be always available, and if it is not or it did not properly load then something would need to be fixed, but keeping the fallback was just being overly cautious and it is not really needed.
How to test
Share a PDF file with another user
Customize the share and disable Allow download and sync
Fixes #649
Although the best fix would be to fallback to Collabora if available currently it does not seem to be possible to do that, so for now just an error message is shown.
Also, while it would be possible to use
this.$emit('error')
to notify the viewer that the file could not be loaded currently it does not seem possible to customize the message, so the standard Viewer error with Error loading {name of the file} would be shown. In this case it is worth explaning the reason, so the error is handled directly in the PDF viewer instead (but with the markup and style for the error element copied from the viewer). Maybe custom error messages will be possible in the future with the Viewer 4.0 API and then that code can go away :-)Regarding the error message itself feel free to improve the wording :-) After several tries this is the best I could come up with :shrug:
Finally, note that before Nextcloud 28 when the PDF viewer was opened in public pages for a single share the UI was directly injected. When it was changed to use the viewer instead a fallback to directly inject the UI was left just in case the viewer was not available. This pull request only handles the disabled download permissions when the viewer is used, but not in the fallback case:
public.js
will go away (in another pull request) because it is no longer needed, so there will be no fallback at all. But also in Nextcloud 28 to 30 the fallback should never be used anyway; the viewer is expected to be always available, and if it is not or it did not properly load then something would need to be fixed, but keeping the fallback was just being overly cautious and it is not really needed.How to test
Allow download and sync
Result with this pull request
An error message is shown
Result without this pull request
The PDF viewer is loaded, but contents are empty