jira-projects/MISC#29: Firefox snap won't work with KeepassXC when not launched from a terminal

I gave some detail from my previous testing here.

• the application icon in my K-menu runs /snap/bin/firefox %u and KeepassXC doesn’t work.
• running snap run firefox in a terminal, KeepassXC works
• Editing the K-Menu item to instead run snap run firefox doesn't resolve it
• Editing the K-Menu item and ticking run in terminal however does

Checking environment:

• I launched the "broken" mechanism, went to about:support and then saved the resulting page.
• I launched the working mechanism, went to about:support and then saved the resulting page.

diff reports no difference between them

OK, this gets weirder.

I did the following

Launch firefox using the working mechanism, verified it was working. Preserved a copy of the desktop file

cp /home/ben/.local/share/applications/firefox_firefox.desktop firefox_firefox_working.desktop

Edited the K-Menu item to disable run in terminal Ran from the K-Menu and verified that it's not working Preserved a copy of the desktop file

cp /home/ben/.local/share/applications/firefox_firefox.desktop firefox_firefox_notworking.desktop

But.... if I go into Dolphin and double-click firefox_firefox_notworking.desktop Firefox launches with KeepassXC communication working.

It's seems like this issue is specific to stuff launched from the K-Menu

For posterity, a diff of the two .desktop files

--- firefox_firefox_notworking.desktop  2022-09-13 17:50:45.382727352 +0100
+++ firefox_firefox_working.desktop 2022-09-13 17:48:56.109912459 +0100
@@ -217,7 +217,7 @@
 Name[zh_TW]=Firefox 網路瀏覽器
 Path=
 StartupNotify=true
-Terminal=false
+Terminal=true
 TerminalOptions=
 Type=Application
 Version=1.0

Going to try and capture some logs during the "broken" state.

Have updated the command in the K-Menu

$ grep Exec /home/ben/.local/share/applications/firefox_firefox.desktop
Exec=env BAMF_DESKTOP_FILE_HINT=/var/lib/snapd/desktop/applications/firefox_firefox.desktop /snap/bin/firefox -private-window
Exec=env BAMF_DESKTOP_FILE_HINT=/var/lib/snapd/desktop/applications/firefox_firefox.desktop /snap/bin/firefox -new-window
Exec=env MOZ_LOG=NativeMessagingPortal:5 MOZ_LOG_FILE=/tmp/ff_log.log /usr/bin/snap run firefox %u

There's a log per worker by the looks of it

root@bumblebee:/home/ben/tmp/firefox_snap_stuff# ls /tmp/snap.firefox/tmp/
ff_log.log.child-1.moz_log                 ff_log.log.child-4.moz_log                 ff_log.log.moz_log                         .X11-unix/
ff_log.log.child-2.moz_log                 ff_log.log.child-5.moz_log                 .snap/                                     
ff_log.log.child-3.moz_log                 ff_log.log.child-6.moz_log                 Temp-44591179-1cc6-432d-86bd-42ae25829923/ 

They're all empty though - I've screwed up somewhere clearly.

I've tried a few different invocations and it just won't log anything.

What I have noticed, though, is that working/broken seems to change depending on how you construct the command.

This gives the broken behaviour

env MOZ_LOG=NativeMessagingPortal:5 MOZ_LOG_FILE=/tmp/ff_log.log /usr/bin/snap run firefox %u

This gives the working behaviour

MOZ_LOG=NativeMessagingPortal:5 MOZ_LOG_FILE=/tmp/ff_log.log /usr/bin/snap run firefox %u

I'm guessing the K-Menu is deciding the second is a shell command, whereas the other gets fired some other way?

Could it be launch feedback?

Disabling that

ben@bumblebee:~/tmp/firefox_snap_stuff$ diff -u firefox_firefox_notworking.desktop firefox_firefox_lf.desktop 
--- firefox_firefox_notworking.desktop  2022-09-13 17:50:45.382727352 +0100
+++ firefox_firefox_lf.desktop  2022-09-13 18:15:43.449765350 +0100
@@ -216,13 +216,13 @@
 Name[zh_CN]=Firefox 网络浏览器
 Name[zh_TW]=Firefox 網路瀏覽器
 Path=
-StartupNotify=true
+StartupNotify=false
 Terminal=false
 TerminalOptions=
 Type=Application
 Version=1.0
 X-DBUS-ServiceName=
-X-DBUS-StartupType=none
+X-DBUS-StartupType=
 X-KDE-SubstituteUID=false
 X-KDE-Username=
 X-SnapInstanceName=firefox

It fucking works!

There must be something D-Bus'y getting in the way.

I've tried the various different options for X-DBUS-StartupType= and it doesn't work with any of them

The other question that needs answering though, is why isn't my other system affected? I've just checked and it's got Launch Feedback enabled...

Working

ben@optimus:/tmp$ snap list firefox
Name     Version    Rev   Tracking     Publisher  Notes
firefox  105.0b5-1  1780  latest/beta  mozilla✓   -

Not Working

ben@bumblebee:~$ snap list firefox
Name     Version    Rev   Tracking     Publisher  Notes
firefox  105.0b9-1  1826  latest/beta  mozilla✓   -

So, we are looking at different versions - I'll update Optimus and see if it breaks

We've ended up on a slightly newer version

ben@optimus:/tmp$ snap list firefox
Name     Version    Rev   Tracking     Publisher  Notes
firefox  105.0b9-1  1836  latest/beta  mozilla✓   -

Issue doesn't occur.

Bringing bumblebee up to date

ben@bumblebee:~$ snap list firefox
Name     Version    Rev   Tracking     Publisher  Notes
firefox  105.0b9-1  1836  latest/beta  mozilla✓   -

The issue is still present.

Version of Keepassxc is consistent between systems

ben@bumblebee:~$ dpkg-query -l | grep keepass
ii  keepassxc                                     2.6.6+dfsg.1-1                              amd64        Cross Platform Password Manager

As is xdg-desktop-portal

ben@optimus:~/Downloads$ dpkg-query -l | grep xdg-des
ii  xdg-desktop-portal                            1.14.4-1ubuntu2~22.04.1                     amd64        desktop integration portal for Flatpak and Snap
ii  xdg-desktop-portal-gtk                        1.14.0-1build1                              amd64        GTK+/GNOME portal backend for xdg-desktop-portal
ii  xdg-desktop-portal-kde                        5.24.4-0ubuntu1                             amd64        backend implementation for xdg-desktop-portal using Qt

KDE's the same version etc etc.

Ah-ha.

When running Firefox using the broken mechanism, the following gets written to the journal

Sep 13 20:17:57 bumblebee xdg-desktop-por[754118]: g_app_info_get_id: assertion 'G_IS_APP_INFO (appinfo)' failed
Sep 13 20:17:57 bumblebee xdg-desktop-por[754118]: g_strsplit: assertion 'string != NULL' failed
Sep 13 20:17:58 bumblebee systemd[1325]: xdg-desktop-portal.service: Main process exited, code=killed, status=11/SEGV
Sep 13 20:17:58 bumblebee systemd[1325]: xdg-desktop-portal.service: Failed with result 'signal'.

So, the reason Keepassxc can't be communicated with is xdg-desktop-portal is throwing an assert and failing.

Grabbing the code from https://github.com/flatpak/xdg-desktop-portal.git, whilst I see the function call it doesn't tell us too much.

The function throwing the assert is part of Glib rather than xdg-desktop-portal: #g-app-info-get-id, but it's got issues with the object that xdg-desktop-portal is passing into it.

Running xdg-desktop-portal in a terminal so I can collect output

/usr/libexec/xdg-desktop-portal -v 2>&1 | tee xdg.log

File:

xdg.log

The line

XDP: No permissions stored for: webextensions org.keepassxc.keepassxc_browser, app 

is interesting.

Running again, but with the "fix" in place in the K-Menu item (run in terminal)

xdg-working.log

No complaints about permissions in that one

Runnning a diff of the files we find there's another difference further up

ben@optimus:~/tmp/xdg-desktop-portal$ diff -u xdg.log xdg-working.log 
--- xdg.log 2022-09-13 20:31:58.076901113 +0100
+++ xdg-working.log 2022-09-13 20:31:58.076901113 +0100
@@ -71,11 +71,6 @@
 XDP: Using kde.portal for org.freedesktop.impl.portal.RemoteDesktop in KDE
 XDP: providing portal org.freedesktop.portal.RemoteDesktop
 XDP: org.freedesktop.portal.Desktop acquired
-XDP: Assigning app ID "" to pid 756333 which has unit "app-firefox_firefox-5dcff4c2195f41a88a704e57462cf14c.scope"
+XDP: Running: snap routine portal-info 758029
 XDP: Read org.freedesktop.appearance color-scheme
-XDP: webextensions session owned by ':1.1798' created
-XDP: No permissions stored for: webextensions org.keepassxc.keepassxc_browser, app 
-
-(/usr/libexec/xdg-desktop-portal:756316): GLib-GIO-CRITICAL **: 20:27:04.443: g_app_info_get_id: assertion 'G_IS_APP_INFO (appinfo)' failed
-
-(/usr/libexec/xdg-desktop-portal:756316): GLib-CRITICAL **: 20:27:04.443: g_strsplit: assertion 'string != NULL' failed
+XDP: webextensions session owned by ':1.1830' created

Waking up for the day, so figured I'd have a quick poke through the sources whilst my coffee sinks in.

It looks like the assert

-(/usr/libexec/xdg-desktop-portal:756316): GLib-GIO-CRITICAL **: 20:27:04.443: g_app_info_get_id: assertion 'G_IS_APP_INFO (appinfo)' failed

Happens here

  g_return_val_if_fail (G_IS_APP_INFO (appinfo), NULL);

The function doesn't do anything too special - if the first argument evaluates false then the second argument is returned.

The subsequent assert will be because desktop_id is null. xdg-desktop-portal ultimately segfaults.

I don't think we need/want to chase that down though. Really we need to figure out why what we're passing in isn't of type GAppInfo.

The difference in startup's might point us in the right direction

In particular, that early change in process:

-XDP: Assigning app ID "" to pid 756333 which has unit "app-firefox_firefox-5dcff4c2195f41a88a704e57462cf14c.scope"
+XDP: Running: snap routine portal-info 758029

The failed one seems to rely on a unit, whereas the working one invokes a routine.

One of the things I wondered about overnight - is it that the broken one is somehow invoked on my user's behalf, rather than as my user?

Running

find / -name 'app-firefox_firefox-5dcff4c2195f41a88a704e57462cf14c.scope'

Didn't yield anything.

However, it's because I've stopped and started Firefox since then (although still in the broken state). The hash at the end has changed (a run id maybe?)

root@bumblebee:/home/ben# find / -name 'app-firefox_firefox*'
/run/user/1000/systemd/transient/app-firefox_firefox-cd90a099af6244c794f4bf5fa7a0be0a.scope
/sys/fs/cgroup/user.slice/user-1000.slice/user@1000.service/app.slice/app-firefox_firefox-cd90a099af6244c794f4bf5fa7a0be0a.scope

Value:

root@bumblebee:/home/ben# cat /run/user/1000/systemd/transient/app-firefox_firefox-cd90a099af6244c794f4bf5fa7a0be0a.scope
# This is a transient unit file, created programmatically via the systemd API. Do not edit.
[Scope]
Slice=app.slice

[Unit]
Description=Firefox Web Browser - Web Browser
SourcePath=/home/ben/.local/share/applications/firefox_firefox.desktop

The second one is a directory

root@bumblebee:/home/ben# ls -l /sys/fs/cgroup/user.slice/user-1000.slice/user@1000.service/app.slice/app-firefox_firefox-cd90a099af6244c794f4bf5fa7a0be0a.scope
total 0
-r--r--r-- 1 ben ben 0 Sep 13 20:30 cgroup.controllers
-r--r--r-- 1 ben ben 0 Sep 13 20:30 cgroup.events
-rw-r--r-- 1 ben ben 0 Sep 13 20:30 cgroup.freeze
--w------- 1 ben ben 0 Sep 13 20:30 cgroup.kill
-rw-r--r-- 1 ben ben 0 Sep 13 20:30 cgroup.max.depth
-rw-r--r-- 1 ben ben 0 Sep 13 20:30 cgroup.max.descendants
-rw-r--r-- 1 ben ben 0 Sep 13 20:30 cgroup.procs
-r--r--r-- 1 ben ben 0 Sep 13 20:30 cgroup.stat
-rw-r--r-- 1 ben ben 0 Sep 13 20:30 cgroup.subtree_control
-rw-r--r-- 1 ben ben 0 Sep 13 20:30 cgroup.threads
-rw-r--r-- 1 ben ben 0 Sep 13 20:30 cgroup.type
-rw-r--r-- 1 ben ben 0 Sep 13 20:30 cpu.pressure
-r--r--r-- 1 ben ben 0 Sep 13 20:30 cpu.stat
-rw-r--r-- 1 ben ben 0 Sep 13 20:30 io.pressure
-r--r--r-- 1 ben ben 0 Sep 13 20:30 memory.current
-r--r--r-- 1 ben ben 0 Sep 13 20:30 memory.events
-r--r--r-- 1 ben ben 0 Sep 13 20:30 memory.events.local
-rw-r--r-- 1 ben ben 0 Sep 13 20:30 memory.high
-rw-r--r-- 1 ben ben 0 Sep 13 20:30 memory.low
-rw-r--r-- 1 ben ben 0 Sep 13 20:30 memory.max
-rw-r--r-- 1 ben ben 0 Sep 13 20:30 memory.min
-r--r--r-- 1 ben ben 0 Sep 13 20:30 memory.numa_stat
-rw-r--r-- 1 ben ben 0 Sep 13 20:30 memory.oom.group
-rw-r--r-- 1 ben ben 0 Sep 13 20:30 memory.pressure
-r--r--r-- 1 ben ben 0 Sep 13 20:30 memory.stat
-r--r--r-- 1 ben ben 0 Sep 13 20:30 memory.swap.current
-r--r--r-- 1 ben ben 0 Sep 13 20:30 memory.swap.events
-rw-r--r-- 1 ben ben 0 Sep 13 20:30 memory.swap.high
-rw-r--r-- 1 ben ben 0 Sep 13 20:30 memory.swap.max
-r--r--r-- 1 ben ben 0 Sep 13 20:30 pids.current
-r--r--r-- 1 ben ben 0 Sep 13 20:30 pids.events
-rw-r--r-- 1 ben ben 0 Sep 13 20:30 pids.max

So, under the hood, the broken version is in a SystemD scope (within the app slice). Of course, it's possible (likely, even) that the working version is too (presumably snap relies on this).

Annoyingly, systemctl seems to lack an option to list scopes (or slices for that matter), but we can check which scopes are running in that slice with

ls -ld /sys/fs/cgroup/user.slice/user-1000.slice/user@1000.service/app.slice/*.scope

There are a few

root@bumblebee:/home/ben# ls -ld /sys/fs/cgroup/user.slice/user-1000.slice/user@1000.service/app.slice/*scope
drwxr-xr-x 2 ben ben 0 Aug 31 14:47  /sys/fs/cgroup/user.slice/user-1000.slice/user@1000.service/app.slice/app-com.nextcloud.desktopclient.nextcloud-afaa190204484421a72dbbef763c2364.scope
drwxr-xr-x 2 ben ben 0 Sep 13 20:30  /sys/fs/cgroup/user.slice/user-1000.slice/user@1000.service/app.slice/app-firefox_firefox-cd90a099af6244c794f4bf5fa7a0be0a.scope
drwxr-xr-x 2 ben ben 0 Sep 13 17:49  /sys/fs/cgroup/user.slice/user-1000.slice/user@1000.service/app.slice/app-org.kde.dolphin-f36fd995a8154ef0916d9a2cf71c08b1.scope
drwxr-xr-x 2 ben ben 0 Aug 30 12:39  /sys/fs/cgroup/user.slice/user-1000.slice/user@1000.service/app.slice/app-org.kde.kate-bad2af2e4987421f979fc3b8025cf369.scope
drwxr-xr-x 2 ben ben 0 Aug 30 12:39  /sys/fs/cgroup/user.slice/user-1000.slice/user@1000.service/app.slice/app-org.kde.kcalc-568ed928b35040d3a9379b375abfe9a4.scope
drwxr-xr-x 2 ben ben 0 Aug 30 12:39  /sys/fs/cgroup/user.slice/user-1000.slice/user@1000.service/app.slice/app-org.kde.kcalc-9a8de155cb5a4dc7a399088e956dd312.scope
drwxr-xr-x 2 ben ben 0 Aug 31 13:00  /sys/fs/cgroup/user.slice/user-1000.slice/user@1000.service/app.slice/app-org.keepassxc.KeePassXC-4b633c76fbdb4f3ea8d218dc26bfc697.scope
drwxr-xr-x 2 ben ben 0 Sep 12 09:54 '/sys/fs/cgroup/user.slice/user-1000.slice/user@1000.service/app.slice/app-realvnc\x2dvncviewer-bba92aef7909427cb7ae627299b8c888.scope'
drwxr-xr-x 2 ben ben 0 Sep 12 10:30 '/sys/fs/cgroup/user.slice/user-1000.slice/user@1000.service/app.slice/app-signal\x2ddesktop_signal\x2ddesktop-f0234c497750493882d5308509dcaccd.scope'
drwxr-xr-x 2 ben ben 0 Aug 30 14:57  /sys/fs/cgroup/user.slice/user-1000.slice/user@1000.service/app.slice/app-slack_slack-553ede310e4c4b82b7548681a9bfad98.scope
drwxr-xr-x 2 ben ben 0 Aug 30 12:39  /sys/fs/cgroup/user.slice/user-1000.slice/user@1000.service/app.slice/app-terminator-03fda50527da488e85f25945ed6b5f8f.scope
drwxr-xr-x 2 ben ben 0 Sep 13 17:38  /sys/fs/cgroup/user.slice/user-1000.slice/user@1000.service/app.slice/snap.chromium.chromium.9162a931-165c-4db5-9cd6-d4c48e1dc35f.scope
drwxr-xr-x 2 ben ben 0 Sep 13 20:30  /sys/fs/cgroup/user.slice/user-1000.slice/user@1000.service/app.slice/snap.firefox.firefox.ff6e76ee-fb44-4d46-93b8-d209fafaf553.scope
drwxr-xr-x 2 ben ben 0 Sep 13 13:42  /sys/fs/cgroup/user.slice/user-1000.slice/user@1000.service/app.slice/vte-spawn-00088dd6-4faa-46a5-a623-82f60a476fb7.scope
drwxr-xr-x 2 ben ben 0 Sep 13 10:19  /sys/fs/cgroup/user.slice/user-1000.slice/user@1000.service/app.slice/vte-spawn-097a1a68-ec79-4cc8-93b3-9b2eb135071c.scope
drwxr-xr-x 2 ben ben 0 Sep 13 16:01  /sys/fs/cgroup/user.slice/user-1000.slice/user@1000.service/app.slice/vte-spawn-2d136b98-dc21-46f3-847d-3376e27683bf.scope
drwxr-xr-x 2 ben ben 0 Sep 13 20:24  /sys/fs/cgroup/user.slice/user-1000.slice/user@1000.service/app.slice/vte-spawn-3390b9e6-72dd-41cf-b32f-2a4cb5c9308e.scope
drwxr-xr-x 2 ben ben 0 Sep 13 10:09  /sys/fs/cgroup/user.slice/user-1000.slice/user@1000.service/app.slice/vte-spawn-459ceb88-de39-4fdc-be9d-5ae38cbd22b7.scope
drwxr-xr-x 2 ben ben 0 Sep 13 13:41  /sys/fs/cgroup/user.slice/user-1000.slice/user@1000.service/app.slice/vte-spawn-635849ac-7132-46e6-a11f-b6f2e2003bca.scope
drwxr-xr-x 2 ben ben 0 Sep 13 17:18  /sys/fs/cgroup/user.slice/user-1000.slice/user@1000.service/app.slice/vte-spawn-6d1607b8-49e6-4663-837f-e0b811fd7264.scope
drwxr-xr-x 2 ben ben 0 Sep 13 17:47  /sys/fs/cgroup/user.slice/user-1000.slice/user@1000.service/app.slice/vte-spawn-7d730827-2465-4d42-9bf9-031885154362.scope
drwxr-xr-x 2 ben ben 0 Aug 30 12:39  /sys/fs/cgroup/user.slice/user-1000.slice/user@1000.service/app.slice/vte-spawn-88742a3e-e074-4ab7-b427-dfb0d2c9c3e1.scope

Killing Firefox and launching the working version (I need it working to work anyway)

root@bumblebee:/home/ben# ls -ld /sys/fs/cgroup/user.slice/user-1000.slice/user@1000.service/app.slice/*scope | grep firefox
drwxr-xr-x 2 ben ben 0 Sep 14 09:15 /sys/fs/cgroup/user.slice/user-1000.slice/user@1000.service/app.slice/app-firefox_firefox-6fefbbb284f0470f896b1acee1fa539e.scope
drwxr-xr-x 2 ben ben 0 Sep 14 09:15 /sys/fs/cgroup/user.slice/user-1000.slice/user@1000.service/app.slice/snap.firefox.firefox.89dc741c-a17b-4e9f-b1bc-debefcf6d427.scope

Ok, will have to come back to this later. I'm not currently sure how to go about it, but I guess we need to find a way to identify how it ultimately gets called, and from what context.

Figured I'd have a quick go at getting auditd to log the call chain to see whether we can spot anything interesting.

Telling auditd to log everything

sudo auditctl -a exit,always -S execve

Then tailed /var/log/audit/audit.log and tee'd into a file:

• working.log
• notworking.log

OK, so in the not working one, we see the run occur

type=SYSCALL msg=audit(1663153138.092:719802491): arch=c000003e syscall=59 success=yes exit=0 a0=55a72f091ca0 a1=55a731edcab0 a2=55a72cba2480 a3=7f993296a9d8 items=2 ppid=11541 pid=810803 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=(none) ses=4 comm="snap" exe="/usr/bin/snap" subj=? key=(null)^]ARCH=x86_64 SYSCALL=execve AUID="ben" UID="ben" GID="ben" EUID="ben" SUID="ben" FSUID="ben" EGID="ben" SGID="ben" FSGID="ben"
type=EXECVE msg=audit(1663153138.092:719802491): argc=3 a0="/usr/bin/snap" a1="run" a2="firefox"

The parent pid is 11541, which is

ben@bumblebee:~$ ps aux | grep 11541
ben        11541  0.0  1.7 5162052 287512 ?      Sl   Aug30   5:35 /usr/bin/plasmashell

(makes sense)

There's a fair old chain there

type=PATH msg=audit(1663153138.092:719802491): item=0 name="/usr/bin/snap" inode=8782276 dev=103:05 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=? nametype=NORMAL cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0^]OUID="root" OGID="root"
type=UNKNOWN[1421] msg=audit(1663153138.092:719802491):
type=PATH msg=audit(1663153138.092:719802491): item=1 name="/lib64/ld-linux-x86-64.so.2" inode=8784211 dev=103:05 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=? nametype=NORMAL cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0^]OUID="root" OGID="root"
type=PROCTITLE msg=audit(1663153138.092:719802491): proctitle=2F7573722F62696E2F736E61700072756E0066697265666F78
type=UNKNOWN[1420] msg=audit(1663153138.092:719802491): subj_apparmor=unconfined
type=SYSCALL msg=audit(1663153138.112:719802634): arch=c000003e syscall=59 success=yes exit=0 a0=c000041170 a1=c00008bd40 a2=c0000b5520 a3=c0001fb480 items=2 ppid=11541 pid=810803 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=(none) ses=4 comm="snap" exe="/snap/snapd/16778/usr/bin/snap" subj=? key=(null)^]ARCH=x86_64 SYSCALL=execve AUID="ben" UID="ben" GID="ben" EUID="ben" SUID="ben" FSUID="ben" EGID="ben" SGID="ben" FSGID="ben"
type=EXECVE msg=audit(1663153138.112:719802634): argc=3 a0="/usr/bin/snap" a1="run" a2="firefox"
type=CWD msg=audit(1663153138.112:719802634): cwd="/home/ben"
type=UNKNOWN[1421] msg=audit(1663153138.112:719802634):

Ultimately we seen snap-confine being called

type=SYSCALL msg=audit(1663153138.136:719803083): arch=c000003e syscall=59 success=yes exit=0 a0=c0000c4ba0 a1=c0000d8880 a2=c00011e600 a3=0 items=2 ppid=11541 pid=810803 auid=1000 uid=1000 gid=1000 euid=0 suid=0 fsuid=0 egid=1000 sgid=1000 fsgid=1000 tty=(none) ses=4 comm="snap-confine" exe="/snap/snapd/16778/usr/lib/snapd/snap-confine" subj=? key=(null)^]ARCH=x86_64 SYSCALL=execve AUID="ben" UID="ben" GID="ben" EUID="root" SUID="root" FSUID="root" EGID="ben" SGID="ben" FSGID="ben"
type=EXECVE msg=audit(1663153138.136:719803083): argc=6 a0="/snap/snapd/16778/usr/lib/snapd/snap-confine" a1="--base" a2="core20" a3="snap.firefox.firefox" a4="/usr/lib/snapd/snap-exec" a5="firefox"

and desktop-launch

type=SYSCALL msg=audit(1663153138.156:719803349): arch=c000003e syscall=59 success=yes exit=0 a0=55a00db65b50 a1=55a00db65be8 a2=55a00df34328 a3=55a00db5cda2 items=3 ppid=11541 pid=810803 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=(none) ses=4 comm="desktop-launch" exe="/usr/bin/bash" subj=? key=(null)^]ARCH=x86_64 SYSCALL=execve AUID="ben" UID="ben" GID="ben" EUID="ben" SUID="ben" FSUID="ben" EGID="ben" SGID="ben" FSGID="ben"
type=EXECVE msg=audit(1663153138.156:719803349): argc=3 a0="/bin/bash" a1="/snap/firefox/1836/snap/command-chain/desktop-launch" a2="/snap/firefox/1836/firefox.launcher"

Then there are lots and lots of file accesses as firefox comes up

There are some dbus comms

type=SYSCALL msg=audit(1663153139.220:719825535): arch=c000003e syscall=59 success=yes exit=0 a0=55e9f2cc7db0 a1=55e9f2cc4940 a2=55e9f2cc2ca0 a3=55e9f2ca8010 items=2 ppid=811009 pid=811010 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=(none) ses=4 comm="dbus-send" exe="/usr/bin/dbus-send" subj=? key=(null)^]ARCH=x86_64 SYSCALL=execve AUID="ben" UID="ben" GID="ben" EUID="ben" SUID="ben" FSUID="ben" EGID="ben" SGID="ben" FSGID="ben"
type=EXECVE msg=audit(1663153139.220:719825535): argc=8 a0="dbus-send" a1="--print-reply=literal" a2="--session" a3="--dest=io.snapcraft.Settings" a4="/io/snapcraft/Settings" a5="io.snapcraft.Settings.Check" a6="string:default-web-browser" a7="string:firefox.desktop"

Actually, it does that a lot, but the exit code is 0 so I assume it's OK

Eventually, xdg-desktop-portal gets kicked off

type=SYSCALL msg=audit(1663153138.384:719807946): arch=c000003e syscall=59 success=yes exit=0 a0=561560a6fd00 a1=561560a6b3e0 a2=561560a76ad0 a3=7ffc6e84a830 items=2 ppid=1325 pid=810917 auid=1000 uid=1000 gid=1
000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=(none) ses=1 comm="xdg-desktop-por" exe="/usr/libexec/xdg-desktop-portal" subj=? key=(null)^]ARCH=x86_64 SYSCALL=execve AUID="ben" UID="ben" 
GID="ben" EUID="ben" SUID="ben" FSUID="ben" EGID="ben" SGID="ben" FSGID="ben"
type=EXECVE msg=audit(1663153138.384:719807946): argc=1 a0="/usr/libexec/xdg-desktop-portal"

The parent there is systemd's user process

ben@bumblebee:~$ ps aux | grep 1325
ben         1325  0.0  0.0  18856  5984 ?        Ss   Aug30   0:02 /lib/systemd/systemd --user

There's lots of chatter, and then eventually we see xdg-desktop-portal die

type=ANOM_ABEND msg=audit(1663153140.392:719841674): auid=1000 uid=1000 gid=1000 ses=1 subj=? pid=810917 comm="pool-/usr/libex" exe="/usr/libexec/xdg-desktop-portal" sig=11 res=1^]AUID="ben" UID="ben" GID="ben"

in working.log

We see the terminal get opened

type=SYSCALL msg=audit(1663153175.712:720595494): arch=c000003e syscall=59 success=yes exit=0 a0=55a72fdb0540 a1=55a730fbbae0 a2=55a72cba2480 a3=7f993296a9d8 items=2 ppid=11541 pid=811294 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=(none) ses=4 comm="konsole" exe="/usr/bin/konsole" subj=? key=(null)^]ARCH=x86_64 SYSCALL=execve AUID="ben" UID="ben" GID="ben" EUID="ben" SUID="ben" FSUID="ben" EGID="ben" SGID="ben" FSGID="ben"
type=EXECVE msg=audit(1663153175.712:720595494): argc=9 a0="/usr/bin/konsole" a1="-qwindowtitle" a2=46697265666F78205765622042726F77736572 a3="-qwindowicon" a4="/snap/firefox/1826/default256.png" a5="-e" a6="/usr/bin/snap" a7="run" a8="firefox"

The parent there (unsurprisingly) is plasmashell

That invokes snap

type=SYSCALL msg=audit(1663153176.368:720602383): arch=c000003e syscall=59 success=yes exit=0 a0=55b745f58a90 a1=55b745f68f30 a2=55b745eb4a00 a3=7f086c03d3f8 items=2 ppid=811294 pid=811316 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=pts7 ses=4 comm="snap" exe="/usr/bin/snap" subj=? key=(null)^]ARCH=x86_64 SYSCALL=execve AUID="ben" UID="ben" GID="ben" EUID="ben" SUID="ben" FSUID="ben" EGID="ben" SGID="ben" FSGID="ben"
type=EXECVE msg=audit(1663153176.368:720602383): argc=3 a0="/usr/bin/snap" a1="run" a2="firefox"
...
...
type=EXECVE msg=audit(1663153176.432:720602852): argc=6 a0="/snap/snapd/16778/usr/lib/snapd/snap-confine" a1="--base" a2="core20" a3="snap.firefox.firefox" a4="/usr/lib/snapd/snap-exec" a5="firefox"

and desktop-launch

type=EXECVE msg=audit(1663153176.468:720603252): argc=3 a0="/bin/bash" a1="/snap/firefox/1836/snap/command-chain/desktop-launch" a2="/snap/firefox/1836/firefox.launcher"

Eventually xdg-desktop-portal is launched

type=SYSCALL msg=audit(1663153176.932:720607770): arch=c000003e syscall=59 success=yes exit=0 a0=561560a0e130 a1=5615609f8c30 a2=561560a76ad0 a3=7ffc6e84a830 items=2 ppid=1325 pid=811426 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=(none) ses=1 comm="xdg-desktop-por" exe="/usr/libexec/xdg-desktop-portal" subj=? key=(null)^]ARCH=x86_64 SYSCALL=execve AUID="ben" UID="ben" GID="ben" EUID="ben" SUID="ben" FSUID="ben" EGID="ben" SGID="ben" FSGID="ben"

Again, the parent PID is the same as in notworking

Problem is, I just don't see much difference - albeit from a quick skim.

It does seem, though, like the snap being launched directly by plasmashell yields different behaviour to when run another way.

I created a new K-Menu item

/usr/bin/env > /tmp/with_terminal

Then ran it.

Then switched it over to without.

Running a diff of the two, there are various differences (because the terminal - konsole - also sets env vars), but the version without terminal has this

DESKTOP_STARTUP_ID=bumblebee;1663155505;944665;11541_TIME1295993384

It's used in startup notification:

Communicating from a launcher process to a launchee process
===

To communicate the startup sequence information from a launcher
process to a launchee process, when possible an environment variable
should be used:

 DESKTOP_STARTUP_ID
   value of the "ID" field in the "new" message

It is suggested to unset this environment variable in the launchee
as soon as it's read, to avoid possible reuse by some process started
later by launchee.

So, it might be interesting to override this in the run command and see if that gains us anything

Setting DESKTOP_STARTUP_ID doesn't seem to have broken the working version - though perhaps because it won't have reached anything with that id?

Just in case my initial check of environments was wrong, I've also pulled environment vars out of /proc for both broken and non-broken instances of Firefox

root@bumblebee:/home/ben# diff -u tmp/working_env.txt tmp/broken_env.txt  | egrep -e '^(-|\+)'
--- tmp/working_env.txt 2022-09-14 13:41:00.098184404 +0100
+++ tmp/broken_env.txt  2022-09-14 13:39:25.309601275 +0100
-PROFILEHOME=
+root@bumblebee:/home/ben# strings /proc/820564/environ
-KONSOLE_VERSION=211203
-SHELL_SESSION_ID=18373c2a758e4a7d9c91ae6d7ef6dc07
-KONSOLE_DBUS_SESSION=/Sessions/1
-COLORTERM=truecolor
-KONSOLE_DBUS_WINDOW=/Windows/1
-WINDOWID=98566151
-COLORFGBG=15;0
-TERM=xterm-256color
+DESKTOP_STARTUP_ID=bumblebee;1663158987;902425;11541_TIME1299475342
-KONSOLE_DBUS_SERVICE=:1.2092

Nothing really stands out.

The auditd stuff shows the commands run are the same, so it'd have to be something in the environment right? And yet there's nothing.

From the xdg-desktop-portal failure we can see it's failing to get the application's information, which I think is effectively derived from the underlying .desktop. I just can't work out why - I don't really know what I'm looking for.

Perhaps though, I'm looking at the wrong process? Maybe I should be looking closer at the portal process rather than Firefox - it's spawned as a result of the Firefox snap, so perhaps the way Firefox is started has a knock-on effect down the chain in a way that won't be visible when looking at Firefox itself?

Working:

root@bumblebee:/home/ben# ps aux | grep xdg-desktop-portal
ben         6756  0.0  0.0 336900  1948 ?        Ssl  Aug30   0:01 /usr/libexec/xdg-desktop-portal-gtk
ben         6775  0.0  0.4 1634812 68712 ?       Ssl  Aug30   0:27 /usr/lib/x86_64-linux-gnu/libexec/xdg-desktop-portal-kde
ben       821323  0.0  0.0 475784 13088 ?        Ssl  13:39   0:00 /usr/libexec/xdg-desktop-portal
root      823993  0.0  0.0   9212  2232 pts/9    S+   14:03   0:00 grep --color=auto xdg-desktop-portal

root@bumblebee:/home/ben# cat /proc/821323/cmdline 
/usr/libexec/xdg-desktop-portal

root@bumblebee:/home/ben# strings /proc/821323/environ 
HOME=/home/ben
LANG=en_GB.UTF-8
LANGUAGE=en_GB:en
LOGNAME=ben
PATH=/home/ben/.cargo/bin:/home/ben/.local/bin:/home/ben/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/home/ben/bin/:/bin:/home/ben/bin/:/bin
SHELL=/bin/bash
SYSTEMD_EXEC_PID=821323
USER=ben
XDG_RUNTIME_DIR=/run/user/1000
QT_ACCESSIBILITY=1
XDG_DATA_DIRS=/usr/share/plasma:/usr/local/share:/usr/share:/var/lib/snapd/desktop
CLUTTER_IM_MODULE=ibus
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus
DESKTOP_SESSION=plasma
DISPLAY=:0
GPG_AGENT_INFO=/run/user/1000/gnupg/S.gpg-agent:0:1
GPG_TTY=not a tty
GTK2_RC_FILES=/etc/gtk-2.0/gtkrc:/home/ben/.gtkrc-2.0:/home/ben/.config/gtkrc-2.0
GTK_IM_MODULE=ibus
GTK_RC_FILES=/etc/gtk/gtkrc:/home/ben/.gtkrc:/home/ben/.config/gtkrc
IM_CONFIG_PHASE=1
KDE_APPLICATIONS_AS_SCOPE=1
KDE_FULL_SESSION=true
KDE_SESSION_UID=1000
KDE_SESSION_VERSION=5
PAM_KWALLET5_LOGIN=/run/user/1000/kwallet5.socket
PWD=/home/ben
QT_AUTO_SCREEN_SCALE_FACTOR=0
QT_IM_MODULE=ibus
SESSION_MANAGER=local/bumblebee:@/tmp/.ICE-unix/6869,unix/bumblebee:/tmp/.ICE-unix/6869
SHLVL=0
SSH_AGENT_PID=6646
SSH_AUTH_SOCK=/tmp/ssh-XXXXXXlkhA7g/agent.6583
XAUTHORITY=/home/ben/.Xauthority
XCURSOR_SIZE=24
XCURSOR_THEME=breeze_cursors
XDG_CONFIG_DIRS=/home/ben/.config/kdedefaults:/etc/xdg/xdg-plasma:/etc/xdg:/usr/share/kubuntu-default-settings/kf5-settings
XDG_CURRENT_DESKTOP=KDE
XDG_SEAT=seat0
XDG_SEAT_PATH=/org/freedesktop/DisplayManager/Seat0
XDG_SESSION_CLASS=user
XDG_SESSION_DESKTOP=KDE
XDG_SESSION_ID=4
XDG_SESSION_PATH=/org/freedesktop/DisplayManager/Session1
XDG_SESSION_TYPE=x11
XDG_VTNR=1
XMODIFIERS=@im=ibus
_=/usr/bin/dbus-update-activation-environment
MANAGERPID=1325
INVOCATION_ID=119156bc729240fcbdf92e55fb219af1
JOURNAL_STREAM=8:202798566

To check it in the notworking state, I need it to stay up, so will disable the keepassxc browser extension for the test

root@bumblebee:/home/ben# ps aux | grep xdg-desktop-portal
ben         6756  0.0  0.0 336900  1948 ?        Ssl  Aug30   0:01 /usr/libexec/xdg-desktop-portal-gtk
ben         6775  0.0  0.4 1634812 68712 ?       Ssl  Aug30   0:27 /usr/lib/x86_64-linux-gnu/libexec/xdg-desktop-portal-kde
ben       821323  0.0  0.0 688784 13172 ?        Ssl  13:39   0:00 /usr/libexec/xdg-desktop-portal
root      825029  0.0  0.0   9212  2092 pts/9    S+   14:06   0:00 grep --color=auto xdg-desktop-portal

So.... it has the same PID - because, of course, we've not gone and segfaulted it yet. That'd suggest that the issue isn't related to the way it's launched...

Not much point grabbing the env then, as it won't have changed.

But... what happens if I now reenable keepassxc - will it cause xdg-desktop-portal to crash out?

no:

root@bumblebee:/home/ben# ps aux | grep xdg-desktop-portal
ben         6756  0.0  0.0 336900  1948 ?        Ssl  Aug30   0:01 /usr/libexec/xdg-desktop-portal-gtk
ben         6775  0.0  0.4 1634812 68712 ?       Ssl  Aug30   0:27 /usr/lib/x86_64-linux-gnu/libexec/xdg-desktop-portal-kde
ben       821323  0.0  0.0 688784 13208 ?        Ssl  13:39   0:00 /usr/libexec/xdg-desktop-portal
root      825158  0.0  0.0   9212  2176 pts/9    S+   14:09   0:00 grep --color=auto xdg-desktop-portal

and the extensions working!

Closing Firefox and re-launching to verify it still dies on startup

It killed it

root@bumblebee:/home/ben# ps aux | grep xdg-desktop-portal
ben         6756  0.0  0.0 336900  1948 ?        Ssl  Aug30   0:01 /usr/libexec/xdg-desktop-portal-gtk
ben         6775  0.0  0.4 1634812 68712 ?       Ssl  Aug30   0:27 /usr/lib/x86_64-linux-gnu/libexec/xdg-desktop-portal-kde
root      825614  0.0  0.0   9212  2288 pts/9    S+   14:09   0:00 grep --color=auto xdg-desktop-portal

So, lets disable the extension again and re-launch, just to verify that I didn't accidentally leave a working session open.

It killed it that time.

Ahh, but there's a difference - last time there was a preexisting working xdg-desktop-portal whereas this instance was launched by the "broken" Firefox. Let's do that cycle again quickly

No, didn't work. Did I screw up before, or was it blind luck?

In the ps above, I see that some of the subprocesses have been running for quite some time - does this still happen if I kill them?

It does.

Let's get back on track and compare the environments just in case (doesn't seem likely though as the original xdg-desktop-portal doesn't seem to survive)

root@bumblebee:/home/ben# cat /proc/828413/cmdline 
/usr/libexec/xdg-desktop-portal

root@bumblebee:/home/ben# strings /proc/828413/environ 
HOME=/home/ben
LANG=en_GB.UTF-8
LANGUAGE=en_GB:en
LOGNAME=ben
PATH=/home/ben/.cargo/bin:/home/ben/.local/bin:/home/ben/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/home/ben/bin/:/bin:/home/ben/bin/:/bin
SHELL=/bin/bash
SYSTEMD_EXEC_PID=828413
USER=ben
XDG_RUNTIME_DIR=/run/user/1000
QT_ACCESSIBILITY=1
XDG_DATA_DIRS=/usr/share/plasma:/usr/local/share:/usr/share:/var/lib/snapd/desktop
CLUTTER_IM_MODULE=ibus
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus
DESKTOP_SESSION=plasma
DISPLAY=:0
GPG_AGENT_INFO=/run/user/1000/gnupg/S.gpg-agent:0:1
GPG_TTY=not a tty
GTK2_RC_FILES=/etc/gtk-2.0/gtkrc:/home/ben/.gtkrc-2.0:/home/ben/.config/gtkrc-2.0
GTK_IM_MODULE=ibus
GTK_RC_FILES=/etc/gtk/gtkrc:/home/ben/.gtkrc:/home/ben/.config/gtkrc
IM_CONFIG_PHASE=1
KDE_APPLICATIONS_AS_SCOPE=1
KDE_FULL_SESSION=true
KDE_SESSION_UID=1000
KDE_SESSION_VERSION=5
PAM_KWALLET5_LOGIN=/run/user/1000/kwallet5.socket
PWD=/home/ben
QT_AUTO_SCREEN_SCALE_FACTOR=0
QT_IM_MODULE=ibus
SESSION_MANAGER=local/bumblebee:@/tmp/.ICE-unix/6869,unix/bumblebee:/tmp/.ICE-unix/6869
SHLVL=0
SSH_AGENT_PID=6646
SSH_AUTH_SOCK=/tmp/ssh-XXXXXXlkhA7g/agent.6583
XAUTHORITY=/home/ben/.Xauthority
XCURSOR_SIZE=24
XCURSOR_THEME=breeze_cursors
XDG_CONFIG_DIRS=/home/ben/.config/kdedefaults:/etc/xdg/xdg-plasma:/etc/xdg:/usr/share/kubuntu-default-settings/kf5-settings
XDG_CURRENT_DESKTOP=KDE
XDG_SEAT=seat0
XDG_SEAT_PATH=/org/freedesktop/DisplayManager/Seat0
XDG_SESSION_CLASS=user
XDG_SESSION_DESKTOP=KDE
XDG_SESSION_ID=4
XDG_SESSION_PATH=/org/freedesktop/DisplayManager/Session1
XDG_SESSION_TYPE=x11
XDG_VTNR=1
XMODIFIERS=@im=ibus
_=/usr/bin/dbus-update-activation-environment
MANAGERPID=1325
INVOCATION_ID=00f3a32d1b344e948398b8c3f4515c20
JOURNAL_STREAM=8:202973432

Basically exactly the same (some changes in PIDs).

Have hit a bit of dead-end this way then. I guess it's time to dig into the code a bit more - it definitely looks like it's something about the way in which xdg-desktop-portal retrieves information about apps rather than the way it's instantiated.

HOLY SHIT, A CLUE!!!

I had my browser open in the broken state, and turned the KeepassXC browser extension back on in Firefox's settings.

I was on a Zoom call at the time, and Zoom exited as soon as I turned the extension back on.

I've had weird shit previously with Zoom doing weird stuff to terminator because of Zoom's ibus dependency. I wonder if it's something along those lines?

It would also go some way to explaining why my other system doesn't suffer from this - it doesn't have Zoom installed. I might have to install it and see whether that breaks it.

OK, installing Zoom didn't break comms on my other laptop.

But, updating Zoom on this laptop

ben@bumblebee:~/Downloads$ sudo dpkg -i zoom_amd64\ \(1\).deb 
(Reading database ... 327690 files and directories currently installed.)
Preparing to unpack zoom_amd64 (1).deb ...
Unpacking zoom (5.11.10.4400) over (5.7.31792.0820) ...

Did fix the issue.

There must have been something about the older version which interfered.

They have a changelog at https://support.zoom.us/hc/en-us/articles/205759689-Release-notes-for-Linux but I don't see anything obvious - there is one about notification issues on Fedora, I wonder if the fix for that involved changing the way that Zoom hooks into the system?

Just to TL:DR this in case I need to refer back:

Firefox on Ubuntu is now run via snap

In order to facilitate communication with local applications (such as KeepassXC) via Native Messaging, there's a new daemon called xdg-desktop-portal

If a certain version (5.7.31792.0820 and possibly some later/earlier versions - it's not known when this was fixed) of Zoom is present (doesn't need to be running, just installed) on the machine, then xdg-desktop-portal will segfault if the following is true

• Firefox is launched from the K-Menu and doesn't have run in terminal set
• Firefox has an extension enabled which utilises NativeMessaging (for example the KeepassXC browser extension)

xdg-desktop-portal will not segfault if Firefox is started from the commandline, by doubleclicking a .desktop file (even the one used by the K-Menu) or if the K-Menu item is set to run in terminal.

If the extension is disabled, the launching Firefox from the K-Menu will not cause xdg-desktop-portal to segfault. However, it will segfault once the extension is enabled.

Curiously, if the extension is disabled, Firefox launched, a Zoom video call started and then the extension re-enabled, not only will xdg-desktop-portal segfault, but Zoom will die too.

Updating Zoom to the latest version (5.11.10.4400) resolves the issue.

Re-opening - this has broken again.

There was an update pending, so I did snap refresh and was moved to firefox (beta) 106.0b2-1 - comms with KeepassXC broke again.

As before, using "Run in Terminal" allows it to work...

I don't have time to troubleshoot this further at the moment, so am using "Run in Terminal" so that I can work. When I've a little more time free, I'll start by rebooting and then try and troubleshoot this again/further.

Although the previous Zoom update didn't update any dependencies, I wonder if it's post-install scripts (I assume it has them, haven't checked) disturbed the state of something somewhere.

Can check quite quickly/easily what it does

$ dpkg-deb -R zoom_amd64\ \(1\).deb .
$ cat DEBIAN/postinst 

Which gives us

#!/bin/bash
# Program:
#   script to be run after package installation

echo "run post install script, action is $1..."

update-mime-database /usr/share/mime || true
#update-desktop-database || true
if [ -x "/usr/bin/update-desktop-database" ]; then 
    update-desktop-database || true
else
    echo "/usr/bin/update-desktop-database command is missing! apt install desktop-file-utils and run this command again."
fi
#add chrome-sandbox setuid access  
if [ -e "/opt/zoom/cef/chrome-sandbox" ]; then 
    chown root /opt/zoom/cef/chrome-sandbox && chmod 4755 /opt/zoom/cef/chrome-sandbox || true
fi

Seems unlikely that the chown at the end is going to fix an unrelated application. It's plausible that update-desktop-database might though - we saw earlier in the investigation that the Application details fetched by xdg-desktop-portal are empty, so it might be that update-desktop-database causes it to be repopulated.

We can test that quickly.

Another user has reported that they're experiencing the same

Should really try and find time to troubleshoot this further.

Never got chance to dig in more, and it's all working fine for me again. I've had a change of laptop in the ensuing time and am now running XFCE rather than KDE (which may or may not be relevant).