Created attachment 176303 [details] Showcasing the issue using ASHPD SUMMARY When an app wants to use the portal, the window appears and a screenshot is taken. But, the portal window is always on the screenshot, as it ignores the delay specified. STEPS TO REPRODUCE 1. Open any application that uses the interactive screenshot portal 2. Select any area, at any delay 3. Take the screenshot 4. Select save OBSERVED RESULT Doesn't matter how fast alt-tab is done to take a screenshot of the intended window; it always shows the “Request Screenshot Window.” It's worse when the screenshot area is of the “Active window”, as it only takes a screenshot of itself. EXPECTED RESULT The portal shouldn't take a screenshot of itself, or at least, respect the delay to hide it and go to the intended window. SOFTWARE/OS VERSIONS Operating System: EndeavourOS KDE Plasma Version: 6.2.4 KDE Frameworks Version: 6.8.0 Qt Version: 6.8.0 Kernel Version: 6.12.1-zen1-1-zen (64-bit) Graphics Platform: Wayland Processors: 4 × Intel® Core™ i5-3210M CPU @ 2.50GHz Memory: 15.5 GiB of RAM Graphics Processor: Mesa Intel® HD Graphics 4000 ADDITIONAL INFORMATION It has always happened as I'm using KDE Wayland (since 6.0). An uninteractive screenshot works well, as it doesn't have a GUI, and the interactive and in Gnome work as intended. Also, as is seen in the video, sometimes when a capture is canceled, it is sent anyway.
Created attachment 176304 [details] Trying to using the portal in GIMP 3.0 RC1
Created attachment 176305 [details] Active window area result
Created attachment 176306 [details] Trying another screenshot in GIMP 3.0 RC1
Just confirming this is still an issue as of 6.4.0. Applications like GIMP still can't take screenshots via the portal.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/merge_requests/414
Git commit 9bfc61c7158e4dbec98e60c90548e187e8164c34 by David Redondo. Committed on 24/06/2025 at 12:43. Pushed by davidre into branch 'master'. Fix screenshot delay Timer expects the delay in milliseconds FIXED-IN:6.4.2 M +1 -1 src/ScreenshotDialog.qml https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/commit/9bfc61c7158e4dbec98e60c90548e187e8164c34
Git commit 9531d6a223d15348d641cdcb347be6a5f0fba7b2 by David Redondo. Committed on 24/06/2025 at 14:14. Pushed by davidre into branch 'Plasma/6.4'. Fix screenshot delay Timer expects the delay in milliseconds FIXED-IN:6.4.2 (cherry picked from commit 9bfc61c7158e4dbec98e60c90548e187e8164c34) Co-authored-by: David Redondo <kde@david-redondo.de> M +1 -1 src/ScreenshotDialog.qml https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/commit/9531d6a223d15348d641cdcb347be6a5f0fba7b2
(In reply to David Redondo from comment #6) > Git commit 9bfc61c7158e4dbec98e60c90548e187e8164c34 by David Redondo. > Committed on 24/06/2025 at 12:43. > Pushed by davidre into branch 'master'. > > Fix screenshot delay > > Timer expects the delay in milliseconds > FIXED-IN:6.4.2 > > M +1 -1 src/ScreenshotDialog.qml > > https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/commit/ > 9bfc61c7158e4dbec98e60c90548e187e8164c34 Thanks for the fix; to some extent, this is enough to make the portal usable. However, this also fixes the issue that makes the portal capture itself if there is no delay? Ideally, for better usability, it may also let us select the application you want to capture, like the screencast portal or the screenshot Gnome's portal.
In 6.1.2 only one part of the issue is fixed, and even if what was fixed was the most fundamental, having to manually hide the portal GUI every time someone needs to make a screenshot isn't a desirable UX. Though, maybe for organization questions, do you prefer to have a bug per report? If that's the case, would it be better to make another bug that includes that other part?
(In reply to playpsic04 from comment #9) > In 6.1.2 only one part of the issue is fixed, and even if what was fixed was > the most fundamental, having to manually hide the portal GUI every time > someone needs to make a screenshot isn't a desirable UX. > > Though, maybe for organization questions, do you prefer to have a bug per > report? If that's the case, would it be better to make another bug that > includes that other part? * The version is 6.4.2