Reproducing on Kubuntu 26.04 with `slack` snap (4.49.89) and `snapd`
2.75.2. The prompt fires on every Slack launch and clicking "Yes" does
not suppress future prompts.
Caveat: this investigation was carried out with LLM assistance. I am
happy to re-run any check, gather further evidence, or test patches on
this machine for anyone working on resolving the issue — please tag me
on the bug.
After investigation I believe the underlying cause is that
`io.snapcraft.Settings.SetSub` in snap-userd has no skip-on-match logic
and prompts unconditionally, regardless of whether the requested value
is already the current value. Detailed evidence below in case it helps
anyone working on a fix.
## Environment
- Kubuntu 26.04, KDE Plasma 6, Wayland session
- `snap`/`snapd` 2.75.2
- `xdg-desktop-portal` 1.21.1, `xdg-desktop-portal-kde` 6.6.4 (also `-gtk`
1.15.3 installed)
- Slack snap 4.49.89, revision 244
- snap interfaces `desktop`, `desktop-legacy`, `gsettings`, `unity7`,
`wayland`, `x11` all connected as expected.
## What the user sees
KDialog popup at every Slack launch:
> Allow settings change?
> Allow snap "slack" to change "default-url-scheme-handler" subproperty "slack"
> to "slack_slack.desktop"?
Clicking "Yes" lets Slack continue. Next launch the prompt returns.
## Pre-existing state on disk
The xdg-settings system already has Slack registered as the handler
before the prompt fires:
```
$ xdg-settings get default-url-scheme-handler slack
slack_slack.desktop
$ grep "x-scheme-handler/slack" ~/.config/mimeapps.list
x-scheme-handler/slack=slack_slack.desktop
$ find / -name slack_slack.desktop 2>/dev/null
/var/lib/snapd/desktop/applications/slack_slack.desktop
/home/<user>/.config/autostart/slack_slack.desktop
```
So the value Slack is asking userd to set is already the current value.
## Replaying the check in userd's exact environment
`snap userd` runs in the user systemd session. Pulling its env from
`/proc/<pid>/environ`:
```
HOME=/home/<user>
XDG_DATA_DIRS=/home/<user>/.local/share/flatpak/exports/share:/var/lib/flatpak/exports/share:/usr/local/share:/usr/share:/var/lib/snapd/desktop
PATH=...usual user PATH...
```
Replaying with that exact env:
```
$ env -i HOME=$USERD_HOME XDG_DATA_DIRS=$USERD_DATA PATH=/usr/bin:/bin \
xdg-settings get default-url-scheme-handler slack
slack_slack.desktop
$ env -i HOME=$USERD_HOME XDG_DATA_DIRS=$USERD_DATA PATH=/usr/bin:/bin \
xdg-settings check default-url-scheme-handler slack slack_slack.desktop
yes
```
So if userd was running `xdg-settings check` (or get + compare) before
prompting, the comparison should report a match and the prompt should be
skipped. It is not skipped.
## DBus trace of an actual launch
`dbus-monitor --session "interface=io.snapcraft.Settings"` while
quitting and relaunching Slack produces exactly one method call, with no
preceding `CheckSub`/`GetSub`:
```
method call sender=:1.156 -> destination=io.snapcraft.Settings
serial=2 path=/io/snapcraft/Settings
interface=io.snapcraft.Settings; member=SetSub
string "default-url-scheme-handler"
string "slack"
string "slack.desktop"
```
Slack passes the bare app id (`slack.desktop`); userd composes
`<snap>_<value>` to derive `slack_slack.desktop` for the prompt text.
So:
1. Slack calls SetSub on every launch unconditionally — it does not check first.
2. userd in 2.75.2 receives SetSub and goes straight to the confirmation prompt
without checking the current value.
## snapd binary inspection
The format string for the prompt is present in
`/snap/snapd/current/usr/bin/snap`:
```
Allow snap %q to change %s to %q ?
```
I was not able to find any `check-subproperty`, `xdg-settings check`,
"already set", or skip-on-match strings in the userd binary, which is
consistent with the prompt firing unconditionally on `SetSub`.
## Workarounds that do *not* work
- Pre-setting the handler with `xdg-settings set default-url-scheme-handler
slack slack_slack.desktop` — already set, no effect on the prompt.
- Copying `slack_slack.desktop` into `~/.local/share/applications/` and running
`update-desktop-database` so it is findable via standard `XDG_DATA_DIRS` — does
not stop the prompt.
- Both the user's interactive shell and the replayed userd env already report
`xdg-settings check ... → yes` before the prompt fires.
## Suggested investigation direction
If `usersession/userd/settings.go` `SetSub` is supposed to short-circuit
when the current value already equals the requested value, that path
appears to be missing or not reached in 2.75.2. A `Check`/`CheckSub`
early-return in `SetSub` (mirroring the behaviour of `xdg-settings
check-subproperty`) would silently fix the very common "already correct"
case that affects this and the duplicate reports against teams-for-
linux, ytmdesktop, bitpay, figma-linux, and Obsidian on multiple desktop
environments.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1966067
Title:
Snap application always asks for settings change on startup
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1966067/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
