| Summary: | xdg-desktop-portal-kde file dialog ignores activity off-the-record setting | ||
|---|---|---|---|
| Product: | [Plasma] xdg-desktop-portal-kde | Reporter: | Thomas Baag <bugs.kde.org> |
| Component: | general | Assignee: | Plasma Bugs List <plasma-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | major | CC: | aleixpol, ctrlaltca, sitter |
| Priority: | NOR | ||
| Version First Reported In: | 6.4.3 | ||
| Target Milestone: | --- | ||
| Platform: | NixOS | ||
| OS: | Linux | ||
| Latest Commit: | https://invent.kde.org/frameworks/kio/-/commit/0ea7124ca44b629e98a1ca22abab376ae7907e11 | Version Fixed/Implemented In: | |
| Sentry Crash Report: | |||
|
Description
Thomas Baag
2025-07-28 16:21:49 UTC
As a workaround one can symlink the state file to /dev/null which works for me. ln -s /dev/null ~/.local/state/xdg-desktop-portal-kdestaterc I can confirm this problem. My xdg-desktop-portal-kdestaterc right now contains in "Recent URLs[$e]" 6 smb:// links to multiple samba servers. I'm using Firefox (with widget.use-xdg-desktop-portal.file-picker = 1) to save a file and the dialog takes up to 35 seconds to appear. If I can try to save the file a few times nothing appears on the screen, until suddenly all the dialogs appears at once after - i guess - the network timeout. Using dbus-vewer I can see the portal request coming from Firefox, then a lot of calls to the kwalletd/kpasswdserver dbus interfaces, requesting saved credentials for the samba servers. This is really annoying for a few reasons: * there's no visual confirmation something is happening during the wait, so it just seems broken * it's related to a feature (the "recent paths" dropdown) that's quite well hidden and - at least by me - unknown and never used before * there's no way to disable this behavior. I guess a good compromise could be to load the dialog early and populate the "recent" dropdown in an async fashion, or even only when the user actually presses the button requesting to use the feature. At least if it takes some seconds to load the user knows what they are waiting for. In the meanwhile, I can confirm Thomas' symlink workaround works. Activity tracking has nothing to do with the fileopendialog. Can one of you try to get a backtrace while it is stuck? Easiest would be to run killall -ABRT xdg-desktop-portal-kde and then grab the developer information from the crash dialog. Sorry but i can't, drkonqui is not supported on my non-systemd system. Trying to run xdg-desktop-portal-kde under gdb and stop/kill it while it's blocked lead to this backtrace:
---
Thread 1 "xdg-desktop-por" received signal SIGINT, Interrupt.
0x00007ffff35134c7 in access () from /lib64/libc.so.6
(gdb) bt full
#0 0x00007ffff35134c7 in access () at /lib64/libc.so.6
#1 0x00007ffff413e388 in ??? () at /usr/lib64/libQt6Core.so.6
#2 0x00007ffff3ee7792 in QFileInfo::exists(QString const&) () at /usr/lib64/libQt6Core.so.6
#3 0x00007ffff7b8bb53 in KUrlComboBox::setUrls(QList<QString> const&, KUrlComboBox::OverLoadResolving) () at /usr/lib64/libKF6KIOWidgets.so.6
#4 0x00007ffff7d03031 in ??? () at /usr/lib64/libKF6KIOFileWidgets.so.6
#5 0x00007ffff7d0b7c2 in KFileWidget::KFileWidget(QUrl const&, QWidget*) () at /usr/lib64/libKF6KIOFileWidgets.so.6
---
I also did the same running xdg-desktop-portal-kde under strace and this is it:
---
write(5, "\1\0\0\0\0\0\0\0", 8) = 8
access("/home/fabio/Pictures/", F_OK) = 0
access("/home/fabio/Documents/", F_OK) = 0
access("/run/user/1000/kio-fuse-cfSTBM/smb/192.168.249.241/archivio/chiuse/XX.2025.7603/", F_OK) = 0
>>>> FREEZE HERE
access("/run/user/1000/kio-fuse-cfSTBM/smb/192.168.249.241/archivio/chiuse/XX.2025.4930/", F_OK) = 0
access("/home/fabio/Desktop/", F_OK) = 0
access("/home/fabio/", F_OK) = 0
access("/home/fabio/Downloads/", F_OK) = 0
---
My ~/.local/state/xdg-desktop-portal-kdestaterc contains (reformatted for better readability):
---
[KFileDialog Settings]
Recent Files[$e]=file:$HOME/Downloads/KVIrc-5.2.8-Quasar-x86_64.exe
Recent URLs[$e]=
smb://192.168.249.241/archivio/chiuse/XX.2025.5263/,
smb://192.168.249.241/archivio/chiuse/XX.2025.4327/,
file:$HOME/Pictures/,
smb://192.168.249.241/archivio/XX.2025.2913/PP1328-2024/,
file:$HOME/Documents/,
smb://192.168.249.241/archivio/chiuse/XX.2025.7603/,
file:///run/user/1000/kio-fuse-cfSTBM/smb/192.168.249.241/archivio/chiuse/XX.2025.7603/,
file:///run/user/1000/kio-fuse-cfSTBM/smb/192.168.249.241/archivio/chiuse/XX.2025.4930/,
file:$HOME/Desktop/,
file:$HOME/,
file:$HOME/Downloads/
---
So it seems it's the file:// urls pointing to kio-fuse mounted directories causing the problem, at least for me.
smb:// urls gets skipped while checking for QFileInfo::exists(), i guess those kio-fuse urls should be skipped aswell
I'll have a look at kfiledialog
Kio-fuse uses the base path QStandardPaths::writableLocation(QStandardPaths::RuntimeLocation): https://invent.kde.org/system/kio-fuse/-/blob/master/src/kiofuseservice.cpp?ref_type=heads#L45 KUrlComboBox::setUrls() could skip file URLs starting with that base path in https://invent.kde.org/frameworks/kio/-/blob/master/src/widgets/kurlcombobox.cpp?ref_type=heads#L221 Can this be a sensible approach? Ah! fuse, now that explains things. Maybe we should just get rid of the check. You can never truly know if a given path will be available or fast or local - it's risky no matter what we do. A possibly relevant merge request was started @ https://invent.kde.org/frameworks/kio/-/merge_requests/1961 Git commit 0ea7124ca44b629e98a1ca22abab376ae7907e11 by Christoph Cullmann, on behalf of Fabio Bas. Committed on 19/08/2025 at 05:37. Pushed by cullmann into branch 'master'. KUrlComboBox::setUrls(): remove check for file existence M +0 -6 src/widgets/kurlcombobox.cpp https://invent.kde.org/frameworks/kio/-/commit/0ea7124ca44b629e98a1ca22abab376ae7907e11 |