Bug 62786 - PRINTING: Allow click to enter page range field
Summary: PRINTING: Allow click to enter page range field
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
(earliest affected) rc
Hardware: All All
: low enhancement
Assignee: Not Assigned
Depends on:
Blocks: Print-Dialog
  Show dependency treegraph
Reported: 2013-03-26 23:47 UTC by Jared
Modified: 2018-12-14 14:11 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Note You need to log in before you can comment on or make changes to this bug.
Description Jared 2013-03-26 23:47:58 UTC
Problem description: Two clicks are required to enter a page range in the Print dialog

Steps to reproduce:
1. Menu:File->Print...
2. In Print dialog box click the Print radio button
3. Tab over or click over to enter the range

Current behavior: Two clicks necessary

Expected behavior: To be able to click into the grayed-out range area directly (activating that option) would allow for a quicker process.
i.e. if one were to click into that range the system could assume that both a range is being requests and that a print range selection is desired rather than the "All" option.

Operating System: Windows 8
Version: rc
Comment 1 Jorendc 2013-04-08 19:46:57 UTC
Thanks for your enhancement request. This'll be indeed an improvement. Therefore I mark this as NEW.

For the developer who'll work on this issue, it should be worth it to contact UX-advice for their opinion.

Kind regards,
Comment 2 Jared 2013-05-03 15:16:21 UTC
If this is accepted it would be great to see this across more areas in LibreOffice that are similar to this.
e.g. File->Export as PDF->Pages [range clickable]
Comment 3 Joel Madero 2014-02-27 23:03:33 UTC
In order to limit the confusion between ProposedEasyHack and EasyHack and to make queries much easier we are changing ProposedEasyHack to NeedsDevEval.

Thank you and apologies for the noise
Comment 4 Robinson Tryon (qubit) 2015-12-13 11:21:12 UTC Comment hidden (obsolete)
Comment 5 Jared 2017-07-26 16:14:23 UTC
Bump: to see if this will still be considered. 
Running (x64) on Windows currently.
Comment 6 Jared 2018-02-20 16:51:16 UTC
I still would love to see this considered. I don't see a change in UI on
Comment 7 Roman Kuznetsov 2018-12-12 18:19:06 UTC
I think this enhacement is wontfix, because we can't activize field by click in GUI.
Comment 8 Heiko Tietze 2018-12-13 09:06:11 UTC
It's not only impossible with standard controls but also bad usability. You might have seen the pattern to click on a disabled control and it magically accepts the focus on the web. Besides standard controls don't allow this as Roman wrote in c7, the drawback is a) it's not discoverable for the user, and b) you loose the important information of being disabled for a good reason.
Comment 9 Jared 2018-12-14 14:11:42 UTC
I would contend this UX is widely used (ala Chrome print dialog). I understand the forced-disabled field requires a double confirmation from the user, but as other platform UX adapt I would like to see this considered also.