Description: In case that user opens the properties pane (right side of application) and scroll in this pane using mouse scroll wheel, if the mouse pointer become on a number textbox it will change the value of textbox instead os scrolling Steps to Reproduce: 1. Open the properties pane at the right side of application 2. Place mouse pointer on a number textbox (Spacing, Indent, ...) or keep the mouse pointer in a place near a number textbox and start to scroll 3. Roll the scroll wheel on the mouse Actual Results: If pointer is on the textbox or during the scroll become on textbox, it start to change the value instead of scrolling Expected Results: It must scroll the pane no changing the values unintentionally. Reproducible: Always User Profile Reset: Yes Additional Info: Version: 7.3.4.2 Build ID: 30(Build:2) CPU threads: 4; OS: Linux 5.18; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
Created attachment 181097 [details] Properties pane
Personal opinion: it's feature, not a bug. I do like the current mouse over scroll behavior.. Lets ask the UX departement..
(In reply to Telesto from comment #2) > Personal opinion: it's feature, not a bug. I do like the current mouse over > scroll behavior.. > > Lets ask the UX departement.. Yes; It's not a feature bug (bacause of this reason I set to minor severity ;)) but because it can cause to changes formatting unintentionally, it can be a UX problem. Thanks for forwarding it to UX department.
If we have a scrollbox it makes sense to do the onwheel action without focus but for all other controls I agree that before changing the index of a dropdown, the value in a spinedit, etc. it has to become focused. Plus, when focused the cursor should also remain located over the control to avoid wheel action with the cursor somewhere else (as it's a matter of fact today for kf5 and gen but not gtk3). Caolan, is this a big effort?
Removing needsUXEval, spin box and dropdown values should be guarded for unintentional changes.
For gen I see we have: mnWheelBehavior = MouseWheelBehaviour::ALWAYS; and another possibility of MouseWheelBehaviour::FocusOnly apparently exists, so it's possible that changing that to mnWheelBehavior = MouseWheelBehaviour::FocusOnly; in vcl/source/app/settings.cxx would do the right thing, see https://gerrit.libreoffice.org/c/core/+/137271 For the gtk3 case (which is the original report) I think https://gerrit.libreoffice.org/c/core/+/137268 then would get our gtk spinbuttons to honor that setting, and so not change the spinbutton under the mouse unless the focus is in it. lets give this a go and see does it match expectations, if not rolling back the first commit will return to the current state.
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/e3f5bf99ab7b558d867449e7142c982d667fc2a0 tdf#149823 follow MouseWheelBehaviour for GtkSpinButton It will be available in 7.5.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/9659860c56164a3dade94714eabfdafdb90fd1c5 tdf#149823 default to MouseWheelBehaviour::FocusOnly It will be available in 7.5.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.