Bug 504931 - "Allow restoring on future sessions" still asks for what to share next time
Summary: "Allow restoring on future sessions" still asks for what to share next time
Status: CONFIRMED
Alias: None
Product: xdg-desktop-portal-kde
Classification: Plasma
Component: general (other bugs)
Version First Reported In: 6.3.5
Platform: Arch Linux Linux
: NOR normal
Target Milestone: ---
Assignee: Plasma Bugs List
URL:
Keywords: usability
Depends on:
Blocks:
 
Reported: 2025-05-28 17:28 UTC by Arimil
Modified: 2025-06-03 16:23 UTC (History)
3 users (show)

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


Attachments
video sample of issue (1.76 MB, video/mp4)
2025-05-28 17:33 UTC, Arimil
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Arimil 2025-05-28 17:28:24 UTC
SUMMARY
When selecting a window with xdg-desktop-portal in OBS and checking the `Allow restoring on future sessions` checkbox then closing said application and reopening it. The capture does not correctly resume capture, instead your are left with the last frame before the program was closed the first time. Furthermore if when closing OBS and reopening it, you will be bombarded with xdg-desktop-portal selection windows for every pipewire capture you have, and no way to distinguish what source it is for.

STEPS TO REPRODUCE
1. In OBS add a pipewire capture source
2. Select a window to capture
3. Close and reopen the captured window
4. Close the application and OBS

OBSERVED RESULT
1. The capture will not resume
2. Capture does not restore on future sessions

EXPECTED RESULT
1. Capture automatically continues capturing window when it detects the same window
2. xdg-desktop-portal does not ask for what to share when `Allow restoring on future sessions` is checked

SOFTWARE/OS VERSIONS
Operating System: CachyOS Linux
KDE Plasma Version: 6.3.5
KDE Frameworks Version: 6.14.0
Qt Version: 6.9.0

ADDITIONAL INFORMATION
Possibly related to: https://bugs.kde.org/show_bug.cgi?id=488369
However I'm creating a new issue for this since in that issue the proposed solution is to rename the checkbox to something more accurate, however in my situation I'm looking for the functionality that is implied by the checkbox but missing.
Comment 1 Arimil 2025-05-28 17:33:14 UTC Comment hidden (spam)
Comment 2 Arimil 2025-05-28 18:10:25 UTC Comment hidden (spam)
Comment 3 David Redondo 2025-06-03 09:00:40 UTC
Restoring the capture while OBS is running is tricky.
However the following still works:

- capture kate
- close kate
- open kate
- as you noted the capture does not continue in OBS
- close OBS
- open OBS

the new kate window is correctly captured.
Comment 4 Arimil 2025-06-03 16:21:47 UTC
Correct, the other undesirable outcome is if you are to close OBS when Kate is not open, this triggers the portal to prompt for a window again, instead of just waiting for that window to be opened and capture it then.
Comment 5 Arimil 2025-06-03 16:23:03 UTC
(In reply to Arimil from comment #4)
> Correct, the other undesirable outcome is if you are to close OBS when Kate
> is not open, this triggers the portal to prompt for a window again, instead
> of just waiting for that window to be opened and capture it then.

Reopen OBS when Kate is closed but has an active capture that is.