| Summary: | Focus window under mouse pointer when using mouse extra button bindings | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | ulterno |
| Component: | input | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | REPORTED --- | ||
| Severity: | wishlist | CC: | cwo.kde, duha.bugs, kdedev, nate |
| Priority: | NOR | ||
| Version First Reported In: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
ulterno
2025-05-19 12:11:26 UTC
It's a bit hard for me to understand what the issue is; can you write specific steps to reproduce that indicate what issue you're having? See https://community.kde.org/Get_Involved/Issue_Reporting#Steps_to_Reproduce Thanks! STEPS TO REPRODUCE 0. System Settings -> Window Behaviour -> Focus -> Window Activation Policy = Click to Focus; Raise on Hover = disabled 0. System Settings -> Mouse -> Extra Mouse Buttons : Add a binding (Say, MouseExtraButton3) that does something relevant (Call it Event-A) to the Active Window - e.g. `F5` to refresh window in case of a web browser 1. Have 2 Windows (of any application or multiple applications that work with Event-A) open, side-by-side (say, window1 and window2) 2. Activate window1. 3. Move mouse pointer to window2 4. Click the MouseExtraButton3. OBSERVATION - Event-A occurs in window1 EXPECTATION - window2 gets activated with the "Click to Focus" rule - Event-A occurs in window2 It is to be noted that this might not be desirable for every binding and is better to be selected by the user on a per-binding basis. There is definitely an inconsistency here. When it's a built-in extra mouse button function like "Back" or "Forward", it behaves like requested here (minus the configurability) - if you click the "Back" mouse button on a browser window that does not have focus, that background window that you clicked receives the mouse press event, and goes back one page in the history. The window that has focus at that point is not affected. It doesn't seem consistent to do this for built-in extra mouse buttons, but not for custom-bound ones. > It doesn't seem consistent to do this for built-in extra mouse buttons, but not for custom-bound ones.
Yes. Since the custom bindings make it act like a keyboard key, it gets rid of all mouse button press events.
___
One can also check that out by:
1. adding a debug output in a widget's bool event (QEvent *event) override
and filter to remove the events (by QEvent::Type): Move, Show, Resize, Paint, HoverEvent, HoverMove, Enter, Leave
That way, the debug output will only show up for events occuring on mouse click (click and drag for all mouse buttons also works here)
2. trying out the "rebind"-ed button inside the widget.
Even if the window is in focus, the widget would normally not get that as a mouse event
I tried this out with a QScrollBar of a QTabWidget, because it doesn't have any keyboard events enabled, making it easier to determine
|