.pdf file loses filename on download

[tbsbdr]

Steps to reproduce

1. Ensure in your browser settings, that your browser does not act as PDF-viewer
2. open demo.owncloud.com and login
3. click on a pdf-file, eg. ownCloud Manual.pdf
4. The download dialog shows then 7de6d7ad-60b2-4d71-81b8-273bb60d4cc8 (without extension) as the downloaded file name (current chrome or safari). On Firefox the downloaded file is just called pdf (without extension)

Expected behaviour

original filename should be kept

Actual behaviour

filename changes to a uuid 7de6d7ad-60b2-4d71-81b8-273bb60d4cc8 or pdf depending on the browser

[fschade]

@tbsbdr there is only one way to workaround the described issue.

If we decide to always download a pdf (instead of opening it in a new tab and let the browser handle the pdf rendering) we can enable it! But then we loose the ability to preview the file in the browser (even if the user has the browser preview enabled)

the uid you see here is how the browser internally stores the blob and references it.

[tbsbdr]

yep, the browser behaviour (=user setting) should be respected - i.e. no "download" attribute in the link.
"As a user who left-clicks on myDocument.pdf in the fileslist, I expect that the same thing happens like on any other website when I click on a pdf."

If the user chooses rightclick -> download then a download should start.

[tbsbdr]

As discussed: lets use presigned URLs instead of blobs so that the browser can preview or download - depending on its settings.

[fschade]

@tbsbdr as discussed i tried the preSigned url which worked expect that the backend uses "Content-Disposition: attachment".

This force downloads the requested file.

The only possible solution i can think of is to change the webdav behavior in oc10 and ocis to support switching "Content-Disposition: inline"

[tbsbdr]

inline would also be "wrong" if this means, that the backend and not the browser defines the behaviour in this usecase. would it be possible to just don't send the content disposition header so that the decision is up to the browser?

1. minimum goal is to not loose the filename
2. cherry on top: let the browser decide about download or view

[kulmann]

I'd like to follow up here and bring @C0rby to the game.

Is it a good idea to provide a downloadUrl and an inlineUrl, both signed, backend side? With Content-Disposition: attachment and Content-Disposition:inline respectively. And of course for both authenticated contexts and public links. Then the implementation in web would be super slim.

[C0rby]

I think we need to add this to the next sprint. This needs some thinking through first. I would like to have the signed URL only on-demand because the signing is actually a bit of a computational heavy operation and doing it on every PROPFIND isn't very efficient because you don't need the signed URLs every time.

[diocas]

This issue seems a bit more generic than what I understood from our discussion this morning. But let me add our 2 cents...

From our point of view, the current preview implementation also has issues because we cannot bookmark/reuse the url (and is non understandable by users as well). At the same time, we lose the branding which might be considered inconsistent with all the other extensions.
But the biggest issue, and the one that caused many complains from users, is that there is no (loading) feedback. Meaning that if we try to open a large PDF, nothing happens because the browser needs to download it first, and only then opens the new tab with the preview. And users kept clicking, which then would do another download and eventually replace the current open tab.

I'm also not a big fan of having signed urls since they will become invalid after expiration. So the idea of putting it inside an iframe, where we show a pretty normal app url to the user and hide all this logic, is better.

We've tried to do the iframe method, and still use the browser native renderer. This solved all the issues I mentioned but it created a major one that I haven't been able to fix: the presentation mode no longer works! (even with allowfullscreen).
Maybe the usage of a library could be reconsidered as well?

[kulmann]

@diocas I like your solution a lot. Could you provide a PR so that we can check as well if we manage to get the fullscreen support running? In any case, using an iframe to bypass the issues you mentioned and still use the browsers native pdf support is just awesome.

[diocas]

Done, but the issue with the proper name missing is still there unfortunately..

[tbsbdr]

But the biggest issue, and the one that caused many complains from users, is that there is no (loading) feedback. Meaning that if we try to open a large PDF, nothing happens because the browser needs to download it first, and only then opens the new tab with the preview. And users kept clicking, which then would do another download and eventually replace the current open tab.

@diocas I made a "Add progress indicator for ui-interactions" issue here #6183 ticket is currently not prioritised but I'll discuss with benedikt if we can give it a higher prio.

[lookacat]

@tbsbdr Seems to be working now..

[tbsbdr]

jep, can confirm that "download" does not loose the filename any more.