Bug 465368 - File dialogs don't handle sftp/fish redirects well
Summary: File dialogs don't handle sftp/fish redirects well
Status: REPORTED
Alias: None
Product: frameworks-kio
Classification: Frameworks and Libraries
Component: Open/save dialogs (show other bugs)
Version: 5.102.0
Platform: openSUSE Linux
: NOR normal
Target Milestone: ---
Assignee: KIO Bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2023-02-06 13:33 UTC by Grósz Dániel
Modified: 2023-02-17 11:49 UTC (History)
1 user (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 Grósz Dániel 2023-02-06 13:33:51 UTC
SUMMARY
If you enter an sftp or fish URL without any path in the location bar (or the Name field) of an Open or Save dialog, the dialog normally redirects to the user's home directory on the server, as SFTP clients usually do. However, if you select a file in the home directory, or enter a file name, the dialog treats it as if you meant a file in the server's root directory.

In an Open dialog, it will typically say that the file does not exist. In the unusual case where a file exists in the root directory with the same name as the file you selected in the home directory, it returns that file; if you select a regular file in your home directory, and a directory with the same name exists in the root, it switches to that directory. In a Save dialog, the dialog will return a file in the root directory. In the unlikely case that files with the same name exist in the home and in the root, you select the one in the home directory, and you confirm that you want to overwrite it, the dialog returns the one in the root (and the application will overwrite a different file than you intended if you have the permissions!).

The behavior of the Up button when used immediately after getting on the remote server is also buggy: it goes immediately to the server's root directory, skipping intermediate directories. But sanity returns once you change folders, either by clicking a folder or using the Up button: after that, the dialog seems to know where it is.

The bug only comes up if you enter the URL without any path, not even a trailing slash. If you enter a trailing slash, it opens the server's root directory without any redirection, and it behaves normally. Also, Dolphin seems to be unaffected.

STEPS TO REPRODUCE
1. Open an Open/Save dialog that accepts remote files, e.g. kdialog --getopenurl or kdialog --getsaveurl.
2. Write sftp://user@host in the location bar or the Name input field, and press Enter.
3. Select a file or enter a name in the Name input.

OBSERVED RESULT
After Step 2, the dialog typically goes to something like sftp://user@host/home/user (or at least it appears to, both in terms of the files listed, and the contents of the location bar). After Step 3, the dialog acts as if you meant a file in sftp://user@host/ (e.g. opens/saves to it), rather than sftp://user@host/home/user .

EXPECTED RESULT
The dialog opens or saves to a file in sftp://user@host/home/user .

It would also be better than the current behavior if the dialog ignored the redirect and opened the server's root directory.

SOFTWARE/OS VERSIONS
Operating System: openSUSE Tumbleweed 20230204
KDE Plasma Version: 5.26.5
KDE Frameworks Version: 5.102.0
Qt Version: 5.15.8
Kernel Version: 6.1.7-1-default (64-bit)
Graphics Platform: X11

ADDITIONAL INFORMATION
I don't know if the issue affects any protocol other than sftp and fish. I don't remember if ftp has a similar redirect functionality, as I haven't used it in ages; I've no idea about stuff smb, ldap, webdav or gdrive. Also, there was a similar redirect  bug 345199 a few years ago with kdeconnect (also affecting Dolphin, eventually auto-closed).
Comment 1 Grósz Dániel 2023-02-17 11:49:11 UTC
I wrote that Dolphin was unaffected, but since then I found that it's actually affected by a similar issue (or in a sense an inverse of this one): there, the Location bar doesn't reflect the redirect, but otherwise (e.g. if a file is opened) it behaves correctly: Bug 465915.