Bug 419449 - Application Launcher ignores filenames of recent documents from hash sign on
Summary: Application Launcher ignores filenames of recent documents from hash sign on
Status: RESOLVED FIXED
Alias: None
Product: plasmashell
Classification: Plasma
Component: Application Menu (Kicker) widget (other bugs)
Version First Reported In: 5.15.5
Platform: Other Linux
: NOR normal
Target Milestone: 1.0
Assignee: Eike Hein
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-03-31 11:54 UTC by yoehoduv
Modified: 2025-06-05 19:46 UTC (History)
4 users (show)

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


Attachments
a wrong file name shows in history tab (69.16 KB, image/png)
2020-03-31 11:54 UTC, yoehoduv
Details

Note You need to log in before you can comment on or make changes to this bug.
Description yoehoduv 2020-03-31 11:54:27 UTC
Created attachment 127134 [details]
a wrong file name shows in history tab

SUMMARY

When the filename of a recent document includes a hash sign, the history
tab in Application Launcher shows a file whose name only has the part
preceding the hash sign.  And when I click on the entry from the history
tab, it tries to open a file whose name is the part preceding the hash
sign.

STEPS TO REPRODUCE

Create a file `~/foo#`.

    echo foo > ~/'foo#'

Double click on it in Dolphin to open it.

There should be a new file in `~/.local/share/RecentDocuments` and a new
entry in the History tab in Application Launcher.

    $ ls -al ~/.local/share/RecentDocuments/
    total 4
    drwx------. 1 user user   24 Mar 31 11:24 .
    drwxr-xr-x. 1 user user 1334 Mar 30 11:27 ..
    -rw-------. 1 user user  114 Mar 31 11:24 foo#.desktop

    $ cat ~/.local/share/RecentDocuments/foo'#'.desktop
    [Desktop Entry]
    Icon=text-plain
    Name=foo#
    Type=Link
    URL[$e]=file:$HOME/foo%23
    X-KDE-LastOpenedWith=org.kde.kwrite

Click on the new entry in Application Launcher.

OBSERVED RESULT

I get asked to choose a program to open foo.  I can choose kwrite, it
says "new file".  If I type in `echo` and check "Run in terminal" and
"Do not close when command exits", I get `/home/user/foo` echoed to my
terminal.

EXPECTED RESULT

I expect clicking the entry from Application Launcher to open the file
`foo#`.

SOFTWARE/OS VERSIONS

Operating System: Fedora 30
KDE Plasma Version: 5.15.5
KDE Frameworks Version: 5.64.0
Qt Version: 5.12.5
Comment 1 Alexander Lohnau 2020-07-17 19:40:37 UTC
Can confirm.

But it works when searching for "foo".

PS: We are using the activities data instead of the recent documents data. This is located in ~/.local/share/kactivitymanagerd/resources/database in the table ResourceEvent. If out search the targettedResource column for "foo" you will see that the filename is correctly stored.
Comment 2 Patrick Silva 2021-06-14 00:06:16 UTC
On Arch Linux running Plasma 5.22 I get this message:
"Unable to rum the command specified. The file or folder XXX does not exist."
Comment 3 Bug Janitor Service 2025-06-05 17:06:26 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/5570
Comment 4 cwo 2025-06-05 18:19:41 UTC
Git commit c6c0a68416b5042032853a6f673bddbe475567b7 by Christoph Wolk.
Committed on 05/06/2025 at 17:45.
Pushed by cwo into branch 'master'.

applets/kicker: fix filenames containing # in history

Kicker takes the resource name as provided by PlasmaActivities.Stats and
interprets it as an URL, setting the 'file' url scheme if necessary.
This fails when the filenames contain a '#' character, as QUrl will
interpret them as url fragments if not percent-encoded (which they are
not for local files, but are for remote urls). This makes display and
opening of such files fail in both Kicker and Kickoff.

Instead, we test whether it's an absolute path (the local history
entries are) and if so, use QUrl.fromLocalFile to get the correct url.
This is also what PlasmaActivities.Stats does in ResultSet (which is
what the Task Manager uses, so everything works there already, but we
want a real model here).
Related: bug 437960
FIXED-IN: 6.4.0

M  +5    -3    applets/kicker/recentusagemodel.cpp

https://invent.kde.org/plasma/plasma-workspace/-/commit/c6c0a68416b5042032853a6f673bddbe475567b7
Comment 5 cwo 2025-06-05 19:46:40 UTC
Git commit ab55c53e37814da5aadf9bf29dd5cae7a783ef6e by Christoph Wolk.
Committed on 05/06/2025 at 18:33.
Pushed by cwo into branch 'Plasma/6.4'.

applets/kicker: fix filenames containing # in history

Kicker takes the resource name as provided by PlasmaActivities.Stats and
interprets it as an URL, setting the 'file' url scheme if necessary.
This fails when the filenames contain a '#' character, as QUrl will
interpret them as url fragments if not percent-encoded (which they are
not for local files, but are for remote urls). This makes display and
opening of such files fail in both Kicker and Kickoff.

Instead, we test whether it's an absolute path (the local history
entries are) and if so, use QUrl.fromLocalFile to get the correct url.
This is also what PlasmaActivities.Stats does in ResultSet (which is
what the Task Manager uses, so everything works there already, but we
want a real model here).
Related: bug 437960
FIXED-IN: 6.4.0


(cherry picked from commit c6c0a68416b5042032853a6f673bddbe475567b7)

Co-authored-by: Christoph Wolk <cwo.kde@posteo.net>

M  +5    -3    applets/kicker/recentusagemodel.cpp

https://invent.kde.org/plasma/plasma-workspace/-/commit/ab55c53e37814da5aadf9bf29dd5cae7a783ef6e