Bug 386385 - Ctrl-q on client app doesn't close open portal dialogs
Summary: Ctrl-q on client app doesn't close open portal dialogs
Alias: None
Product: xdg-desktop-portal-kde
Classification: Plasma
Component: general (show other bugs)
Version: unspecified
Platform: Other Linux
: NOR minor
Target Milestone: ---
Assignee: Harald Sitter
Depends on:
Reported: 2017-10-31 13:07 UTC by Harald Sitter
Modified: 2022-04-22 15:13 UTC (History)
3 users (show)

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


Note You need to log in before you can comment on or make changes to this bug.
Description Harald Sitter 2017-10-31 13:07:35 UTC
- start a portal'd kate
- ctrl-o
- then ctrl-q the kate (leave the dialog open)

result: dialog stays open even though the kate instances that started it is now gone

expected: dialog disappears when kate gets closed

possible solution: since a client requesting a portal method must have some dbus address, the portal can listen for the address getting unregistered on the bus at which point the portal should also discard all pending dialogs to do with the client
Comment 1 David Greengas 2020-11-24 15:33:55 UTC
I am not able to reproduce this. I followed the exact steps outlined in your report.

Please confirm if this is still an issue and include version details.

Operating System: Manjaro Linux
KDE Plasma Version: 5.20.3
KDE Frameworks Version: 5.77.0
Qt Version: 5.15.1
Kernel Version: 5.9.10-1-MANJARO
OS Type: 64-bit
Processors: 4 × Intel® Core™ i5-6200U CPU @ 2.30GHz
Memory: 7.7 GiB of RAM
Graphics Processor: Mesa Intel® HD Graphics 520
Comment 2 Harald Sitter 2020-11-25 10:21:54 UTC
The GUI is now blocked it seems.

When you start it from a terminal and ctrl-c the lead process the dialog will still remain open though, i.e. the actual problem that the portal doesn't react to the client disappearing is still there.
Comment 3 Harald Sitter 2022-04-22 15:09:57 UTC
Git commit b32240b9e898fbf2ec1201e3628c8357c4af6676 by Harald Sitter.
Committed on 22/04/2022 at 09:37.
Pushed by ngraham into branch 'master'.

add Request closing support to all rejectable dialogs

this ensures that the dialog goes away when the app disappears while the
dialog is still up (e.g. when ctrl-c'ing the app)

this simply refactors the existing Request code to correctly register on
the path and then emit the closerequest that gets routed to the ::reject
function of the dialog. for extra flexibility this is implemented as a
template such that the concrete type doesn't matter so long as it has a
reject slot.

M  +3    -0    src/access.cpp
M  +3    -0    src/appchooser.cpp
M  +2    -0    src/dynamiclauncher.cpp
M  +4    -0    src/filechooser.cpp
M  +1    -11   src/inhibit.cpp
M  +3    -0    src/print.cpp
M  +3    -0    src/remotedesktop.cpp
M  +14   -1    src/request.cpp
M  +12   -1    src/request.h
M  +3    -0    src/screencast.cpp
M  +3    -0    src/screenshot.cpp