| Summary: | Consider suppressing the portal confirmation dialog on connection | ||
|---|---|---|---|
| Product: | [Plasma] KRdp | Reporter: | Nate Graham <nate> |
| Component: | general | Assignee: | Unassigned bugs mailing-list <unassigned-bugs> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | ahiemstra, julien.dlq, ngompa13, voidpointertonull+bugskdeorg |
| Priority: | NOR | Keywords: | usability |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Linux | ||
| See Also: | https://bugs.kde.org/show_bug.cgi?id=488369 | ||
| Latest Commit: | Version Fixed In: | 6.1.0 | |
| Sentry Crash Report: | |||
|
Description
Nate Graham
2024-06-11 16:56:36 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/krdp/-/merge_requests/36 We have no control over the portal dialog, short of switching to a completely different API. The only thing we can do is to ensure we request permission early and hope the user checks "remember" (and there are no bugs with that setting). Note that we can't even control from within the server if that checkbox is ticked by default. The linked MR implements the above, which hopefully resolves most of this along with the fix to persistence of the "remember" option. We do have control over it ("we" meaning KDE). We could delete it completely and auto-accept incoming requests, for example.
Git commit 8cea6fb883bb387c4d1adadad3bfe79b387c1abc by Arjen Hiemstra. Committed on 12/06/2024 at 11:06. Pushed by ahiemstra into branch 'master'. server: Create a single temporary portal session on server startup We want to ask the user for permission when it's convenient, not when there's nobody at the machine to confirm the permissions. So create a portal session at startup to request the permisisons. Unfortunately we cannot reuse this portal session since it leads to reconnection issues with the PipeWire stream. While that is probably solvable it also causes additional problems, most notably that the "Remote Desktop" SNI will be constantly active. So instead, discard the session after it was successfully started and create a new session when a new connection is incoming. This assumes the user checked "remember" for the portal permission. Unfortunately there is not a whole lot we can do to force that. In general the permission model here is rather lacking. M +35 -17 server/SessionController.cpp M +10 -3 server/SessionController.h M +1 -2 server/main.cpp https://invent.kde.org/plasma/krdp/-/commit/8cea6fb883bb387c4d1adadad3bfe79b387c1abc A possibly relevant merge request was started @ https://invent.kde.org/plasma/krdp/-/merge_requests/37 Git commit 8d76d9a634d7072fdc1036bb2f2da45b5f8dd917 by Arjen Hiemstra. Committed on 13/06/2024 at 09:44. Pushed by ahiemstra into branch 'Plasma/6.1'. server: Create a single temporary portal session on server startup We want to ask the user for permission when it's convenient, not when there's nobody at the machine to confirm the permissions. So create a portal session at startup to request the permisisons. Unfortunately we cannot reuse this portal session since it leads to reconnection issues with the PipeWire stream. While that is probably solvable it also causes additional problems, most notably that the "Remote Desktop" SNI will be constantly active. So instead, discard the session after it was successfully started and create a new session when a new connection is incoming. This assumes the user checked "remember" for the portal permission. Unfortunately there is not a whole lot we can do to force that. In general the permission model here is rather lacking. (cherry picked from commit 8cea6fb883bb387c4d1adadad3bfe79b387c1abc) M +35 -17 server/SessionController.cpp M +10 -3 server/SessionController.h M +1 -2 server/main.cpp https://invent.kde.org/plasma/krdp/-/commit/8d76d9a634d7072fdc1036bb2f2da45b5f8dd917 As written, this bug report is fixed by that commit. We can refine the presentation later to not show any confirmation dialog at all, but at least the time when it's shown is immediate so it won't potentially block incoming unattended remote access requests. |