Description: Wanted to print 2 pages. The print dialogue box automatically selects the number of copies box which is then scrollable to enormous quantities by accident. When I got to the printer it was printing hundreds of copies of my document instead of 1. Please don't make the number of copies box scrollable from the mousepad. Steps to Reproduce: 1. Ctrl + P on a document 2.Scroll on track pad 3.Press enter and way too many copies print Actual Results: printed one hundred pages of a document that was sensitive and needed shredding in lots of 4 through the shredder. Expected Results: Print 2 pages once only Reproducible: Always User Profile Reset: No Additional Info: [Information automatically included from LibreOffice] Locale: en-GB Module: DrawingDocument [Information guessed from browser] OS: Windows (All) OS is 64bit: no
I agree that it can lead to very problematic results, and I doubt anyone relies on the scrollability of this field to assign a value (too fiddly when we know exactly what value we want to assign). This kind of interaction might make sense for e.g. a value that auto-updates a preview (e.g. in the Character dialog), but not here. gtk3 VCL plugin does not allow changing the value by mouse scroll. gen and kf5 do, even with the pointer outside of the field, which is focused by default, as MT said. Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: ad1f0bdeac30fca1dc56a08803ef23f2aca4db05 CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: x11 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: CL threaded Also in 7.2.0.4. In 7.1.0.3, the field was not focused when opening the dialog, so it was less of a problem. Heiko, Caolán, thoughts? Are there other examples of making such a spinbox "unscrollable"?
IIRC we had similar reports in the past. The widget scrollability is controlled by the OS/DE and we cannot prevent it to happen. Ie. while both kf6 and win do scroll gtk3 does not. Maybe Caolan or Michael have an idea.
Michael fixed bug 158548 by blocking the scroll thingy for listboxes as long the cursor is not hovering over the control. Can we do the same for spin edits?
could put the initial focus in the "Print" button instead of the spinbutton, otherwise the scroll behavior is an upstream gtk thing that isn't really under our control
(In reply to Heiko Tietze from comment #3) > Michael fixed bug 158548 by blocking the scroll thingy for listboxes as long > the cursor is not hovering over the control. Can we do the same for spin > edits? Yes, we can: https://gerrit.libreoffice.org/c/core/+/167604 (In reply to Caolán McNamara from comment #4) > could put the initial focus in the "Print" button instead of the spinbutton, > otherwise the scroll behavior is an upstream gtk thing that isn't really > under our control In my test with gtk3, the value doesn't change on mouse-wheel regardless of focus, so the issue described here is only for non-GTK, i.e. the VCL SpinField implementation.
Michael Weghorn committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/869b88488ac443cc64943254064da20b0f361c56 tdf#160824 vcl: Require mouse over spinfield to mouse-wheel through values It will be available in 24.8.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.
"In my test with gtk3, the value doesn't change on mouse-wheel regardless of focus" Very odd, it does for me (with a real mouse and scroll wheel), presumably using this code: https://gitlab.gnome.org/GNOME/gtk/-/blob/gtk-3-24/gtk/gtkspinbutton.c#L1332