Skip to content

Conversation

@backportbot-nextcloud
Copy link

@backportbot-nextcloud backportbot-nextcloud bot commented Jan 28, 2021

⚠️ This backport had conflicts and is incomplete ⚠️

backport of #291

Before the move to the viewer the URL of the PDF file to load was got
using "Files.getDownloadUrl()", which encodes each section of the path
as a URI component. The full URL, in turn, was again encoded as a URI
component to set the source of the iframe in which the PDF viewer is
loaded. When the PDF viewer parsed the URL it decoded it once, so each
section of the path was still encoded as a URI component.

After the move to the viewer the URL of the PDF file to load was got
from the "davPath" property set by the viewer, which uses the filename
as is. The full URL was then encoded as a URI component, so when the PDF
viewer parsed and decoded the URL the raw filename was used. In most
cases it worked fine, but if the filename included some special
character, like "?", the file failed to load.

Now, instead of using the "davPath" property set by the viewer, each
section of the dav path is encoded as a URI component. The encoding
tries to not make any assumption on the format used by the viewer to
avoid being coupled too much.

Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
@danxuliu danxuliu force-pushed the backport/291/stable20 branch from 46829d8 to c992b55 Compare January 28, 2021 17:24
Copy link
Member

@danxuliu danxuliu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tested and works 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants