SUMMARY When clicking anywhere on the panel in Wayland session, nothing gets registered. Secondary and tertiary (right/middle) clicks do however work fine, as well as hover. The problem persists in edit mode too. No other part of the desktop seems to have trouble picking up on clicks though… STEPS TO REPRODUCE 1. Click panel in Wayland session OBSERVED RESULT Nothing happens EXPECTED RESULT Whatever you clicked on will perform its action (e.g. open the launcher, run application or open system tray) SOFTWARE Operating System: KDE neon 5.26 KDE Plasma Version: 5.26.2 KDE Frameworks Version: 5.99.0 Qt Version: 5.15.7 Nvidia driver version: 515.65.01 Graphics Platform: Wayland ADDITIONAL INFORMATION It's hard to show something not registering on a screen recording, so no attachment. Just imagine clicking on stuff in the panel and nothing happening. :^)
I found the cause of the issue: I use the window behavior setting Window Actions > Inactive Inner Window Actions > Left click: "Activate and raise". This is so that I don't inadvertently cause an action when I just want to bring the window forward. On Wayland this however means that the panel doesn't read clicks, because it will never truly be raised. I would not expect this setting to affect the panel anyways, but now I know it's the cause. Do with that what you will. :^)
Can confirm, thanks for the investigation!
(In reply to Gabriel from comment #1) > I found the cause of the issue: I use the window behavior setting Window > Actions > Inactive Inner Window Actions > Left click: "Activate and raise". > This is so that I don't inadvertently cause an action when I just want to > bring the window forward. > > On Wayland this however means that the panel doesn't read clicks, because it > will never truly be raised. I would not expect this setting to affect the > panel anyways, but now I know it's the cause. Do with that what you will. :^) I can confirm your finding also.
(In reply to Gabriel from comment #1) > I found the cause of the issue: I use the window behavior setting Window > Actions > Inactive Inner Window Actions > Left click: "Activate and raise". > This is so that I don't inadvertently cause an action when I just want to > bring the window forward. > > On Wayland this however means that the panel doesn't read clicks, because it > will never truly be raised. I would not expect this setting to affect the > panel anyways, but now I know it's the cause. Do with that what you will. :^) I can confirm it too. Same happens with right-click if I set "Activate and rise" to it Arch Linux 6.6.8 Plasma 5.27.10
This seems to be fixed with Plasma 6.
(In reply to Marco Rebhan from comment #5) > This seems to be fixed with Plasma 6. Well, almost. Panel's context menus seem to have focus state, they need to be clicked twice to use the menu entry.
Can confirm this, too. I would really like to use "Activate and raise" behavior for left click again. Fixing this would be greatly appreciated.
Yes, it would be good to see a fix. This bug stops me from switching to Wayland.
I too have this issue! Additionally, on Manjaro.... (be careful, it might be a down stream bug... I'm not sure yet), the activate setting in KCM means "activate and raise", while "activate and raise" means "activate" and... well basically all settings are screwed.
But I might be able to give some more useful information: It does register the clicks, as long, as the tool tips menu isn't shown. It seems to steal it's focus. And the new panel clone buttons are affected too
(In reply to Katalin Rebhan from comment #6) > (In reply to Marco Rebhan from comment #5) > > This seems to be fixed with Plasma 6. > > Well, almost. Panel's context menus seem to have focus state, they need to > be clicked twice to use the menu entry. For me, clicking twice doesn't work either... which setting did you have it set too?
*** This bug has been marked as a duplicate of bug 501457 ***
(In reply to Nate Graham from comment #12) > > *** This bug has been marked as a duplicate of bug 501457 *** Hi Nate, while those two Bugs _might_ be related (that's why I mentioned the broken menu in this bug in the first place). This bug is about item's not responding to clicks, while the other one is for Windows not getting raised. I can see that the commit with which the other report has been fixed but... it **doesn't** fix the click behavior for which this bug report is for. I am sorry for the confusion and will be more careful in the future. But this bug is definitely not fixed. I kindly ask for this report to stay open until it is
Bug 501457 is fixed in Plasma 6.4. Did you test with thr 6.4 beta or git master? If not, then you don't have the fix on your system.
🐛🧹 ⚠️ This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information, then set the bug status to REPORTED. If there is no change for at least 30 days, it will be automatically closed as RESOLVED WORKSFORME. For more information about our bug triaging procedures, please read https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging. Thank you for helping us make KDE software even better for everyone!
This bug still happens in 6.4 Beta 2. When hovering over any tray icon or other element until the tooltip appears, it won't register mouse clicks anymore. I'm sorry for the delay. I'm in the middle of moving and didn't get around to checking. (In reply to Nate Graham from comment #14) > Bug 501457 is fixed in Plasma 6.4. Did you test with thr 6.4 beta or git > master? If not, then you don't have the fix on your system. Again, as you've only changed the settings GUI and which selection applies which setting, I wouldn't expect it to affect this bug in the first place. As there isn't a possible value for that setting, that would describe this behavior on purpose (which could then be wrongly applied), it has to be a bug further down the line in the behavior logic itself. Either in the general click behavior, or in how those tooltips work/grab focus. Additional information: It no longer happens when attempting to clone a panel. This seems to suggest that it is more likely to be an issue with the tooltips, instead of the general click logic
Quoting myself from Bug 460961 Comment 3 because I think it's relevant here, and I wouldn't want these details to be missed: «Playing around with this a little more, I think I see what is happening. KWin *does* treat unfocusable windows differently in that it always passes clicks through to them even if "Inactive Inner Window Actions" for left-clicks is set to "Activate and raise." The difficulty is that the plasmashell panel is made focusable whenever it is displaying any popup window such as a tooltip or popup menu. Whenever it is in this "focusable but unfocused" state, left-clicking on it merely focuses on it but does not pass the click through to it. You can see this if you click on the launcher button to open the applications menu and then click on the launcher button again. The applications menu will not be hidden by your second click, as that click merely transfers focus from the popup menu back to the panel window. A third click on the launcher button will close the applications menu because that click is passed to the panel window since it is focusable and focused. Once the applications menu is closed, the panel window is made unfocusable again, and indeed focus transfers back to whatever window had the focus before you opened the applications menu.» Also, the problem is not specific to the Plasmashell panels. The problem in KWin's click-passing logic also affects other applications that display tooltips. From Bug 460961 Comment 2: «For instance, open a Dolphin window, right-click on the empty space in the files view, hover over Properties, wait for the tooltip to appear, and then click on Properties. Your click won't be passed to the context menu but instead will only cause the tooltip to be hidden.»
Can also confirm BUG existence on the 6.4 release. Operating System: Arch Linux KDE Plasma Version: 6.4.0 KDE Frameworks Version: 6.15.0 Qt Version: 6.9.1 Kernel Version: 6.15.3-arch1-1 (64-bit) Graphics Platform: Wayland OFF-TOPIC PS: About the info needed link: I'm in a loop with the cloudflare thing. I get the OK from the captcha, but then "https://community.kde.org" returns a 403 and sends me right back to it. So silly, driving away users to save cloudflare money. Just disable that option. :(
Also confirm Gabriel's workaround of "window action > inactive inner window action > left click", select anything with "pass click". Differently from gabriel, I had `Window Actions>left click = Activate` (because I have focus follow mouse, so it is impossible to click on a window that is not active, kinda of) Yet, moving the mouse to the panel doesn't move focus away from other window, so i am guessing there's a work around to not give focus to the panel"?
I think there's a chance this was just fixed in Plasma 6.4.1 with the change to fix Bug 506007; can anyone upgrade to 6.4.1 (it was released this Tuesday) and see? I can't reproduce it anymore myself, FWIW.
(In reply to Nate Graham from comment #20) > I think there's a chance this was just fixed in Plasma 6.4.1 with the change > to fix Bug 506007; can anyone upgrade to 6.4.1 (it was released this > Tuesday) and see? I can't reproduce it anymore myself, FWIW. I am on 6.4.1 (Garuda) This still affects me. I have raise and activate selected. When I click a window it will raise, active AND pass click - except for Firefox based browsers which only raise with clicking the titlebar. This I think is a different problem though.
(In reply to Nate Graham from comment #20) > I think there's a chance this was just fixed in Plasma 6.4.1 with the change > to fix Bug 506007; can anyone upgrade to 6.4.1 (it was released this > Tuesday) and see? I can't reproduce it anymore myself, FWIW. Since the latest beta fails to launch entirely for me... idk if it's fixed yet. I'll keep an eye on it though and report back as soon as I can test it. FIY: As the issue was in a confirmed state before it was closed by Nate, I have restored it to that state now. I hope that's ok.
(In reply to Nate Graham from comment #20) > I think there's a chance this was just fixed in Plasma 6.4.1 with the change > to fix Bug 506007; can anyone upgrade to 6.4.1 (it was released this > Tuesday) and see? I can't reproduce it anymore myself, FWIW. I'm now running Plasma 6.4.1 (with KDE Frameworks 6.15.0 and Qt 6.9.1), and there has been no change relative to this issue. The two easiest reproducers still fail: • Hover mouse cursor over launcher button in panel. Wait for tooltip to appear. Click mouse button. Nothing happens. • Right-click on a file or folder in Dolphin. Hover mouse cursor over "Properties." Wait for tooltip to appear. Click mouse button. Tooltip disappears, but "Properties" is not activated.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/7898
Git commit f73200def99d7511955c3c698b53832cd3bb9404 by Vlad Zahorodnii. Committed on 11/07/2025 at 09:19. Pushed by vladz into branch 'master'. Fix "activate and raise" action with panels With the "activate and raise" action, the window manager should activate and raise the window but not pass the click. If a window is focusable, then only the mouse press should be filtered out. If a window is not focusable, there is some sophisticated code to see whether the window is obstructed by any other window (because isActive() is always false for such windows so we need another way to determine whether it's the first click). If the window is obstructed, then no click will be passed but the action will still be performed, in other words, the window will be activated (noop) and raised. However, this breaks if a window has transients, which is the case with panels. We want the click to be passed along even though the window is covered by a child (it doesn't matter whether it accepts focus). Given that primarily only special surfaces don't accept focus, e.g. panels, and they are expected to receive clicks, the special stacking order code path can be replaced with a `return false;` statement. Which is also identical to the MouseActivate case. See also e8dad997fae98e3c0c40653667dd22a002747556 M +1 -20 src/window.cpp https://invent.kde.org/plasma/kwin/-/commit/f73200def99d7511955c3c698b53832cd3bb9404
Git commit 267fa4ece648dd1a5b4c65f8af34a84f20f428f3 by Vlad Zahorodnii. Committed on 11/07/2025 at 09:39. Pushed by vladz into branch 'Plasma/6.4'. Fix "activate and raise" action with panels With the "activate and raise" action, the window manager should activate and raise the window but not pass the click. If a window is focusable, then only the mouse press should be filtered out. If a window is not focusable, there is some sophisticated code to see whether the window is obstructed by any other window (because isActive() is always false for such windows so we need another way to determine whether it's the first click). If the window is obstructed, then no click will be passed but the action will still be performed, in other words, the window will be activated (noop) and raised. However, this breaks if a window has transients, which is the case with panels. We want the click to be passed along even though the window is covered by a child (it doesn't matter whether it accepts focus). Given that primarily only special surfaces don't accept focus, e.g. panels, and they are expected to receive clicks, the special stacking order code path can be replaced with a `return false;` statement. Which is also identical to the MouseActivate case. See also e8dad997fae98e3c0c40653667dd22a002747556 (cherry picked from commit f73200def99d7511955c3c698b53832cd3bb9404) Co-authored-by: Vlad Zahorodnii <vlad.zahorodnii@kde.org> M +1 -20 src/window.cpp https://invent.kde.org/plasma/kwin/-/commit/267fa4ece648dd1a5b4c65f8af34a84f20f428f3