I submit this as a bug, because in my opinion should not be so. I will write briefly, the mouse wheel is treated as a click on the window. When I turn the mouse wheel on which any window, it becomes active. This is without clicking on the window, simply move the mouse wheel (to scroll up and down) is the same as using the left mouse button. And it should work so that the mouse wheel does not raise oknien or not working at the time when the area is not a place where you can scroll anything. At present time, use the mouse wheel: menus, buttons and terminal program or settings panel (where there is no scroll) - makes the program becomes active, or go to the front as the active window. It's click and mouse wheel (up - down) should raise the window is active. I report this as an error.
At least in 4.10.0 this is configurable with Window Manager Tweaks (xfwm4-tweaks-settings) "Accessibility/Raise windows when any mouse button is pressed", which is off by default. So it seems not to be a bug or fixed in 4.10.0. Though the option description should IMHO mention the mouse wheel is a button too.
(In reply to comment #1) > At least in 4.10.0 this is configurable with Window Manager Tweaks > (xfwm4-tweaks-settings) "Accessibility/Raise windows when any mouse button > is pressed", which is off by default. > > So it seems not to be a bug or fixed in 4.10.0. Though the option > description should IMHO mention the mouse wheel is a button too. No, this isn't a correct answer. The mouse wheel is not a button. Pressing it would be a button (mouse 3). Scrolling it should not be treated as a click, which is the bug. Mouse wheel should be ignored when user is in "click to focus" mode, because scrolling the wheel is not a button click.
To further clarify: If you disable that setting for "Raise when any pressed", then the window can no longer be focused using a click, only on the titlebar. It is a separate preference and not related to mouse wheel.
(In reply to comment #0) > I submit this as a bug, because in my opinion should not be so. > > I will write briefly, the mouse wheel is treated as a click on the window. > When I turn the mouse wheel on which any window, it becomes active. This is > without clicking on the window, simply move the mouse wheel (to scroll up > and down) is the same as using the left mouse button. > > And it should work so that the mouse wheel does not raise oknien or not > working at the time when the area is not a place where you can scroll > anything. > > At present time, use the mouse wheel: menus, buttons and terminal program or > settings panel (where there is no scroll) - makes the program becomes > active, or go to the front as the active window. > > It's click and mouse wheel (up - down) should raise the window is active. I > report this as an error. The mouse wheel is a button click, it's button 4/5. Using different actions depending on where the pointer is located, in scrollable area or not, is impossible as the context belongs to the application, whereas focusing/raising windows belongs to the window manager, so it's impossible for the window manager to decide based on what the app would do... Either you treat the button4/5 events as regular button events and raise/focus accordingly, or you don't, there is no in between solution. If my undertanding of your report is correct, this bug should be closed as invalid. Otherwise, please clarify.
(In reply to comment #3) > To further clarify: > > If you disable that setting for "Raise when any pressed", then the window > can no longer be focused using a click, only on the titlebar. It is a > separate preference and not related to mouse wheel. Hi Dan, The "Raise windows when any mouse button is pressed" in Manager Tweaks is an accessibility feature, isn't it? Standard "Click to focus" option is available in "Window Manager" settings. "Click to focus" enabled with "Raise windows when any mouse button is pressed" disabled works as excepted. Only left click (button 1) focuses the windows. I have encountered situations this configuration was not the default and I was forced to switch above options. Maybe it was my fault. I think the options behavior are correct, but maybe not default or maybe sometimes spontaneously changed? I am not sure. Cheers, Petr
Sic, actually the relevat option is "RAISE TO CLICK" in "Focus" tab in "Window Manager" settings, not the "click to focus" I have mentioned. The "Accessibility/Raise windows when any mouse button is pressed" just alters the behavior of "Raise to click" option.
Let me just state the behavior I hoped to see, which I think mariusz also meant, but anyway: Using "click to focus" mode, mouse wheel (mouse4/5) should not affect background windows or change focus. Mouse wheel input should continue to be seen by the window that is in focus. (For example MS Windows 7 works the way I described.) This allows, for example, holding the mouse outside the window while still using the mouse wheel to scroll (maybe app-dependent). Mouse wheel over a background window will not send events there. I don't see any options to make this happen. I'm not an X expert, I don't know if there is some limitation preventing this or if it's just xfwm. Currently, raise_with_any_button=FALSE prevents the background window from raising, but the background window still gets the mouse wheel input and scrolls. Cheers, Dan
I actually never wanted to use "raise with any button" option, so I will avoid commenting its functionality. Just one comment: the current behavior of the wheel (raising windows) sounds strange to me, but on the other side I think every reporter complaining about this had this enabled just by mistake. It should be commented by someone really needing this option, for whom the simple left click to raise windows is not sufficient. I feel this configuration should be either more specific, what buttons will raise the window, or moved to accessibility setting. I just turned it on unintentionally, while exploring XFCE settings, as I probably thought it should be obviously on. Maybe I missed the word "any". Therefore I find this option misleading because orphaned and separated from the related "click to raise". I have not expected such option to even exists :) And later, once I saw windows being raised while turning the mouse wheel over them, I thought it is a global behavior and therefore a bug - until I realized it was my fault by turning on the wrong option. Later I have found this bug report and just put my 2c. Unlike Dan, I expected the lowered window to scroll not the focused one, though. (In reply to comment #7) > Using "click to focus" mode, mouse wheel (mouse4/5) should not affect > background windows or change focus. Mouse wheel input should continue to be > seen by the window that is in focus. (For example MS Windows 7 works the way > I described.) This is another issue, right? If I understand, you want a global behavior, where windows without input focus won't get buttons 4/5 events, instead these will get back to the currently focused window? By the way, I blame this behavior for being the reason why so **many** Windows users don't know their mouse has a wheel that can be used for scrolling! Over and over again I have seen windows users hunting the scrollbar or attached arrows every time they wanted to scroll the page/list a line or two. The wheel behavior in Windows was always a nightmare, if it worked at all. But nowadays the mouse wheels seem to reliably work even in Windows, though users still don't use it for scrolling! I can speak about hundreds of them, and not only ordinary users. I personally take this behavior of MS Windows as a serious bug. It's very inconvenient to use the wheel in MS Windows. I mean, you cannot scroll merely anything before you focus the scrollable widget first - text areas, list, combos, sliders... And how to focus it with the mouse without having side effect? Doing this globally you will easily end with HUGE INCONSISTENCY and UNPREDICTABILITY of mouse actions, the same mess it is in Windows! Windows 8 including. Just the need to click inside any widget to get it focused before you are able to scroll, without knowing where to click to not alter anything - if the widget has no label, or extensive mouse moving if it has one. Inability to scroll anything without losing your current focused widget. Or the dilema of compromise: Either accept not being able to use mouse wheel on anything not focused - pager, volume indicator, screen edges, task bar, window titlebars etc, and there are also windows not accepting input focus at all; or lose the point of all of this, as your pointer may easily end on such window/place excluded from the rule. The most important point, I want to bring, is that you seem to want misuse pointer buttons. The mouse is a pointing device, each event of a pointer device is and should be passed to the window where its pointing and also contains coordinates of the event. No matter if you press a button or turn the wheel or just move the mouse. It informs about the POINTER event. The fact mouses have wheels does not make non-pointing device from them. Despite of my ignorance of X, it has another event type: KEYBOARD events. These don't have coordinates, and these are what you want. There are XF86XK_ScrollUp and XF86XK_ScrollDown keysyms. If you do not have wheel on the keybord, map them to other keys. Or if you really want, you may passively grab POINTER events on the root window generated by buttons 4/5 and return the event to the event queue if the event was over focused window or discard it and send XF86XK_ScrollUp/XF86XK_ScrollDown key events to the focused application. This could work. Should this be done by the window manager? Sending POINTER events back to the focused window will probably not work, the application will not probably scroll nothing. You can test this: focus scrollable area, move the mouse outside it but keep it inside focused window and turn the wheel - probably nothing will be happen and there wasn't WM involved, application (or toolkit) decided not to scroll, as they correctly handled the pointer events as POINTER events. Cheers, Petr
> Or if you really want, you may passively grab POINTER events on the root window > generated by buttons 4/5 and return the event to the event queue if the event > was over focused window or discard it and send > XF86XK_ScrollUp/XF86XK_ScrollDown key events to the focused application. This > could work. There is probably no need to send XF86XK_ScrollUp/XF86XK_ScrollDown to the focused window as it should have input focus already, so maybe putting this events to queue is enough. But I don't know much about X, just have read few chapters from http://www.x.org/releases/X11R7.6/doc/libX11/specs/libX11/libX11.html, this could be the way, though.
It seems applications I have tested do not handle XF86_ScrollUp / XF86_ScrollDown. Sorry, you might use Down/Up but this behave differently in many applications.
Thanks for the discussions and clarification on the report everyone. Olivier, I'll use the report so we remember the string describing this feature could be improved. Even now, apart from the fact that the feature applies to scrolling I'm not sure what else it does and why it applies specifically to the a11y settings. Leaving the bug unassigned as the Design SIG will probably get hold of it when other projects are completed.
See 4964's comments for a potential solution.
*** Bug 4964 has been marked as a duplicate of this bug. ***