Bug 403782 - Okular trying to save a PDF to an URL location
Summary: Okular trying to save a PDF to an URL location
Status: CONFIRMED
Alias: None
Product: okular
Classification: Applications
Component: general (show other bugs)
Version: 1.6.1
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: Okular developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-01-30 20:54 UTC by avlas
Modified: 2019-02-01 13:59 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description avlas 2019-01-30 20:54:09 UTC
SUMMARY

Not sure this is an issue of okular (or kio or ...), but when saving a pdf file in okular that was loaded via an URL with ctrl+shift+s (save as), okular defaults the path to the URL as if it was a local path.


STEPS TO REPRODUCE
1. Open Okular
2. Open file
3. Set a URL to a pdf file, e.g., https://www.biorxiv.org/content/biorxiv/early/2019/01/27/
4. Save the PDF file (save as ctrl + shift +s)

OBSERVED RESULT

Okular tries to save the above PDF file to https://www.biorxiv.org/content/biorxiv/early/2019/01/27/

EXPECTED RESULT

Okular should default to a local path (e.g., $HOME, or Downloads, or Documents, or last path used) instead of the original remote URL


SOFTWARE/OS VERSIONS

KDE neon 5.14
Plasma 5.14.5
Qt 5.11.2
Frameworks 5.54.0
Linux 4.18.0-14-generic
64 bits

ADDITIONAL INFORMATION

Copying Info from About System should have an option to copy in English to ease bug reporting ;)
Comment 1 Viorel-Cătălin Răpițeanu 2019-01-31 00:23:43 UTC
I can confirm that this behaviour is reproducing with the latest 1.6.1 version.
Comment 2 Albert Astals Cid 2019-01-31 18:19:24 UTC
I disagree. Saving to a remove url (for example smb:/ is more than fine), the "problem" here is that you cna't really save to https, so in this case, yes ideally it should detect that the url is non writeable and offer a writeable loccation, but defaulting to a local path is wrong.
Comment 3 avlas 2019-01-31 18:21:50 UTC
I totally agree. I wasn't precise.
Comment 4 Viorel-Cătălin Răpițeanu 2019-01-31 19:44:28 UTC
(In reply to Albert Astals Cid from comment #2)
> I disagree. Saving to a remove url (for example smb:/ is more than fine),
> the "problem" here is that you cna't really save to https, so in this case,
> yes ideally it should detect that the url is non writeable and offer a
> writeable loccation, but defaulting to a local path is wrong.

Yes. Another thing is that save location also included the file name.
In my case, when I opened an online pdf (http://www.africau.edu/images/default/sample.pdf),
the save location was: http://www.africau.edu/images/default/sample.pdf/
Comment 5 Laura David Hurka 2019-01-31 21:32:38 UTC
avlas' use case is (similar to)
1. clicking a PDF link in a web browser -> opens in Okular
2. wanting to keep the PDF file
3. clicking Save As (because Save obiously doesn't work)

Then avlas wants Save As to suggest ~/Downloads or ~/Documents, because it is obious to the user that saving to the web is not possible and not useful.

But saving to the web could be useful e. g. with webdavs, so I think this should be configurable.
[x] If document URL protocol is [http, https, ...      ]
    suggest saving in           [~/Downloads         V ]

Better would be
[_] If document URL is non-writable [...]
but I didn't see this option in KIO right now.
Comment 6 Laura David Hurka 2019-02-01 10:29:54 UTC
I thought a bit about this.

(In reply to David Hurka from comment #5)
> Better would be
> [_] If document URL is non-writable [...]

This could be confusing, if URLs randomly appear to be non-writable.

Also, other KDE applications (KMail, Falkon) copy remote PDFs to /tmp/, so this would be more useful:
[x] If document URL begins with [/tmp/, http://, https://, ...]
    (_) Suggest saving in       [~/Downloads     V ]
    (o) Suggest saving in last used directory
Comment 7 avlas 2019-02-01 13:59:30 UTC
I realized of two things:

1) This is not only about PDF's, it also happens for remote images (e.g., in a browser)

2) In the "Save As" window: 

While the path is that of the remote URL, the content that you see is that of the last local path used, which is inconsistent (and likely makes the user to miss the URL path on top, as it is less salient, only realizing about that once the saving error message is displayed). This can be reproduced by, e.g., saving >1 remote PDF's.

So, it seems kio, or whichever is displaying such content, defaults to the last path (wondering if because the URL is non-writable (?) if so, the same approach could also be used for the path on top). In contrast, the path on top defaults to the original URL (sometimes wrongly assuming that the filename is a subfolder, as indicated in https://bugs.kde.org/show_bug.cgi?id=403782#c4).