Bug 2179591

I reproduced the black screen problem when logging out as the second user in my Fedora 38 installation. loginctl in the VT showed that the second user's session was still active and there wasn't a sddm session. The problem might involve the second user's session not being properly stopped so that the sddm session never started. The errors I reported might have prevented the second user's session from stopping.

Fabian Vogt commented "Bug in SDDM, fixed upstream: https://github.com/sddm/sddm/issues/1660" on my upstream report https://bugs.kde.org/show_bug.cgi?id=467547#c2 This problem still happened after I updated to sddm-0.19.0^git20230320.e07e805-2.fc38 https://koji.fedoraproject.org/koji/buildinfo?buildID=2172984 in my Fedora 38 KDE Plasma installation, rebooted twice, then logged in as the second user and logged out. 
sddm-0.19.0^git20230320.e07e805-2.fc38 appears to have the commit https://github.com/sddm/sddm/commit/e07e805c21310572b4fecc810fd5610b1d3d03fd which was marked as fixing https://github.com/sddm/sddm/issues/1660 for the user switching problem. This logout problem might be different from that one and doesn't seem to be fixed.

The second users had the standard account type in System Settings' User page. The first users had the administrator account type in System Settings' User page and were in the wheel group.

Proposed as a Blocker and Freeze Exception for 38-final by Fedora user mattf using the blocker tracking app because:

 Logging out of Plasma 5.27.3 on Wayland as the second user on the system resulted in a black screen in a F38 KDE Plasma installation and QEMU/KVM VM. loginctl in the VT showed that the second user's session was still active and there wasn't a sddm session. The problem might involve the second user's session not being properly stopped so that the sddm session never started. The errors I reported might have prevented the second user's session from stopping. The Fedora 38 Beta blocker criterion "Shutting down, rebooting, logging in and logging out must work using standard console commands and the mechanisms offered (if any) by all release-blocking desktops." might be violated. https://fedoraproject.org/wiki/Fedora_38_Beta_Release_Criteria#Shutdown,_reboot,_login,_logout

I can reproduce this on VM too:

sddm-0.19.0^git20230312.d00b2ce-0.fc38.1.x86_64
kde-settings-sddm-38.2-2.fc38.noarch
sddm-wayland-plasma-5.27.3-1.fc38.noarch
sddm-breeze-5.27.3-1.fc38.noarch
sddm-kcm-5.27.3-1.fc38.x86_64

kf5-kwindowsystem-5.104.0-1.fc38.x86_64

kwin-libs-5.27.3-2.fc38.x86_64
kwin-common-5.27.3-2.fc38.x86_64
kwin-wayland-5.27.3-2.fc38.x86_64
kwin-x11-5.27.3-2.fc38.x86_64
kwin-5.27.3-2.fc38.x86_64

xdg-desktop-portal-1.16.0-2.fc38.x86_64
xdg-desktop-portal-gtk-1.14.1-2.fc38.x86_64
xdg-desktop-portal-kde-5.27.3-1.fc38.x86_64

Huh, this is very interesting. I can easily reproduce this bug, but it's literally happening *only* for the second user in the system.

I created the first user (User 1) in the installer, and 3 more users (Users 2 & 3 & 4) in the installed system using KDE's Users app. Users 2 and 3 are standard users, users 1 & 4 are admins. This problem only affects User 2. Every time I try to log out, it ends with a black screen. Even in a clean boot scenario, where I only log in as User 2 and then log out, it's the same. But I can log in and out with any other user just fine, repeatedly, without any issues.

What is different about User 2 (or, in other words, the first user created in KDE's Users app)?

I cannot reproduce this and I have tried really hard with various combinations of users and how I created them. I also reinstalled the VM between the attempts to get as much clean environment as possible.

1. Five users created with `useradd` -> all work OK
2. Five users created with KDE -> all work OK.
3. Three users created with KDE -> all work OK.
4. Two users created with KDE -> the second user works OK.

How shall I reproduce it? I am using the fully updated 20230318 iso.

My reproducer was:
1. Install KDE Live, create an admin user in the installer, don't create a root user.
2. Log in to KDE, fully update it through Discover, reboot.
3. Open System Settings -> Users.
4. Create a standard account, e.g. "tester" (this is "User 2").
5. Log out my User 1, log in User 2.
6. Log out User 2, black screen.
7. Reboot.
8. Log in User 2.
9. Log out User 2, black screen.

I didn't update the Fedora-KDE-Live-x86_64-38-20230318.n.0.iso VM before I reproduced the problem. The second user was of the standard account type  in System Settings' User page and not in the wheel group, while the first user was an administrator account type and was in the wheel group. I saw this problem about 5/5 times in my F38 installation on bare metal, and about 5/10 times in live VMs with Fedora-KDE-Live-x86_64-38-20230318.n.0.iso  and Fedora-KDE-Live-x86_64-38-20230320.n.0.iso. Some kind of race condition might be involved. If kwin_wayland or some KDE program involved in ending the user session stopped before the user session was stopped, this problem might have happened. I don't know why that would only affect the second user. Thanks.

I saw SELinux denials of sss_cache reading a pipe or fifo_file when creating new users in System Settings with a Fedora 38 live image Fedora-KDE-Live-x86_64-38-20230322.n.0.iso in a GNOME Boxes QEMU/KVM VM. I reproduced the denials in my F38 KDE Plasma installation on bare metal. I reported the denials in more detail at https://bugzilla.redhat.com/show_bug.cgi?id=2181010 The users were still created. There were denials and errors like the following.
Mar 22 16:23:53 audit[8649]: AVC avc:  denied  { read } for  pid=8649 comm="sss_cache" path="pipe:[291359]" dev="pipefs" ino=291359 scontext=system_u:system_r:sssd_t:s0 tcontext=system_u:system_r:accountsd_t:s0 tclass=fifo_file permissive=0
Mar 22 16:23:54 accounts-daemon[8649]: [sss_cache] [confdb_init] (0x0010): Unable to open config database [/var/lib/sss/db/config.ldb]
Mar 22 16:23:54 accounts-daemon[8649]: Could not open available domains
Mar 22 16:23:54 chpasswd[8645]: chpasswd: sss_cache exited with status 5
Mar 22 16:23:54 chpasswd[8645]: chpasswd: Failed to flush the sssd cache.

I don't know if the denials or errors might be related to this logout problem.

Matt, that's great info. I believe you've found a very probable root cause. I also see these AVC denials on my system.

My findings:

* The logout issue of User 2 is a race condition. Sometimes, rarely, logout works fine. But at least in my case, the failure ratio is about 90%. (For other users, I have 0% failure).
* When I switch to a permissive mode, it doesn't fix an already-created User 2. Logout failures still happen.
* When I reinstall the system and switch to a permissive mode *before creating User 2*, then User 2 is not affected by the logout issue.

I've done several passes to confirm this theory, and it behaves consistently for me. So I'll mark bug 2181010 as blocking this bug.

(In reply to Kamil Páral from comment #7)
> My reproducer was:
> 1. Install KDE Live, create an admin user in the installer, don't create a
> root user.
> 2. Log in to KDE, fully update it through Discover, reboot.
> 3. Open System Settings -> Users.
> 4. Create a standard account, e.g. "tester" (this is "User 2").
> 5. Log out my User 1, log in User 2.
> 6. Log out User 2, black screen.
> 7. Reboot.
> 8. Log in User 2.
> 9. Log out User 2, black screen.

I followed your reproducer and still were not able to reproduce it at first. Finally, I was able to reproduce but I am only seeing it like in one in three attemtps. After the restart, I can successfully log out twice and the third time is critical.

Hello
I have same issue on Fedora 37 KDE 2 users unable to use logout function without my system crashing.

Full log here https://logs.notifiarr.com/?17520fc3d83e8ab8#8vrDENm1v8DAKTAzSbULfhZiriDS5ckRtaMeX5nECcDT

Which everway i swap it black screens the desktop X11 logout or Wayland logout.

Sceen goes black system need hard reset and it opens a grub menu then logs in.

This is a old long term issue back to Fed 32 that needs addressing.

I have the selinux denial and cannot reproduce this bug

Can any of the testers verify if their systems included this update: https://bodhi.fedoraproject.org/updates/FEDORA-2023-dad8b1e03f ?

Cannot reproduce with nor without the linked sddm update

(In reply to marcdeop from comment #14)
> Can any of the testers verify if their systems included this update:
> https://bodhi.fedoraproject.org/updates/FEDORA-2023-dad8b1e03f ?

I can reproduce it with this version here too sddm-0.19.0^git20230320.e07e805-2.fc38

Created attachment 1953290 [details]
updated this packages and bug still happens at this VM

Here the VM I'm using, bug reproducible:

Operating System: Fedora Linux 38
KDE Plasma Version: 5.27.3
KDE Frameworks Version: 5.104.0
Qt Version: 5.15.8
Kernel Version: 6.2.7-300.fc38.x86_64 (64-bit)

Graphics Platform: Wayland
Processors: 4 × Intel® Core™ i7-3632QM CPU @ 2.20GHz
Memory: 1.9 GiB of RAM
Graphics Processor: llvmpipe
Manufacturer: QEMU
Product Name: Standard PC (Q35 + ICH9, 2009)
System Version: pc-q35-7.0

kde-settings-sddm-38.2-2.fc38.noarch
sddm-kcm-5.27.3-1.fc38.x86_64
sddm-wayland-plasma-5.27.3-2.fc38.noarch
sddm-breeze-5.27.3-2.fc38.noarch
sddm-0.19.0^git20230320.e07e805-2.fc38.x86_64

xdg-desktop-portal-1.16.0-2.fc38.x86_64
xdg-desktop-portal-gtk-1.14.1-2.fc38.x86_64
xdg-desktop-portal-kde-5.27.3-1.fc38.x86_64

kf5-kwindowsystem-5.104.0-1.fc38.x86_64
kwin-libs-5.27.3-2.fc38.x86_64
kwin-common-5.27.3-2.fc38.x86_64
kwin-wayland-5.27.3-2.fc38.x86_64
kwin-x11-5.27.3-2.fc38.x86_64
kwin-5.27.3-2.fc38.x86_64

Something new about this bug:
Following marcdeop suggestion I created another regular user at cli (sudo useradd username, sudo passwd username) then I logged out, login at new user and logged out again. Made this succefully four times in a roll. Then tried to login and logou with the other second user, (that originaly created at system settings, having problems at logout) and, surprise, now this user too managed to logout without any problems, four times in a roll.

Oops sorry for the flag Marc, it wasn't my intention.

Testing last F38KDE build (Fedora-KDE-Live-x86_64-38-20230326.n.1.iso) I cannot reproduce this bug anymore:

Operating System: Fedora Linux 38
KDE Plasma Version: 5.27.3
KDE Frameworks Version: 5.104.0
Qt Version: 5.15.8
Kernel Version: 6.2.8-300.fc38.x86_64 (64-bit)

Graphics Platform: Wayland
Processors: 4 × Intel® Core™ i7-3632QM CPU @ 2.20GHz
Memory: 1.8 GiB of RAM
Graphics Processor: llvmpipe
Manufacturer: QEMU
Product Name: Standard PC (Q35 + ICH9, 2009)
System Version: pc-q35-7.0

sddm-wayland-plasma-5.27.3-2.fc38.noarch
sddm-0.19.0^git20230320.e07e805-2.fc38.x86_64
kde-settings-sddm-38.2-2.fc38.noarch
sddm-breeze-5.27.3-2.fc38.noarch
sddm-kcm-5.27.3-1.fc38.x86_64

xdg-desktop-portal-1.16.0-2.fc38.x86_64
xdg-desktop-portal-kde-5.27.3-1.fc38.x86_64
xdg-desktop-portal-gtk-1.14.1-2.fc38.x86_64

kf5-kwindowsystem-5.104.0-1.fc38.x86_64
kwin-libs-5.27.3-2.fc38.x86_64
kwin-common-5.27.3-2.fc38.x86_64
kwin-wayland-5.27.3-2.fc38.x86_64
kwin-x11-5.27.3-2.fc38.x86_64
kwin-5.27.3-2.fc38.x86_64

Sigh, I think we're victims of the race condition. I still have a snapshot of a VM where I could easily trigger the bug any time, and I can't trigger it today (with no updates performed).

+6 in https://pagure.io/fedora-qa/blocker-review/issue/1122 , marking accepted.

Should we mark this as ON_QA since https://bodhi.fedoraproject.org/updates/FEDORA-2023-624eb88729 exists? Should we mark that update as fixing this bug?

If any of the testers could switch to a TTY or access via ssh the machine when they hit the bug, it would be nice if you could check:

* loginctl list-session
* loginctl session-status $sessioNumber

It would also be interesting to check if the issue happens when creating users via the CLI instead of the KDE interface (as Geraldo mentioned).

Another thing is: once we hit the bug, does creating another user from the CLI fix the issue?

I updated to selinux-policy-38.9-1.fc38 and created a third user in my F38 installation. The sss_cache denial didn't happen when creating the user, but the other sss_cache errors were still shown in the journal as I reported at https://bugzilla.redhat.com/show_bug.cgi?id=2181010 The black screen on logout happened 3/6 times with the third user. So selinux-policy-38.9-1.fc38 doesn't fix the logout problem for me at least. I installed the system in mid 2020 from a Rawhide KDE Plasma live image, and I created the second user on the system right after that. I don't know if the sss_cache denial happened then, but it seems unlikely. 

loginctl list-session and loginctl session-status showed the second user's session as still active from a VT. There were about 20 processes still remaining when I ran systemctl status user. No KDE programs were still running. The remaining processes included dbus-broker, systemd, pipewire, wireplumber, uresourced, and several GNOME programs since I have GNOME installed also and logging into Plasma runs some of them. plasmashell, xdg-desktop-portal-kde, powerdevil were restarted sometimes and then crashed when the problem happened but also when it didn't.
Marc, did you mean creating a new user from the VT when the problem happened, and then restart sddm and log in as the new user and log out or something else? Thanks.

Matt: if you have xdg-desktop-portal-gnome installed... try removing it.

Regarding the user creation: I was only wondering if KDE was doing something ugly when creating users and that was fixed if you used the "normal" cli tools afterwards.

When I ran sudo dnf remove xdg-desktop-portal-gnome, 27 packages were going to be removed including gnome-shell. I think that would make GNOME unusable in my installation so I haven't tried it. I updated to F38 2 weeks ago. Firefox, Thunderbird, GNOME Boxes and gnome-abrt took much longer to start in Plasma in F38 than F37 with xdg-desktop-portal.service and xdg-desktop-portal-gnome.service timing out as I reported at https://bugzilla.redhat.com/show_bug.cgi?id=2176759 I prevented xdg-desktop-portal-gnome from running with systemctl mask xdg-desktop-portal-gnome --user as a workaround to that problem at that time. So xdg-desktop-portal-gnome shouldn't be run in my installation.

I reproduced the logout problem with the second user on my F38 installation. I created a third user with useradd user3 then passwd user3 in VT2. There weren't any sss_cache denials or errors in the journal when creating the third user that way. The logout problem happened 5/5 with the third user. The screen froze twice after logging in and before the splash screen appeared. I used sysrq+alt+e to stop all processes to get back to sddm. ksplashqml crashed those times.

So if I read all of this correctly:
1. The problem doesn't affect just the second-created user.
2. The problem isn't specific to KDE System Settings -> Users, but also `useradd` (which means likely any means of adding a user).
3. KDE System Settings -> Users have some problem with sss_cache, which `useradd` doesn't have, but it's not related to the logout problem. This also means that the selinux-policy fix is likely unrelated to it.
4. There is also a login issue, but that might be unrelated to the logout issue.
5. The logout issue is very much a race.

(In reply to Kamil Páral from comment #29)
> So if I read all of this correctly:
> 1. The problem doesn't affect just the second-created user.

Correct

> 2. The problem isn't specific to KDE System Settings -> Users, but also
> `useradd` (which means likely any means of adding a user).

Correct

> 3. KDE System Settings -> Users have some problem with sss_cache, which
> `useradd` doesn't have, but it's not related to the logout problem. This
> also means that the selinux-policy fix is likely unrelated to it.

Correct

> 4. There is also a login issue, but that might be unrelated to the logout
> issue.

It probably is related but more a consequence rather than a cause. If you logout and experience the issue, likely a process might be lingering there which will cause issues if you try to log in again with the same user.

> 5. The logout issue is very much a race.
It seems to be. However, the more issues like this one I read, the more I think it's due to something Gnome related. What I mean is that this is unlikely to be a kwin issue (and that's the component we have in this bug report)



Anyway, for those users who can reproduce the problem: what happens if you wait 90-120 seconds (I think that's systemd's timeout and perhaps also logind's)? Do things then go back to normal?

I reproduced the problem with the second user in my F38 installation. I waited several minutes, and the black screen remained. I think the systemd timeout was reduced to 45 s in F38 https://fedoraproject.org/wiki/Changes/Shorter_Shutdown_Timer

I saw the problem with Fedora-KDE-Live-x86_64-38-20230318.n.0.iso in a QEMU/KVM VM in GNOME Boxes in which GNOME wasn't installed, so I don't think the problem is due to GNOME.

dbus-:1.2-org.kde.LogoutPrompt failed on every logout, so that might be part of the problem. kwin_wayland stopped before most other KDE programs resulting in the Wayland connection errors I originally reported. I don't know if the problem is in kwin, but something seemed to be wrong with that. ksmserver is a KDE session management server so if ksmserver stopped before the session was stopped, this problem might be what resulted.

sssd-kcm.service runs on my system which runs sssd and might be where the sss_cache errors are from. sssd-kcm.service had stopped when the black screen happened and wasn't restarted when I logged into another VT and created the third user.

I removed GNOME from my F38 KDE Plasma installation and rebooted. The logout problem happened 4/4 times with the second user. I created a third user with sudo useradd user3 then sudo passwd user3 in Konsole in Plasma. No sss_cache errors or denials were in the journal when I created the third user. The logout problem happened 5/5 times with the third user.

Hmm, it turns out I still have one previously-installed VM where I can easily reproduce the problem, even when I fully update all packages. In a different VM, I was unable to trigger it, though.


When the logout issue (for user 'tester') happens:

[kparal@f38kde ~]$ loginctl list-sessions 
SESSION  UID USER   SEAT  TTY  
      2 1000 kparal       pts/0
      7 1001 tester seat0 tty3

2 sessions listed.

(Session 2 is my ssh session to collect logs.)


[kparal@f38kde ~]$ loginctl session-status 7
7 - tester (1001)
           Since: Thu 2023-03-30 13:40:23 CEST; 4min 46s ago
          Leader: 2364 (sddm-helper)
            Seat: seat0; vc3
             TTY: tty3
         Service: sddm; type wayland; class user
         Desktop: KDE
           State: active
            Unit: session-7.scope
                  └─2364 /usr/libexec/sddm-helper --socket /tmp/sddm-auth-8466ca7a-dcc1-46e8-8d86-7969b9b918d9 --id 3>

Mar 30 13:40:23 f38kde systemd[1]: Started session-7.scope - Session 7 of User tester.
Mar 30 13:40:23 f38kde sddm-helper[2376]: pam_kwallet5: final socket path: /run/user/1001/kwallet5.socket
Mar 30 13:40:40 f38kde kwalletd5[2377]: The Wayland connection broke. Did the Wayland compositor die?
Mar 30 13:40:40 f38kde kwalletd5[2377]: The Wayland connection broke. Did the Wayland compositor die?

Created attachment 1954665 [details]
sddm backtrace in gdb

Here are backtraces of running processes sddm and sddm-helper while the logout issue is present (a black screen with a cursor instead of sddm).

Created attachment 1954666 [details]
sddm-helper backtrace in gdb

Can anybody check what happens when they hit the bug and they trigger a `loginctl terminate-session $sessionId` or `loginctl kill-session $sessionId` ?

Do you get back to SDDM then?

I tried loginctl terminate-session $sessionId days ago, and it did stop the user's session. An sddm session wasn't started in the normal way, and sddm didn't appear. I saw output like Kamil mentioned in comment 33 in the VT. I think the sddm backtraces Kamil attached showed sddm and sddm-helper waiting. If the user's session isn't stopped properly due to the failure of dbus-:1.2-org.kde.LogoutPrompt which runs /usr/libexec/ksmserver-logout-greeter from /usr/share/dbus-1/services/org.kde.LogoutPrompt.service, then the sddm session might not be restarted and sddm might be left waiting indefinitely. Since dbus-:1.2-org.kde.LogoutPrompt, ksmserver-logout-greeter, and ksmserver are in plasma-workspace, I'm reassigning this report to that package.

After `loginctl terminate-session $num`:

Mar 31 10:10:58 f38kde sudo[3591]:   kparal : TTY=pts/0 ; PWD=/home/kparal ; USER=root ; COMMAND=/usr/bin/loginctl terminate-session 4
Mar 31 10:10:58 f38kde audit[3591]: CRED_REFR pid=3591 uid=1000 auid=1000 ses=5 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:setcred grantors=pam_localuser,pam_unix acct="root" exe="/u>
Mar 31 10:10:58 f38kde sudo[3591]: pam_unix(sudo:session): session opened for user root(uid=0) by kparal(uid=1000)
Mar 31 10:10:58 f38kde audit[3591]: USER_START pid=3591 uid=1000 auid=1000 ses=5 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:session_open grantors=pam_keyinit,pam_limits,pam_keyinit,p>
Mar 31 10:10:58 f38kde systemd[1]: Stopping session-4.scope - Session 4 of User tester...
Mar 31 10:10:58 f38kde sddm[820]: Authentication error: SDDM::Auth::ERROR_INTERNAL "Process crashed"
Mar 31 10:10:58 f38kde audit[3591]: USER_END pid=3591 uid=1000 auid=1000 ses=5 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:session_close grantors=pam_keyinit,pam_limits,pam_keyinit,pa>
Mar 31 10:10:58 f38kde systemd[1]: session-4.scope: Deactivated successfully.
Mar 31 10:10:58 f38kde sudo[3591]: pam_unix(sudo:session): session closed for user root
Mar 31 10:10:58 f38kde sddm[820]: Auth: sddm-helper (--socket /tmp/sddm-auth-8480d70f-2329-4349-9472-52a1a22753e0 --id 3 --start /usr/libexec/plasma-dbus-run-session-if-needed /usr/bin/startplasma-wayland --use>
Mar 31 10:10:58 f38kde sddm[820]: Authentication error: SDDM::Auth::ERROR_INTERNAL "Process crashed"
Mar 31 10:10:58 f38kde sddm[820]: Auth: sddm-helper exited with 1
Mar 31 10:10:58 f38kde audit[3591]: CRED_DISP pid=3591 uid=1000 auid=1000 ses=5 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:setcred grantors=pam_localuser,pam_unix acct="root" exe="/u>
Mar 31 10:10:58 f38kde systemd[1]: Stopped session-4.scope - Session 4 of User tester.
Mar 31 10:10:58 f38kde systemd-logind[700]: Removed session 4.


But visually, nothing changes. Still a black screen with a blinking cursor. You can switch to a different VT with Alt+arrow or Ctrl+Alt+Fnum. From the prompts, it's clear that the blinking cursor tty is tty1.

It seems upstream might have found a solution to this issue.

I have created a build for you guys to test at https://copr.fedorainfracloud.org/coprs/g/kdesig/sddm/

@kparal : as it seems you can reproduce the issue, would you mind testing the new build?

I updated to sddm-0.19.0^git20230403.67b8e4c-1.fc38.x86_64 https://bugzilla.redhat.com/show_bug.cgi?id=2179591#c39 to test the new patch. Logout of Plasma as the second user on the system happened normally 8/8 times. The black screen problem didn't happen. The user's session stopped and the sddm session started. The dbus-:1.2-org.kde.LogoutPrompt failures and other errors were still shown in the journal. I'm reassigning the report to sddm as a result. Thanks.

isn't the problem solved now, though?

The black screen problem didn't happen for me when I logged out 9/9 times. I'd wait until others who saw this problem test this before considering it fixed in general since this problem involves a race condition. The dbus-:1.2-org.kde.LogoutPrompt failures and other errors might be different problems. More info on the problem was described at https://bugs.kde.org/show_bug.cgi?id=467547#c8 and the patch is at https://github.com/sddm/sddm/pull/1701

With sddm-0.19.0^git20230403.67b8e4c-1.fc38.x86_64 I wasn't able to reproduce the issue. On the other hand, the race condition gods do not favor me today, even without the patch I had to try ~10 times before encountering the bug. So the fact that I couldn't reproduce the bug with the update installed doesn't necessarily mean it's fixed. Still, I'd say it's definitely a good idea to create a proper update for Fedora with this fix included.

I will need to bundle it with the Plasma 5.27.4 update since I need to tweak plasma-workspace with it, but I'll get that updated momentarily.

FEDORA-2023-abaf931474 has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2023-abaf931474

FEDORA-2023-a430641dce has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2023-a430641dce

FEDORA-2023-abaf931474 has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2023-abaf931474

(In reply to Fedora Update System from comment #47)
> FEDORA-2023-abaf931474 has been submitted as an update to Fedora 38.
> https://bodhi.fedoraproject.org/updates/FEDORA-2023-abaf931474

I can't reproduce the issue with this update.

FEDORA-2023-abaf931474 has been pushed to the Fedora 38 testing repository.

You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-abaf931474

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2023-a430641dce has been pushed to the Fedora 37 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-a430641dce`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-a430641dce

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2023-abaf931474 has been pushed to the Fedora 38 stable repository.
If problem still persists, please make note of it in this bug report.