Bug 160824 - Print dialogue's "Number of copies" field is scrollable and focused by default, leading to excess copies being printed on accident
Summary: Print dialogue's "Number of copies" field is scrollable and focused by defaul...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
7.2.0.4 release
Hardware: All All
: medium enhancement
Assignee: Michael Weghorn
URL:
Whiteboard: target:24.8.0
Keywords:
Depends on:
Blocks: Print-Dialog
  Show dependency treegraph
 
Reported: 2024-04-25 23:12 UTC by MT
Modified: 2024-05-15 08:01 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
screenshot of Firefox print dialog showing number of sheets of paper to be printed (42.75 KB, image/png)
2024-05-15 08:00 UTC, Stéphane Guillou (stragu)
Details

Note You need to log in before you can comment on or make changes to this bug.
Description MT 2024-04-25 23:12:31 UTC
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
Comment 1 Stéphane Guillou (stragu) 2024-05-13 04:15:43 UTC
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"?
Comment 2 Heiko Tietze 2024-05-13 07:47:40 UTC
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.
Comment 3 Heiko Tietze 2024-05-13 07:50:45 UTC
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?
Comment 4 Caolán McNamara 2024-05-13 08:00:10 UTC
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
Comment 5 Michael Weghorn 2024-05-13 14:40:59 UTC
(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.
Comment 6 Commit Notification 2024-05-14 05:26:43 UTC
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.
Comment 7 Caolán McNamara 2024-05-14 07:23:46 UTC
"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
Comment 8 Heiko Tietze 2024-05-14 08:04:22 UTC
(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.
Comment 9 Michael Weghorn 2024-05-14 08:48:23 UTC
(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?
Comment 10 Caolán McNamara 2024-05-14 11:13:43 UTC
"Is that the same for you", yeah scroll wheel only changes the value when the mouse is over the spinbutton (in gtk3)
Comment 11 Michael Weghorn 2024-05-15 06:49:03 UTC
(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 .)
Comment 12 Heiko Tietze 2024-05-15 07:17:06 UTC
(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.
Comment 13 Michael Weghorn 2024-05-15 07:46:45 UTC
(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. :)
Comment 14 Stéphane Guillou (stragu) 2024-05-15 08:00:48 UTC
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.