I suffer the same problem on gentoo.

Operating System: Gentoo Linux 2.8
KDE Plasma Version: 5.23.5
KDE Frameworks Version: 5.90.0
Qt Version: 5.15.2
Kernel Version: 5.16.0-gentoo (64-bit)
Graphics Platform: Wayland
Processors: 16 × AMD Ryzen 7 2700X Eight-Core Processor
Memory: 31.4 GiB of RAM
Graphics Processor: NVIDIA GeForce GTX 1660 Ti/PCIe/SSE2

dupe of 429211?

Don't think this is a dupe of bug 429211. That bug specifically states that functionality is restored after some interaction.
In this case no amount of interaction restores functionality other than replacing the shell with plasmashell --replace.

I can reproduce with current git master on Wayland. What I see is that it visually freezes, but actually remains interactive. Clicking on things works, but the panel doesn't visually update as it usually does. We are getting lots of reports of this.

Since you're on 5.23.5, it doesn't seem to be a regression somewhere in Plasma itself. Possible an issue with a recently-backported Qt patch, or Mesa, or the kernel.

FWIW I also have an Intel UHD Graphics 620 GPU.

*** Bug 449202 has been marked as a duplicate of this bug. ***

Same issue on Fedora 35.

Operating System: Fedora Linux 35
KDE Plasma Version: 5.23.4
KDE Frameworks Version: 5.89.0
Qt Version: 5.15.2
Kernel Version: 5.15.16-200.fc35.x86_64 (64-bit)
Graphics Platform: Wayland
Processors: 8 × 11th Gen Intel® Core™ i7-1195G7 @ 2.90GHz
Memory: 15.3 GiB of RAM
Graphics Processor: Mesa Intel® Xe Graphics

(In reply to Nate Graham from comment #4)
> What I see is that it
> visually freezes, but actually remains interactive. Clicking on things
> works, but the panel doesn't visually update as it usually does. We are
> getting lots of reports of this.

Not exactly this. Sometimes interactivity remains; on taskbar, for example, sometimes you can't switch to another window by clicking its placeholder in taskbar. On the clock, it doesn't even show a tooltip on hover. So, not much interactivitty.

(In reply to Nate Graham from comment #4)

> Since you're on 5.23.5, it doesn't seem to be a regression somewhere in
> Plasma itself. Possible an issue with a recently-backported Qt patch, or
> Mesa, or the kernel.

Found this on the Slackware changelog:

> l/qt5-5.15.3_20211130_014c375b-x86_64-2.txz: Rebuilt.
>       Applied upstream patch:
>       [PATCH] Move the wayland socket polling to a separate event thread.

So this might be a culprit, perhaps.

Seems like this is similar issue I had - Bug 448844. Excluding the crashing behavior when doing `plasmashell --replace`, everything sounds similar.

*** Bug 448844 has been marked as a duplicate of this bug. ***

(In reply to atosser from comment #1)
> I suffer the same problem on gentoo.

You can downgrade to stable qtwayland in Gentoo.

(In reply to Andreas Sturmlechner from comment #11)
> (In reply to atosser from comment #1)
> > I suffer the same problem on gentoo.
> 
> You can downgrade to stable qtwayland in Gentoo.

That is not an option as without this patch wayland is completely useless on Nvidia hardware.

This issue has occurred several times for me after upgrading the qt5-wayland package in Arch Linux from 5.15.2+kde+r41-1 to 5.15.2+kde+r44-1. A few days ago I downgraded qt5-wayland back to r41 and it hasn't happened since, until I updated it to r45 (currently the latest available version), then the issue came back.

Looking at the updated Arch PKGBUILD[1] I see that the difference between r41 and r44 is three commits, all of which come from this MR: https://invent.kde.org/qt/qt/qtwayland/-/merge_requests/24

[1]: https://github.com/archlinux/svntogit-packages/commit/844d032fa6a64d8c6ecb1e785105d2807d1b1193#diff-3e341d2d9c67be01819b25b25d5e53ea3cdf3a38d28846cda85a195eb9b7203a

System information just in case:

Operating System: Arch Linux
KDE Plasma Version: 5.23.5
KDE Frameworks Version: 5.90.0
Qt Version: 5.15.2
Kernel Version: 5.16.2-arch1-1 (64-bit)
Graphics Platform: Wayland
Processors: 8 × Intel® Core™ i7-6700HQ CPU @ 2.60GHz
Memory: 15.5 GiB of RAM
Graphics Processor: Mesa Intel® HD Graphics 530

It's not exactly the same as Bug 429211, but the root cause will be the same.

*** This bug has been marked as a duplicate of bug 429211 ***

(In reply to Nate Graham from comment #14)
> It's not exactly the same as Bug 429211, but the root cause will be the same.
> 
> *** This bug has been marked as a duplicate of bug 429211 ***

Let's hope so. Thanks Nate!

(In reply to Nate Graham from comment #14)
> It's not exactly the same as Bug 429211, but the root cause will be the same.

This is about a regression caused by https://invent.kde.org/qt/qt/qtwayland/-/merge_requests/24, but bug 429211 is about X11, so definitely unrelated. Reopening.

A possible fix is under review upstream: https://codereview.qt-project.org/c/qt/qtwayland/+/393273

*** Bug 449323 has been marked as a duplicate of this bug. ***

*** Bug 449202 has been marked as a duplicate of this bug. ***

*** Bug 449021 has been marked as a duplicate of this bug. ***

*** Bug 448878 has been marked as a duplicate of this bug. ***

*** Bug 448844 has been marked as a duplicate of this bug. ***

I commented under #429211 because I thought I was affected by that, but I that was since turned into X11-specific, and I'm on Wayland.

This is happening on basically an hourly basis. Seeing the wrong (sometimes by a lot) time in the corner is really inconvenient sometimes.
Also, the fact that restarting plasmashell to fix this, sometimes also kills Firefox and/or Discord, which is a whole another issue, I imagine.

(In reply to torokati44 from comment #23)
> I commented under #429211 because I thought I was affected by that, but I
> that was since turned into X11-specific, and I'm on Wayland.
> 
> This is happening on basically an hourly basis. Seeing the wrong (sometimes
> by a lot) time in the corner is really inconvenient sometimes.
> Also, the fact that restarting plasmashell to fix this, sometimes also kills
> Firefox and/or Discord, which is a whole another issue, I imagine.

It may be happening on an hourly basis (haven't noticed), but there is no need for Plasma to be active for an hour for the issue to happen. That is, i once restarted Plasma because of this issue and it was only a matter of few minutes until it freezed again. That said, i did not restart Plasma immediately, so it might have been an hour since it froze.

Can any of you try to apply this patch to Qt 5.15 and check if the issue persists? It seems to fix the problem for me but I can just be lucky.

FYI, the patch is the same thing mentioned in #17 backported to apply to kde/5.15 branch of qtwayland

diff --git a/src/client/qwaylandwindow.cpp b/src/client/qwaylandwindow.cpp
index 4c5711a0..76a448e6 100644
--- a/src/client/qwaylandwindow.cpp
+++ b/src/client/qwaylandwindow.cpp
@@ -648,27 +648,20 @@ void QWaylandWindow::handleFrameCallback()
     mFrameCallbackElapsedTimer.invalidate();
 
     // The rest can wait until we can run it on the correct thread
-    if (!mWaitingForUpdateDelivery) {
-        auto doHandleExpose = [this]() {
-            bool wasExposed = isExposed();
-            mFrameCallbackTimedOut = false;
-            if (!wasExposed && isExposed()) // Did setting mFrameCallbackTimedOut make the window exposed?
-                sendExposeEvent(QRect(QPoint(), geometry().size()));
-            if (wasExposed && hasPendingUpdateRequest())
-                deliverUpdateRequest();
-
-            mWaitingForUpdateDelivery = false;
-        };
-
-        // Queued connection, to make sure we don't call handleUpdate() from inside waitForFrameSync()
-        // in the single-threaded case.
-        mWaitingForUpdateDelivery = true;
-        QMetaObject::invokeMethod(this, doHandleExpose, Qt::QueuedConnection);
-    }
+    QMetaObject::invokeMethod(this, &QWaylandWindow::doHandleFrameCallback, Qt::QueuedConnection);
 
     mFrameSyncWait.notify_all();
 }
 
+void QWaylandWindow::doHandleFrameCallback() {
+    bool wasExposed = isExposed();
+    mFrameCallbackTimedOut = false;
+    if (!wasExposed && isExposed()) // Did setting mFrameCallbackTimedOut make the window exposed?
+       sendExposeEvent(QRect(QPoint(), geometry().size()));
+    if (wasExposed && hasPendingUpdateRequest())
+       deliverUpdateRequest();
+}
+
 bool QWaylandWindow::waitForFrameSync(int timeout)
 {
     QMutexLocker locker(&mFrameSyncMutex);
diff --git a/src/client/qwaylandwindow_p.h b/src/client/qwaylandwindow_p.h
index d45980a8..f31d3fcb 100644
--- a/src/client/qwaylandwindow_p.h
+++ b/src/client/qwaylandwindow_p.h
@@ -228,7 +228,6 @@ protected:
     WId mWindowId;
     bool mWaitingForFrameCallback = false;
     bool mFrameCallbackTimedOut = false; // Whether the frame callback has timed out
-    bool mWaitingForUpdateDelivery = false;
     int mFrameCallbackCheckIntervalTimerId = -1;
     QElapsedTimer mFrameCallbackElapsedTimer;
     struct ::wl_callback *mFrameCallback = nullptr;
@@ -285,6 +284,7 @@ private:
 
     static const wl_callback_listener callbackListener;
     void handleFrameCallback();
+    void doHandleFrameCallback();
 
     static QWaylandWindow *mMouseGrab;
 
-- 
2.35.1

A possibly relevant merge request was started @ https://invent.kde.org/qt/qt/qtwayland/-/merge_requests/34

(In reply to madcatx from comment #25)
> Can any of you try to apply this patch to Qt 5.15 and check if the issue
> persists? It seems to fix the problem for me but I can just be lucky.

There are two more fixes pending upstream: https://codereview.qt-project.org/c/qt/qtwayland/+/393828/1
and https://codereview.qt-project.org/c/qt/qtwayland/+/393826/1.

I made a (draft) MR with all three on https://invent.kde.org/qt/qt/qtwayland/-/merge_requests/34. Would be good to know whether anyone still has the issue with those fixes applied.

Brilliant, MR applied! I'll report back if I run into anything.

(In reply to Fabian Vogt from comment #27)
> Would be good to
> know whether anyone still has the issue with those fixes applied.

I've applied your patches and rebuilt the component. I'll let you know if I still run into any problem. Thank you for your work.

> I made a (draft) MR with all three on
> https://invent.kde.org/qt/qt/qtwayland/-/merge_requests/34. Would be good to
> know whether anyone still has the issue with those fixes applied.

I have been running this patch since you posted it. It does seem to correct the issues with the panel. I don't notice any obvious regressions. However, needle meet haystack.

I've also been running the MR and so far so good.

Same problem with Plasma 5.34 on Arch Linux.

Operating System: Arch Linux
KDE Plasma Version: 5.24.0
KDE Frameworks Version: 5.90.0
Qt Version: 5.15.2
Graphics Platform: Wayland

Since https://codereview.qt-project.org/c/qt/qtwayland/+/393273 was backported to KDE's qt patch collection, this bug report can be closed now.

*** Bug 449825 has been marked as a duplicate of this bug. ***

It's NOT originally a Wayland bug but has been happening since KDE Plasma 4 started, and into Plasma 5.  The panel used to stay frozen for as long as a half-hour or hour until I maybe killed plasmashell or KDE.  Sometimes it worked to restart/fork plasmashell in a screen session in a xterm.  Now it might still sort of work except your minimized system tray programs won't reappear there, only on taskbar (and some in background, have to kill them) which will no longer be in the order you moved programs to.
          This bug for the last 10 or 12+ years is why I initially switched back to KDE3.5 for a few major versions of Slackware until KDE3.5  stopped working, then tried to switch to TDE KDE3.5 fork and simpler (less power-hungry, even though I don't use many effects) desktop environments and still will try to switch.  I still love KDE and will report bugs, but I haven't seen the panel freeze bug ever stop.  Sometimes at the same time, some/most/all other things stop responding too.
        People suggested turn off indexing, which I did, which didn't improve situation.  If I leave KDE on for days the panel is probably bound to stop responding.  One thing that did seem to exacerbate it is if I start 10 or 15+ GUI programs immediately on starting KDE, which sometimes permanently slowed it down.  If I start one program then another after a minute or two or after disc activity died down (though my OS is on SSD, /home is on HDD) and continue in that fashion, usually it doesn't slow down.  The thing is, even if I start 15+ programs at once, it might just be 10% CPU resources of my 32 threads is even being used, so the parallel processing might need to improve (unless that situation is only a HDD access problem.)

Updating to qt5-qtwayland-5.15.2-18.fc35 fixed these freezes for me. Thanks a bunch! ^^

(In reply to David Chmelik from comment #35)
> It's NOT originally a Wayland bug but has been happening since KDE Plasma 4
> started, and into Plasma 5.  The panel used to stay frozen for as long as a
> half-hour or hour until I maybe killed plasmashell or KDE.  Sometimes it
> worked to restart/fork plasmashell in a screen session in a xterm.  Now it
> might still sort of work except your minimized system tray programs won't
> reappear there, only on taskbar (and some in background, have to kill them)
> which will no longer be in the order you moved programs to.
>           This bug for the last 10 or 12+ years is why I initially switched
> back to KDE3.5 for a few major versions of Slackware until KDE3.5  stopped
> working, then tried to switch to TDE KDE3.5 fork and simpler (less
> power-hungry, even though I don't use many effects) desktop environments and
> still will try to switch.  I still love KDE and will report bugs, but I
> haven't seen the panel freeze bug ever stop.  Sometimes at the same time,
> some/most/all other things stop responding too.
>         People suggested turn off indexing, which I did, which didn't
> improve situation.  If I leave KDE on for days the panel is probably bound
> to stop responding.  

There are a lot of other possible causes for a process to freeze like Plasma.

For this bug, we addressed one of the causes we could precisely identify.

> One thing that did seem to exacerbate it is if I start
> 10 or 15+ GUI programs immediately on starting KDE, which sometimes
> permanently slowed it down.  If I start one program then another after a
> minute or two or after disc activity died down (though my OS is on SSD,
> /home is on HDD) and continue in that fashion, usually it doesn't slow down.
> The thing is, even if I start 15+ programs at once, it might just be 10% CPU
> resources of my 32 threads is even being used, so the parallel processing
> might need to improve (unless that situation is only a HDD access problem.)

You are describing a Xorg bug and contention due its protocol design. (If you run a recent distro did you compare with wayland?)
Or at least a different issue. 
We need bugs reports to be focused on a single issue or they become unmanageable.
Feel free to open new bugs or find those that correspond more closely to your symptoms.
Maybe one of the duplicates was wrongfully marked to duplicate this one, then comment on the duplicated one.

I'm having the exactly same symptoms right now, I'm not sure the issue was resolved.

Operating System: Manjaro Linux
KDE Plasma Version: 5.25.2
KDE Frameworks Version: 5.95.0
Qt Version: 5.15.5
Kernel Version: 5.15.52-1-MANJARO (64-bit)
Graphics Platform: Wayland
Processors: 12 × AMD Ryzen 5 3600 6-Core Processor
Memory: 31.3 GiB of RAM
Graphics Processor: NVIDIA GeForce GTX 1660 SUPER/PCIe/SSE2

Still having this issue today, with the following package versions:

plasma-desktop 5.26.3-1
qt5-base 5.15.7+kde+r174-1
frameworkintegration 5.99.0-1
plasma-wayland-session 5.26.3-1
plasma-wayland-protocols 1.9.0-1
wayland-protocols 1.28-1
nvidia-dkms 520.56.06-2
linux60-tkg-bore 6.0.8-272

I'm still experiencing this issue as well. I can confirm the reports of the task bar visually freezing but remaining responsive to mouse inputs to a certain degree.

Operating System: KDE neon 5.26
KDE Plasma Version: 5.26.4
KDE Frameworks Version: 5.100.0
Qt Version: 5.15.7
Kernel Version: 5.15.0-56-generic (64-bit)
Graphics Platform: Wayland
Processors: 8 × Intel® Core™ i7-6700K CPU @ 4.60GHz
Memory: 31.3 GiB of RAM
Graphics Processor: NVIDIA GeForce GTX 1080/PCIe/SSE2
Manufacturer: Gigabyte Technology Co., Ltd.

I'm also affected by this issue. On a fresh startup, sometimes the system clock freezes until some movement with the mouse is made. Elements remain interactive.

Operating System: KDE neon 5.26
KDE Plasma Version: 5.26.5
KDE Frameworks Version: 5.101.0
Qt Version: 5.15.7
Kernel Version: 5.15.0-57-generic (64-bit)
Graphics Platform: Wayland
Processors: 16 × AMD Ryzen 7 5800X3D 8-Core Processor
Memory: 31.3 GiB of RAM
Graphics Processor: AMD Radeon RX 580 Series
Manufacturer: ASUS

That's a different issue caused by a recent regression in the AMD drivers: https://gitlab.freedesktop.org/mesa/mesa/-/issues/7624.

In general please file a new bug report instead of re-opening an old one that's marked as already fixed. Thanks!

I am also experiencing this bug, let me know if I can provide more info:

Operating System: Fedora Linux 37
KDE Plasma Version: 5.27.3
KDE Frameworks Version: 5.104.0
Qt Version: 5.15.8
Kernel Version: 6.2.8-200.fc37.x86_64 (64-bit)
Graphics Platform: Wayland
Processors: 16 × AMD Ryzen 7 5800X 8-Core Processor
Memory: 15.5 GiB of RAM
Graphics Processor: NVIDIA GeForce RTX 3080/PCIe/SSE2

I also found this https://www.reddit.com/r/kde/comments/10i1s81/plasma_526_panel_freezing_with_wayland_nvidia/, so I don't know if the culprit is KDE, Nvidia, Wayland, Firefox, or a combination of all these

Alright, so i think i've found what caused this problem in my case. I'm on Nobara Linux 37 (Plasma) with an Nvidia GPU. 
I was having the KDE panel always freeze after a certain amount of time as well as the steam client/games becoming unresponsive and crashing also. The solution posted here seems to have fixed it for me https://github.com/ValveSoftware/steam-for-linux/issues/9035#issuecomment-1401432123

(In reply to kde.5qfxr from comment #44)
> Alright, so i think i've found what caused this problem in my case. I'm on
> Nobara Linux 37 (Plasma) with an Nvidia GPU. 
> I was having the KDE panel always freeze after a certain amount of time as
> well as the steam client/games becoming unresponsive and crashing also. The
> solution posted here seems to have fixed it for me
> https://github.com/ValveSoftware/steam-for-linux/issues/9035#issuecomment-
> 1401432123

an update: steam client still crashes but the KDE panel at least seems to have stopped crashing

(In reply to kde.5qfxr from comment #44)
> Alright, so i think i've found what caused this problem in my case. I'm on
> Nobara Linux 37 (Plasma) with an Nvidia GPU. 
> I was having the KDE panel always freeze after a certain amount of time as
> well as the steam client/games becoming unresponsive and crashing also. The
> solution posted here seems to have fixed it for me
> https://github.com/ValveSoftware/steam-for-linux/issues/9035#issuecomment-
> 1401432123

This bug report is about plasma panels visually freezing, not crashing. Issue related to an out-of-memory condition would cause the whole plasma-desktop process to quit so the panel would disappear altogether. I don't believe that the Steam issue is relevant here.

Still occurring on siduction (Debian unstable) with Nvidia Wayland. Panel freezes optically (clock does not change), but interaction remains possible.

Created attachment 158356 [details]
Example of Replicating the Freezing Taskbar Defect

Comment on attachment 158356 [details]
Example of Replicating the Freezing Taskbar Defect

I can get this to happen almost 100%.

Mouse over the icon for Firefox, immediately click, and don't move the mouse while it opens. The taskbar will be frozen in the Firefox loading animation.

Sorry, here is my version information:

SOFTWARE/OS VERSIONS
Operating System: Gentoo Linux 2.13
KDE Plasma Version: 5.26.5
KDE Frameworks Version: 5.102.0
Qt Version: 5.15.8
Kernel Version: 6.1.19-gentoo--ZDY1ig-- (64-bit)
Graphics Platform: Wayland
Processors: 128 × AMD Ryzen Threadripper 3990X 64-Core Processor
Memory: 125.7 GiB of RAM
Graphics Processor: AMD Radeon RX 6950 XT
Manufacturer: ASUS

As mentioned earlier, please submit new bug reports rather than re-opening or adding info to an already-closed one. The symptoms may look similar or the same, but the root cause may be different. Thanks.

Sorry about that! I misunderstood the bug report.

While this issue has gotten more infrequent over the last monthish with regular bleeding edge updates, it still persists. Weirdly today it was acting strange before that, I would try to open dolphin by clicking a small icon next to my kde menu but it would minimize my running game of Final Fantasy XIV instead (hypothetically, and/or ACT as well) and while the panel is responsive, it has weird behavior sometimes and doesn't work as expected. Posting my system stats in case it helps, seems like this is happening to nvidia users overall (wayland problems in nvidia? whoda thunk?)

Operating System: Gentoo Linux 2.13
KDE Plasma Version: 5.27.5
KDE Frameworks Version: 5.106.0
Qt Version: 5.15.9
Kernel Version: 6.3.6-gentoo (64-bit)
Graphics Platform: Wayland
Processors: 32 × AMD Ryzen 9 7950X 16-Core Processor
Memory: 30.5 GiB of RAM
Graphics Processor: NVIDIA GeForce RTX 3080 Ti/PCIe/SSE2
Manufacturer: ASRock
Product Name: X670E Steel Legend

I'll add my participation to the pile. I'm having the same issue

Operating System: Arch Linux
KDE Plasma Version: 5.27.6
KDE Frameworks Version: 5.107.0
Qt Version: 5.15.10
Kernel Version: 6.3.8-arch1-1-bcachefs-git
Graphics Platform: Wayland
Processors: Intel Core i5-6600K
Graphics Card: GeForce GTX 1060 6GB

Also have this issue. Would like to note that going into Edit Mode and dragging the panel around (towards the side of the screen so it's forced to re-layout to vertical) fixes the issue for me.

Operating System: Arch Linux 
KDE Plasma Version: 5.27.6
KDE Frameworks Version: 5.108.0
Qt Version: 5.15.10
Kernel Version: 6.4.3-arch1-1 (64-bit)
Graphics Platform: Wayland
Processors: 8 × Intel® Core™ i7-7700K CPU @ 4.20GHz
Memory: 15.6 GiB of RAM
Graphics Processor: NVIDIA GeForce RTX 2060/PCIe/SSE2

No need to drag it around. Just change the height by one pixel and it starts working again

Not exactly sure if it is connected, but sometimes when using floating panel and have maximized window it stops maximizing with the window complete ignores it.

Operating System: EndeavourOS 
KDE Plasma Version: 5.27.6
KDE Frameworks Version: 5.108.0
Qt Version: 5.15.10
Kernel Version: 6.4.5-zen1-1-zen (64-bit)
Graphics Platform: Wayland
Processors: 16 × AMD Ryzen 7 5800X3D 8-Core Processor
Memory: 31,2 GiB of RAM
Graphics Processor: NVIDIA GeForce RTX 3090/PCIe/SSE2

I have the same issue with the frozen clock & panel.

Operating System: openSUSE Tumbleweed 20230724
KDE Plasma Version: 5.27.6
KDE Frameworks Version: 5.108.0
Qt Version: 5.15.10
Kernel Version: 6.4.4-1-default (64-bit)
Graphics Platform: Wayland
Processors: 16 × 11th Gen Intel® Core™ i9-11950H @ 2.60GHz
Memory: 31.1 GiB of RAM
Graphics Processor: NVIDIA RTX A3000 Laptop GPU/PCIe/SSE2
Manufacturer: LENOVO
Product Name: 20YQ000TGE
System Version: ThinkPad P15 Gen 2i

This bug very likely related to task manager. 
When I switched to `latte-task` (comes from latte-dock). Panel won't get frozen any more.

I also have this bug on arch & nvidia.

I also have this bug on arch nvidia.

I have this same bug in Arch Linux. 
inxi output:
System:
  Host: ruxtower Kernel: 6.5.0-1-cachyos arch: x86_64 bits: 64
    Desktop: KDE Plasma v: 5.27.7 Distro: Arch Linux
Memory:
  System RAM: total: 32 GiB available: 31.16 GiB used: 8.86 GiB (28.4%)
  Array-1: capacity: 128 GiB slots: 4 modules: 4 EC: None
  Device-1: Controller0-ChannelA-DIMM0 type: DDR4 size: 8 GiB
    speed: 3200 MT/s
  Device-2: Controller0-ChannelA-DIMM1 type: DDR4 size: 8 GiB
    speed: 3200 MT/s
  Device-3: Controller1-ChannelA-DIMM0 type: DDR4 size: 8 GiB
    speed: 3200 MT/s
  Device-4: Controller1-ChannelA-DIMM1 type: DDR4 size: 8 GiB
    speed: 3200 MT/s
Graphics:
  Device-1: NVIDIA GA106 [GeForce RTX 3060 Lite Hash Rate] driver: nvidia
    v: 535.104.05
  Device-2: Lenovo 500 RGB Camera driver: uvcvideo type: USB
  Display: server: X.Org v: 23.2 with: Xwayland v: 23.2.0 driver: X:
    loaded: nvidia unloaded: fbdev,modesetting,nouveau,vesa
    gpu: nvidia,nvidia-nvswitch resolution: 1: 1920x1080~60Hz
    2: 1920x1080~60Hz
  API: OpenGL v: 4.6.0 NVIDIA 535.104.05 renderer: NVIDIA GeForce RTX
    3060/PCIe/SSE2

I have also been experiencing this bug, and it seemed to be happening on its own after random time intervals but I managed to get it to happen consistently and immediately. It's possible this comment should be a new/separate bug with the same behavior, but I think it's very possible people are not actually doing NOTHING until the taskbar becomes unresponsive. I personally did not observe the taskbar freezing if I truly did nothing with the computer.

Providing additional steps to reproduce that may lead to a fix:

STEPS TO REPRODUCE
1. Boot into Plasma Desktop under Wayland.
2. Right click task manager -> Configure icons-only task manager -> Icons-only task manager settings -> Behavior.
3. Set "Group" to "by program name".
4. Enable "Mouse wheel cycles through tasks", apply if needed.
5. Open multiple windows of any one application that supports multiple windows (I tried this separately with Firefox, Dolphin, and Konsole).
6. Position the cursor over the icon in the icons-only task manager for that application.
7. Use the mouse wheel to cycle between open windows of that application.
8. Notice the unresponsiveness of the panel.

Using the mouse wheel to switch between open windows consistently and immediately (or within a few seconds) renders the panel unresponsive. Sometimes, changing the grouping or mouse wheel scroll settings in task manager settings and applying will also cause this behavior.

For me at least, this bug is tied directly to "mouse wheel: cycles through tasks" for programs "grouped: by program name" in the icons-only task manager. Using Latte-dock instead may be a temporary workaround for some.

Can anyone confirm if they were experiencing this bug when doing absolutely nothing at all, just leaving the computer idle for x amount of time? Are you also able to reproduce with the steps provided / is it applicable to you?

I would look into fixing this myself, but I'm not experienced with OS, Kernel, or Desktop development so it would take me a WHILE to find the source code, branch and parse through the source code, learn the appropriate language(s), set up a testing environment, fix it on my end, and push/request merge the fix. Hopefully this helps someone on the KDE team close this bug.

PS: please go easy on me, this is my first comment here so I might not know this specific group's standards.

RELATED NOTES
* Steps 2-4 may be default settings, which could also explain why the issue is so pervasive. 
* Scrolling just on the taskbar to cycle through all windows does not produce the result, it is only when hovering over a grouped icon which limits the cycle to a single application.
* Clicking to cycle also does NOT produce the result, only scrolling.
* I saw somewhere that it could be tied to virtual desktops or other widgets, but none were the case for me.
* Seems to be an issue across distros, KDE versions, AMD and Intel CPUs, and AMD and NVidia graphics cards.
* Linking a related Reddit thread with more people experiencing this issue. It does not have this insight, but has a good summary from KDE ruling things out: https://www.reddit.com/r/kde/comments/snhb2c/kde_panel_plasma_frozen_what_to_try/
* The task manager will generally still open a program if you click on the icon, even though visually it is unresponsive.

Since it's not listed here, I'm generally running the following command to reset the taskbar, which may have different behavior from `plasmashell --replace` but there seem to be variations of a similar thing:

```
systemctl --user restart plasma-plasmashell.service
```

ABOUT THIS SYSTEM
Operating System: openSUSE Tumbleweed 20230902
KDE Plasma Version: 5.27.7
KDE Frameworks Version: 5.109.0
Qt Version: 5.15.10
Kernel Version: 6.4.11-1-default (64-bit)
Graphics Platform: Wayland
Processors: 12 × AMD Ryzen 5 3600X 6-Core Processor
Memory: 15.5 GiB of RAM
Graphics Processor: NVIDIA GeForce RTX 2070 SUPER/PCIe/SSE2

(In reply to Robert from comment #63)
> I have also been experiencing this bug, and it seemed to be happening on its
> own after random time intervals but I managed to get it to happen
> consistently and immediately. It's possible this comment should be a
> new/separate bug with the same behavior, but I think it's very possible
> people are not actually doing NOTHING until the taskbar becomes
> unresponsive. I personally did not observe the taskbar freezing if I truly
> did nothing with the computer.
> 
> Providing additional steps to reproduce that may lead to a fix:
> 
> STEPS TO REPRODUCE
> 1. Boot into Plasma Desktop under Wayland.
> 2. Right click task manager -> Configure icons-only task manager ->
> Icons-only task manager settings -> Behavior.
> 3. Set "Group" to "by program name".
> 4. Enable "Mouse wheel cycles through tasks", apply if needed.
> 5. Open multiple windows of any one application that supports multiple
> windows (I tried this separately with Firefox, Dolphin, and Konsole).
> 6. Position the cursor over the icon in the icons-only task manager for that
> application.
> 7. Use the mouse wheel to cycle between open windows of that application.
> 8. Notice the unresponsiveness of the panel.
> 
> Using the mouse wheel to switch between open windows consistently and
> immediately (or within a few seconds) renders the panel unresponsive.
> Sometimes, changing the grouping or mouse wheel scroll settings in task
> manager settings and applying will also cause this behavior.
> 
> For me at least, this bug is tied directly to "mouse wheel: cycles through
> tasks" for programs "grouped: by program name" in the icons-only task
> manager. Using Latte-dock instead may be a temporary workaround for some.
> 
> Can anyone confirm if they were experiencing this bug when doing absolutely
> nothing at all, just leaving the computer idle for x amount of time? Are you
> also able to reproduce with the steps provided / is it applicable to you?
> 
> I would look into fixing this myself, but I'm not experienced with OS,
> Kernel, or Desktop development so it would take me a WHILE to find the
> source code, branch and parse through the source code, learn the appropriate
> language(s), set up a testing environment, fix it on my end, and
> push/request merge the fix. Hopefully this helps someone on the KDE team
> close this bug.
> 
> PS: please go easy on me, this is my first comment here so I might not know
> this specific group's standards.
> 
> RELATED NOTES
> * Steps 2-4 may be default settings, which could also explain why the issue
> is so pervasive. 
> * Scrolling just on the taskbar to cycle through all windows does not
> produce the result, it is only when hovering over a grouped icon which
> limits the cycle to a single application.
> * Clicking to cycle also does NOT produce the result, only scrolling.
> * I saw somewhere that it could be tied to virtual desktops or other
> widgets, but none were the case for me.
> * Seems to be an issue across distros, KDE versions, AMD and Intel CPUs, and
> AMD and NVidia graphics cards.
> * Linking a related Reddit thread with more people experiencing this issue.
> It does not have this insight, but has a good summary from KDE ruling things
> out:
> https://www.reddit.com/r/kde/comments/snhb2c/
> kde_panel_plasma_frozen_what_to_try/
> * The task manager will generally still open a program if you click on the
> icon, even though visually it is unresponsive.
> 
> Since it's not listed here, I'm generally running the following command to
> reset the taskbar, which may have different behavior from `plasmashell
> --replace` but there seem to be variations of a similar thing:
> 
> ```
> systemctl --user restart plasma-plasmashell.service
> ```
> 
> ABOUT THIS SYSTEM
> Operating System: openSUSE Tumbleweed 20230902
> KDE Plasma Version: 5.27.7
> KDE Frameworks Version: 5.109.0
> Qt Version: 5.15.10
> Kernel Version: 6.4.11-1-default (64-bit)
> Graphics Platform: Wayland
> Processors: 12 × AMD Ryzen 5 3600X 6-Core Processor
> Memory: 15.5 GiB of RAM
> Graphics Processor: NVIDIA GeForce RTX 2070 SUPER/PCIe/SSE2

I can also confirm this behavior. In my case however it DOES happen with ungrouped windows. In fact when testing it just now I didn't have any grouped windows in the task manager at all. Just hovering above any given window's icon in the task manager and scrolling will immediately freeze the panel for me like how it's described in the initial report. My task manager settings are however the same as yours otherwise.

Whether or not this is a separate issue I'm not sure, but at least it's a consistent repro of the effects of the original reported bug. I will say though that I never use the scroll wheel to switch between windows normally, and still experience the issue frequently. So it seems to be triggered by something else too, perhaps some other window switching/focus related action.

If you have an NVIDIA GPU, you're experiencing Bug 469016; please post comments there, not here.

(In reply to Nate Graham from comment #65)
> If you have an NVIDIA GPU, you're experiencing Bug 469016; please post
> comments there, not here.

I didn't see any indication that this bug is exclusive to AMD, and bug 469016 is not exclusive to NVIDIA either, but I'll follow up there.

Bug 469016 was reported as happening under "heavy load" and unhiding a hidden task bar, which is not applicable to me. That said, recent discussion tying it to window previews and pipewire is relevant. Going to Configure Icons-only Task Manager -> Appearance -> General -> and disabling "Show small window previews when hovering over tasks" prevents the issues for me.

(In reply to Robert Svensson from comment #64)
> I can also confirm this behavior. In my case however it DOES happen with ungrouped windows. In fact when testing it just now I didn't have any grouped windows in the task manager at all. Just hovering above any given window's icon in the task manager and scrolling will immediately freeze the panel for me like how it's described in the initial report. My task manager settings are however the same as yours otherwise.
>
> Whether or not this is a separate issue I'm not sure, but at least it's a consistent repro of the effects of the original reported bug. I will say though that I never use the scroll wheel to switch between windows normally, and still experience the issue frequently. So it seems to be triggered by something else too, perhaps some other window switching/focus related action.

I didn't experience it without grouped windows, but scrolling even with the scroll setting disabled still causes it unless "Show small window previews when hovering over tasks" is disabled. Disabling window previews prevents the issue for me, although this workflow is not ideal. Maybe the root cause is the same for both, maybe not, but hopefully this at least points some people in the right direction.

> I didn't see any indication that this bug is exclusive to AMD, and bug
> 469016 is not exclusive to NVIDIA either, but I'll follow up there.

For me, it actually seems related to NVIDIA, I was having this issue with my 1660s all the time, after I switched to my 6700XT without changing any other component the issue was gone, with the same setup, on manjaro, using the classic task manager ungrouped.