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)
(In reply to Caolán McNamara from comment #10) > "Is that the same for you", yeah scroll wheel only changes the value when > the mouse is over the spinbutton (in gtk3) Great, thanks! (In reply to Stéphane Guillou (stragu) from comment #1) > 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. Regardless of the scroll behavior of the spinbox (fixed now), I'd suggest to change initial focus to the "Printer" combobox at the top of the dialog, which to me seems more logical and also better for accessibility: Tabbing from top to bottom in the visual order is more logical than starting somewhere in the middle of the dialog and having to Shift+Tab to get up to the printer first. (And some controls in the dialog like the page size change dependent on the printer selection, so the printer should really be selected first.) Note that initial focus on the "Number of copies" spinbox was previously implemented in the context of tdf#34641 (as OpenOffice.org also used to do this), but I personally agree with bug 34641 comment 1: > If no arguments will be found against this, I would prefer to open print dialog with focus on printer selection as in other programs. > I agree, start focus on "No of copies" might be useful, but I would prefer consistence. Any thoughts on that? (Changing that would be easy, just replacing the `mxCopyCountField->grab_focus();` in `PrintDialog::PrintDialog` in vcl/source/window/printdlg.cxx .)
(In reply to Michael Weghorn from comment #11) > Regardless of the scroll behavior of the spinbox (fixed now), I'd suggest to > change initial focus to the "Printer" combobox at the top of the dialog... From the efficiency POV, the most relevant function should be in focus. And that's the number of copies: ctrl+P into the dialog, arrow up as many copies you like, and enter to run the action. Admittedly it's odd to start tabbing (or screen reading) in the middle of a dialog. IMO different topic.
(In reply to Heiko Tietze from comment #12) > From the efficiency POV, the most relevant function should be in focus. And > that's the number of copies: ctrl+P into the dialog, arrow up as many copies > you like, and enter to run the action. > > Admittedly it's odd to start tabbing (or screen reading) in the middle of a > dialog. > > IMO different topic. True. I've opened tdf#161082 so the UX team can follow up on that. :)
Created attachment 194123 [details] screenshot of Firefox print dialog showing number of sheets of paper to be printed To stay on the topic of "avoiding printing unwanted copies", I looked at Firefox and really like that it prominently says how many sheets of paper will come out (see attachment). I think having the same thing in our Print dialog, preferably close to the Print button, would likely avoid many such mishaps.