Bug#1026070: kde-plasma-desktop: Right click on desktop and taskbar has no effect

[Max Görner]

Package: kde-plasma-desktop
Version: 5:135
Severity: important

Dear Maintainer,


about the same time as bug #1022972 appeard, after an update about one
and half months ago, right clicks stopped to have an effect in certain
situations.

Previously, when doing an right click on the desktop, a context menu
opened. One of the elements of that context menu was an element that
opened an appearance settings menu which allowed me to configure the
background image. This context menu does not appear anymore.

Also, a right click on the taskbar, which holds Kickoff, the icons of
open windows, the clock and the tray bar, has no effect neither. Thus I
am able neither to change its position nor to add or remove any widgets.

I experience the very same problem on two machines that run Debian
Bookworm. I do not experience it on a machine that runs Ubuntu 22.04, if
that is of any help.

In #1022972 it was found that the keyboard layout had an effect on the
issue. This is not the case here. I added normal German layout as a
secondary layout, but the problem persists even when I change to it.

Best Regards
Max

[1]: About the same time as bug #1022972 appeared.


-- System Information:
Debian Release: bookworm/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.0.0-5-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=de:en_GB
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages kde-plasma-desktop depends on:
ii kde-baseapps 4:21.08.0+5.135
ii plasma-desktop 4:5.26.4-1
ii plasma-workspace 4:5.26.4.1-1
ii udisks2 2.9.4-4
ii upower 0.99.20-2

Versions of packages kde-plasma-desktop recommends:
ii kwin-x11 4:5.26.4-1
ii sddm 0.19.0-4
ii xserver-xorg 1:7.7+23

Versions of packages kde-plasma-desktop suggests:
ii kdeconnect 21.12.3-2

-- no debconf information

[Aurélien COUDERC]

control: tags -1 + moreinfo

Dear Max,

Le 14 décembre 2022 10:09:44 GMT+01:00, "Max Görner" <max+re...@familie-goerner.eu> a écrit :
>Package: kde-plasma-desktop
>Version: 5:135
>Severity: important
>
>Dear Maintainer,
>
>
>about the same time as bug #1022972 appeard, after an update about one
>and half months ago, right clicks stopped to have an effect in certain
>situations.
>
>Previously, when doing an right click on the desktop, a context menu
>opened. One of the elements of that context menu was an element that
>opened an appearance settings menu which allowed me to configure the
>background image. This context menu does not appear anymore.
>
>Also, a right click on the taskbar, which holds Kickoff, the icons of
>open windows, the clock and the tray bar, has no effect neither. Thus I
>am able neither to change its position nor to add or remove any widgets.
>
>I experience the very same problem on two machines that run Debian
>Bookworm. I do not experience it on a machine that runs Ubuntu 22.04, if
>that is of any help.

thank you for your bug report.

There are many people running testing and/or unstable, me included, for whom this bug doesn't happen. So we'll need a bit more analysis if we want to get it fixed.

Could you try creating a new user (without an existing $HOME directory) on one of the machines where you see the bug and report back if the new user still has the issue ?

Also can you find anything meaningful in the system log at the time where you right click or during the load of the user session ?

Lastly if you could have a look at the upstream bugs.kde.org platform and look for a similar bug report that would be useful. I'll have a look too when I can.


Happy hacking !
--
Aurélien

[Max Görner]

Hi Aurélien,

thank you for your quick reply.

> There are many people running testing and/or unstable, me included, for whom this bug doesn't happen. So we'll need a bit more analysis if we want to get it fixed.
>
> Could you try creating a new user (without an existing $HOME directory) on one of the machines where you see the bug and report back if the new user still has the issue ?

I created a new user via `adduser` and the problem persisted for it.
Interestingly, that user had a black background and not some default
background image. The .xsession-errors contains some complaints about missing
/home/kdetest.config/kdedefaults, but I did not try to resolve this.

> Also can you find anything meaningful in the system log at the time where you right click or during the load of the user session ?

The section of my .xsession-erros for today:

Xsession: X session started for mgoerner at Mi 14. Dez 09:18:06 CET 2022
dbus-update-activation-environment: setting
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus
dbus-update-activation-environment: setting DISPLAY=:0
dbus-update-activation-environment: setting
XAUTHORITY=/home/mgoerner/.Xauthority
localuser:mgoerner being added to access control list
dbus-update-activation-environment: setting GTK_MODULES=gail:atk-bridge
dbus-update-activation-environment: setting QT_ACCESSIBILITY=1

The .xsession-errors for the new created user:


Xsession: X session started for kdetest at Mi 14. Dez 11:58:00 CET 2022
dbus-update-activation-environment: setting DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1002/bus
dbus-update-activation-environment: setting DISPLAY=:1
dbus-update-activation-environment: setting XAUTHORITY=/home/kdetest/.Xauthority
localuser:kdetest being added to access control list
dbus-update-activation-environment: setting GTK_MODULES=gail:atk-bridge
dbus-update-activation-environment: setting QT_ACCESSIBILITY=1
QIODevice::read (QFile, "/home/kdetest/.config/kdedefaults/package"): device not open
QDBusConnection: error: could not send signal to service "" path "//home/kdetest/.config/kdedefaults/kdeglobals" interface "org.kde.kconfig.notify" member "ConfigChanged": Invalid object path: //home/kdetest/.config/kdedefaults/kdeglobals
QDBusConnection: error: could not send signal to service "" path "//home/kdetest/.config/kdedefaults/kdeglobals" interface "org.kde.kconfig.notify" member "ConfigChanged": Invalid object path: //home/kdetest/.config/kdedefaults/kdeglobals
QDBusConnection: error: could not send signal to service "" path "//home/kdetest/.config/kdedefaults/kdeglobals" interface "org.kde.kconfig.notify" member "ConfigChanged": Invalid object path: //home/kdetest/.config/kdedefaults/kdeglobals
QDBusConnection: error: could not send signal to service "" path "//home/kdetest/.config/kdedefaults/kcminputrc" interface "org.kde.kconfig.notify" member "ConfigChanged": Invalid object path: //home/kdetest/.config/kdedefaults/kcminputrc
QDBusConnection: error: could not send signal to service "" path "//home/kdetest/.config/kdedefaults/kwinrc" interface "org.kde.kconfig.notify" member "ConfigChanged": Invalid object path: //home/kdetest/.config/kdedefaults/kwinrc
QDBusConnection: error: could not send signal to service "" path "//home/kdetest/.config/kdedefaults/kwinrc" interface "org.kde.kconfig.notify" member "ConfigChanged": Invalid object path: //home/kdetest/.config/kdedefaults/kwinrc
QPixmap: QGuiApplication must be created before calling defaultDepth().
QPixmap: QGuiApplication must be created before calling defaultDepth().

Neither `journalctl` nor `sudo journalctl` show anything of interest after
right clicking somewhere. Are there other logs I should have a look at?

> Lastly if you could have a look at the upstream bugs.kde.org platform and
> look for a similar bug report that would be useful. I'll have a look too when
> I can.

I will do so and report if I find something.


Best
Max Görner

[Max Görner]

Hello again,

I was able to find out a little bit more.

As I wrote I experience the issue on my second computer running on Debian
Testing too. However, a second user of that computer reported that she does
not suffer from that right click issue. So I tried to create a test user on
that second computer too and for this test user the issue did not appear
neither.

So, to sum up: On my Thinkpad both my main user and the fresh test user
experience the right click issue. On my PC only my main user, but neither the
permanent second user nor the fresh test user experienced the issue.

I cannot think of any actual relevant difference. The only thing that comes to
my mind is that the Thinkpad has the keyboard Neo2 configured as main layout,
so I even type in the passphrase for the whole disk encryption in Neo2. The
PC uses some more usual German variant.

I would be very glad if you would have any suggestion what I could do to
narrow down the issue a bit more.


When I created the test users, I noticed that each and every time KDE
complained about that the folder `~/.config/kdedefaults` was missing. I would
expect that after running `adduser` or adding a new user using KDE's settings
dialog KDE would be bootstrap itself. Instead, there are error messages in
`.xsession-errors` and the desktop background stays black.

Should I file a separate bug for this or is this behaviour already known?


Best Regards
Max Görner

[max+re...@familie-goerner.eu]

Dear Maintainer,

I just wanted to inform you that right click on the desktop works again as intended. I did an

`apt full-upgrade` yesterday and today. Only with the upgrade today (~8:30am

CET) right click started to function correctly again.

Thank you very much for your efforts.