Bug 460961

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.