SUMMARY The "Inactive Inner Window Actions" settings group (under Window Management -> Window Behavior -> Window Actions within the systemsettings utility) allows the user to configure what will happen when a mouse click or scroll-wheel action is applied over a window other than the one currently holding focus. In particular, selecting the "Activate and raise" option instead of "Activate, raise, and pass click" allows the user to change the focus by clicking anywhere within the inactive window, without risking accidentally performing some unintended action if the click happens to be over a control widget in that window (which may be partially obscured). There is a similar "Activate" option to shift only the input focus, without affecting the window arrangement. In current KDE releases the panel(s) and all of their nested widgets are treated as Inactive Windows for input passing purposes whenever any normal application window holds the focus, so panel widgets do not function as intended when one of these options is selected. For example, clicking on a task switcher widget opens a small preview pane of the selected application window, but does not immediately switch focus to that application until the user clicks again in the preview pane. The application launcher menu becomes practically inaccessible; clicking on its icon raises a tool tip explaining what the "Application Launcher" is supposed to do, but there's nowhere to send a second click to actually activate the menu system. I think this behavior is wrong (and likely surprising to many inexperienced users) because the Panel is conceptually (from a UX standpoint, not any internal technical detail) different from other applications. In the default Plasma configuration, the Panel is always-visible, with other windows normally precluded from overlapping it. It is supposed to offer at-a-glance information and one-click access to basic desktop functions, the latter of which goes away when inactive window clicks are not configured to a passed-through option. This reduces the utility of the Inactive Inner Window Actions options, which have a practical purpose but become much less attractive if the user might have to give up easy access (apart from keyboard shortcuts) to common features like the application launcher and task switcher. STEPS TO REPRODUCE 1. Open the KDE system settings utility. 2. Navigate to Window Management -> Window Behavior -> Window Actions. 3. Within the "Inactive Inner Window Actions" settings group, set the left-click action to "Activate" or "Activate and raise". 4. Click "Apply" on the settings panel. 5. Left-click on your application launcher button and observe that you cannot open the launcher menu. 6. Left-click on any task switcher button and observe that a preview pane pops up, but the focus and window order do not shift to the selected application. 7. Left-click on that preview pane to actually complete the switch (now a two-click process, which was previously one). 8. Left-click on other panel widgets (e.g. volume control, network status, etc.) and observe that they too are inaccessible, similar to the application launcher menu. 9. Restore the left-click Inactive Inner Window Action to "Activate, raise, and pass click" for the best Plasma experience. PROPOSAL When a mouse click event is received while the cursor is above a window of application class org.kde.plasmashell, always pass the click event through to that window, along with any other actions that may be configured in Inactive Inner Window Actions. Specifically, treat a selection of "Activate" as "Activate and pass click", and a selection of "Activate and raise" as "Activate, raise, and pass click". Optionally offer a checkbox on the Window Actions settings dialog to "Always pass through clicks to plasmashell windows" to control this behavior, with a default value of activated. Optionally, this new behavior could be restricted only to plasmashell windows specifically belonging to the panel (which would be sufficient to address all of the concerns raised in this issue), but it's unusual to have other plasmashell windows visible without holding the input focus, it seems reasonable to treat them similarly to the Panel, and simply filtering by application class permits a very straightforward implementation. EXPECTED RESULT Users concerned about inadvertently triggering an action in an inactive window can select the "Activate and raise" or "Activate" options without compromising their easy access to panel widgets. Additionally, novice users are no longer at risk of a single settings change inadvertently disabling mouse-click access to the launcher menu, volume control, etc. RELATED ISSUES https://bugs.kde.org/show_bug.cgi?id=443996 (Inner Window Actions -> "Activate and raise" [but not pass click] has no effect in focus-follows-mouse mode): this has no direct interdependence with my proposal, but indicates another use case for inhibiting click pass-through, and that the inactive inner window event options have likely not been thoroughly tested.
This is still there in 5.27.3. Setting the left click action to "activate and raise" causes clicking on the panel to never do anything, at least from the short test I did, making this option pretty much unusable. IMO this should be classified as a bug, not wishlist.
This problem exists in Plasma 6 as well. I don't like the proposed solution in Comment 0 because it is too specific to plasmashell. The problem is actually more general. 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. The common theme here appears to be tooltips. Maybe KWin needs to treat the parent window of a currently displayed tooltip as though it is an "active window" for the purpose of passing clicks through to it. However, I'm not sure this would work exactly right, as applications receive mouseover events even on inactive windows and can show a tooltip whose parent is an inactive window, and we wouldn't want to pass a click through to such an inactive window merely because it is currently displaying a tooltip. There appears already to be some kind of exceptional case implemented in KWin for unfocusable windows like the plasmashell panel, as without this exception it would be impossible ever to send left-clicks to the panel since it is always an unfocused window. The visibility of the tooltip seems to be voiding this exception.
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. CURRENT BEHAVIOR OF "Activate and raise" POLICY: • If clicked window is unfocusable, then raise and pass click. • If clicked window is focusable but unfocused, then activate and raise. • If clicked window is focusable and focused, then pass click. PROPOSED BEHAVIOR OF "Activate and raise" POLICY: Same as above but with one additional case: • If clicked window is focusable and is an ancestor of the focused window, then pass click.
(In reply to Marco Rebhan from comment #1) >IMO this should be classified as a bug, not wishlist. I agree, but I was concerned that if I marked it as a bug, some well-intended junior developer with a "let's prune the issue tracker" mentality would have closed it as "this is the documented behavior of Activate & Raise." Documented != intended. (In reply to Matt Whitlock from comment #3) > PROPOSED BEHAVIOR OF "Activate and raise" POLICY: > Same as above but with one additional case: > • If clicked window is focusable and is an ancestor of the focused window, > then pass click. Is that too general, though? In a multi-window application such as GIMP, when a toolbar window is focused, passing a click through to the main window may not be the intended behavior of a user who selected "Activate and Raise." Conceptually, the difference is between child windows that have interactable elements (such as a toolbar or dialog, especially windows with some kind of "Close" or "Dismiss" button), and those that do not (such as tooltips or preview panes). I think an Activate and Raise user probably expects switching out of the first case to be a deliberate process, but will be frustrated if he or she can't easily dismiss the latter. > 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 Do plasmashell and other applications displaying tooltips need to be marked focusable while doing so? Perhaps the right way to close up the state machine is simply not to mark windows as focusable merely because they raise a child. The original special-case logic (for passing clicks to unfocusable windows) is then sufficient.
(In reply to Brent Spillner from comment #4) > Is that too general, though? In a multi-window application such as GIMP, > when a toolbar window is focused, passing a click through to the main window > may not be the intended behavior of a user who selected "Activate and > Raise." That's a fair point. I don't know if the compositor has enough information to discriminate between child windows that are interactive and those that are not, other than by examining the focusable flag. Conceptually, tooltips and other pop-over windows should not be focusable since you're never supposed to interact with them, but I suspect they were implemented as focusable so that they could detect when they lose focus and hide themselves. Of course, ideally the parent widget would hide its associated pop-over whenever the parent window loses focus, but that's harder to implement and might miss some corner cases, leading to the dreaded stuck tooltip. > Do plasmashell and other applications displaying tooltips need to be marked > focusable while doing so? Perhaps the right way to close up the state > machine is simply not to mark windows as focusable merely because they raise > a child. I don't think the panel gets made focusable merely because it has a visible child window. I think it's an intentional flag change. It might be done this way so that it's possible to navigate the panel using the keyboard. That's important for accessibility. That said, I'm not sure why opening the applications menu (or a tray pop-up) by using the mouse should make the panel focusable. If the panel remained unfocusable, then the current click-passing logic would just work. However, that wouldn't solve the issue elsewhere, such as in the Dolphin context menu, where the context menu absolutely does need to be focusable so you can navigate the menu items using the keyboard.