https://bugs.kde.org/show_bug.cgi?id=520163
Bug ID: 520163
Summary: Cannot change path after visiting a kdeconnect:// path
Classification: Applications
Product: kdeconnect
Version First 26.04.1
Reported In:
Platform: openSUSE
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: desktop-application
Assignee: [email protected]
Reporter: [email protected]
Target Milestone: ---
DESCRIPTION
In Dolphin, Krusader, Gwenview, or KDE file dialogs, if I open an (Android)
device via KDE Connect, with a URL such as
kdeconnect://aaa1ef6d_9397_40a3_970e_f153a9107344/, and subsequently enter a
different path (whether an absolute local path, a local path starting with ~,
or a full URL starting with file:///, sftp:// etc.), instead of navigating
there, the location bar *appends* the new path to the kdeconnect:// path, and
in effect doesn't change what it shows at all.
STEPS TO REPRODUCE
1. Open a KDE Connect device in Dolphin, for instance via the KDE Connect
systray applet's "Browse this device" menu item. (I've tested it with an
Android device).
2. In the location bar, enter e.g. /home, and press Enter.
OBSERVED RESULT
The location bar's content changes to something like
kdeconnect://aaa1ef6d_9397_40a3_970e_f153a9107344/home/. The file manager shows
a virtual folder named Internal shared storage (in the case of an Android
device), just like initially.
EXPECTED RESULT
The location bar changes to /home, and the file manager shows the contents of
that directory.
SOFTWARE/OS VERSIONS
Operating System: openSUSE Tumbleweed 20260512
KDE Plasma Version: 6.6.4
KDE Frameworks Version: 6.26.0
Qt Version: 6.11.0
ADDITIONAL INFORMATION
Other protocol handlers I've tried, file:/// and sftp://, are unaffected.
Navigating to a different location in other ways, such as via the Places
sidebar, works.
I'm not sure if this is a bug in KDE Connect kio worker, or the KIO framework's
URL navigator widget. My first intuition was that entering a new path should
overwrite the current one no matter what, the widget shouldn't allow the
current KIO worker to hijack it. But maybe there's a hook specifically to give
the current KIO worker an opportunity to interpret the new path as a relative
path, and kdeconnect wrongly interprets any new path as a relative path?
Konqueror is unaffected, perhaps precisely because it doesn't use such a
mechanism, as interprets any new path as either as an absolute path that fully
replaces the current one, or as a web search term; also, it doesn't use the KIO
framework's URL widget.
I have kio-fuse installed. Another weird thing, perhaps related to this bug, is
that opening any file or folder on the remote device redirects to a path like
/run/user/500/aaa1ef6d_9397_40a3_970e_f153a9107344/storage/emulated/0/ even if
it's opened in a KDE application, while with other remote protocols that's only
done if they are opened in an application that doesn't support KIO.
--
You are receiving this mail because:
You are watching all bug changes.