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
(In reply to Caolán McNamara from comment #7) > "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 Had the same result as Michael, kf6 does scroll, gtk3 doesn't. IIAM we both run KDE. With the patch in place kf6/gen/gtk3 scroll only when the pointer is over the control. Thanks for fixing this, Michael.
(In reply to Caolán McNamara from comment #7) > "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 Hm, indeed, same for me now when trying again, sorry for the confusion... The value *does* change for me with gtk3 when the spin button has focus and is hovered over, but not when it's not hovered over. (IIUC, this is the desired behavior and what the VCL one does now as well). Same behavior with either the Breeze theme (default on KDE Plasma) or with GTK_THEME=Adwaita . Is that the same for you or does the value even change when using the mouse-wheel without the spin button being hovered over?
"Is that the same for you", yeah scroll wheel only changes the value when the mouse is over the spinbutton (in gtk3)