SUMMARY When opening a file though the document portal in a Flatpak app like OBS, the opened files are not remembered after a restart of the document portal daemon. STEPS TO REPRODUCE 1. Open an application that uses xdg portals 2. Open one or more files 3. Close the application 4. Terminate the document portal process or restart the system 5. Open the same app again and get either an error (in case of qpwgraph, restore prompt (in case of OBS), or potentially other behavior OBSERVED RESULT The opened files are not persisted and need to be reopened. EXPECTED RESULT Previously opened files are persisted for applications. SOFTWARE/OS VERSIONS Linux: 6.6.1 KDE Plasma Version: 5.27.9 KDE Frameworks Version: 5.111.0 Qt Version: 5.15.11 ADDITIONAL INFORMATION According to this comment on GitHub the gnome portal implements such behavior, or will do so in a future release. https://github.com/flatpak/xdg-desktop-portal/issues/1075#issuecomment-1733728808
I'm not sure what "The opened files are not persisted and need to be reopened." means, sorry. Do you mean the dialog doesn't remember the last location you has browsed to the next time it opens? Or something else?
Here's an example to hopefully better illustrate the issue: I have an OBS setup with multiple scenes that have images loaded for various things like background, etc. When I import those images into OBS it goes through the document portal and returns the path to the /run location. Doing this initially works just fine, everything gets loaded, and even after restarting OBS the files are being opened up again as expected. If I now restart my machine and open up OBS again it will prompt me that it cannot find some files. At that point I have to select the directory where I store my streaming related resources. After that it will remember the files until I do another system reboot.
I'm not completely sure anymore if this is entirely the fault of the KDE backend implementation like Georges hinted at in the GH comment. Since updating to xdg-desktop-portal 1.18.1 the problem has become less reliable to reproduce. With version 1.18.0 I was able to reproduce this issue 100% of the time simply be rebooting, or restarting the document portal process. Now it doesn't remember opened files sometimes, but most of the times it works just fine. Maybe it has something to do with applications not shutting down properly, or because the files are stored at an automounted location and there's some kind of race condition going on.
Aha. Yeah this isn't a KDE issue, it's kind of an issue with how Flatpak and portals work in the first place. When you select a file, the app gets a temporary license to open that file. Once it does, the access is revoked. This breaks use cases where you want an application to automatically open files on launch, as you're doing. I think this requires discussion upstream for some kind of session restore support whereby apps can register their current state and get the ability to restore it on launch. We could implement what the GNOME portal does, but it's a hack, as there's no guarantee that the last-used folder is the folder where the files needed by the app are actually located. Maybe until upstream support for some kind of sesison restore materializes, we could give the app permanent access to *all* files that the user has deliberately opened via the portalized open dialog
(In reply to Patrick Auernig from comment #2) > Here's an example to hopefully better illustrate the issue: > > I have an OBS setup with multiple scenes that have images loaded for various > things like background, etc. > When I import those images into OBS it goes through the document portal and > returns the path to the /run location. Where do you have OBS from? The flathub version already has access to everything on your system and doesn't get /run urls https://github.com/obsproject/obs-studio/blob/34ef67e212f24a085a63705a0ab81e3401c8eca4/build-aux/com.obsproject.Studio.json#L15
It's a broader issue than just OBS though, as not all apps will have blanket access to files, and indeed it's not recommended that they do.
Can you reproduce the issue cause I cannot Right now the following things make no sense to me: - OBS has blanket access - the steps to reproduce don't produce the observed result (even when I take away the blanket access) - the document portal gives **persistent** access (see flatpak permissions documents) so the observed result makes no sense from a downstream POV unless of course an upstream bug is in play to begin with - what Georges was talking about is remembering locations in the file open dialog. we don't do that on a library level anywhere from what I can tell, doing so for flatpaks would be inconsistent with the rest of the workspace
(In reply to Harald Sitter from comment #5) > (In reply to Patrick Auernig from comment #2) > > Here's an example to hopefully better illustrate the issue: > > > > I have an OBS setup with multiple scenes that have images loaded for various > > things like background, etc. > > When I import those images into OBS it goes through the document portal and > > returns the path to the /run location. > > Where do you have OBS from? The flathub version already has access to > everything on your system and doesn't get /run urls > https://github.com/obsproject/obs-studio/blob/ > 34ef67e212f24a085a63705a0ab81e3401c8eca4/build-aux/com.obsproject.Studio. > json#L15 It's the official package from Flathub, but I generally deny applications unconditional access to all system files. I added the path where my resource files are stored explicitly as read-only. I vaguely remember trying the default Flatpak settings just to see if it changes anything, but it didn't really work. Probably because OBS is using the portal interface to get the file and not accessing it directly via the path.
Qpwgraph has the same issue occasionally where it just "forgets" the last opened patchbay. And that application is using default setting without any overrides.
Gets persistent access for me. ❯ flatpak permissions documents |grep org.rncbc.qpwgraph documents 1811ad34 org.rncbc.qpwgraph read,write,grant-permissions (b'/home/me/bingo.qpwgraph', 41, 258, 0)
I can also confirm that this works for me with default settings. Can you share the Flatpak permission settings you're using when the problem happens to you?
Patrick, are you able to reproduce the issue with an app from Flathub whose permissions you haven't changed at all? Can you try that for testing purposes?
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!
Sorry for the late reply, things happened and I kinda forgot about this bug report. For anyone that might stumble upon this: The location that the document portal randomly "forgot" about was mounted with a systemd-automount option. It seems like Flatpak and sd-automount don't go along very well, as there appears to be some race condition, or some other issue that causes it to not detect the file on first try.