Bug Hunting Session
Bug 57174 - When Opening Any Dialog the First Value in the Dialog Should be Selected
Summary: When Opening Any Dialog the First Value in the Dialog Should be Selected
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
3.6.2.2 release
Hardware: All All
: high enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: difficultyBeginner, needsDevEval, topicUI
Depends on:
Blocks: Dialog
  Show dependency treegraph
 
Reported: 2012-11-16 05:07 UTC by Eric Harman
Modified: 2017-08-25 13:40 UTC (History)
10 users (show)

See Also:
Crash report or crash signature:


Attachments
Two screenshots comparing current situation with expected result (7.00 KB, image/png)
2016-10-10 15:27 UTC, Heiko Tietze
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Eric Harman 2012-11-16 05:07:05 UTC
When I bring up a dialog to change a value and the control with initial focus is a text box or spinner control the initial value is not selected. This forces me to either delete the initial value or select them so that when I type my new value they are replaced. If, on the other hand you tab between fields then they are selected. 

Contrast this (in Windows at least) with the File, Save as dialog (a standard windows dialog). Whatever default value is there (like "Untitled 1.odt") is selected to start with. If I wish to change it all I have to do is start typing and my new value will replace the old. 

This is really inefficient for people who access menus and dialogs using the keyboard. 

Examples of this are: 

Writer: Format, Paragraph
  The field with the focus is "Indent, Before text", but the current value there is not selected. 

Calc: Format, Row, Height
  The "height" field contains "0.l8" by default, but the value is not selected.
Comment 1 Joel Madero 2013-11-24 16:30:53 UTC
Hey Eric -
sorry this has taken so long to get an initial person to say something, but here I am :) So this is actually an enhancement request not a bug (things work as they were designed) but your suggestion is indeed much better. Also - appears like all OS's are affected (which makes sense)


Thank you for reporting this enhancement request! I can confirm that this is a valid enhancement request on:
Version: 4.2.0.0.alpha0+Build ID: 09a4c4d176ff97ab8ff4027af83a549991667baf
Date:   Sat Nov 16 20:32:43 2013 +0100 
Platform: Ubuntu Linux 13.04 x64
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + 
As I've been able to confirm the enhancement request I am marking as:

New (confirmed)
Enhancement
Highest - basically anyone ever going into a dialog would benefit from this

Keywords - 

Whiteboard Status - ProposedEasyHack

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + 
LibreOffice is powered by a team of volunteers, every bug is confirmed (triaged) by human beings who mostly give their time for free. We invite you to join our triaging by checking out this link:
https://wiki.documentfoundation.org/QA/BugTriage

There are also other ways to get involved including with marketing, UX, documentation, and of course developing -  http://www.libreoffice.org/get-help/mailing-lists/. 

Lastly, good bug reports help tremendously in making the process go smoother, please always provide reproducible steps (even if it seems easy) and attach any and all relevant material
Comment 2 Björn Michaelsen 2014-01-17 00:43:25 UTC Comment hidden (obsolete)
Comment 3 Joel Madero 2014-02-27 22:55:04 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 Katarina Behrens 2015-03-26 22:18:17 UTC
This bug has been fixed as a part of GSoC 2015 application process. While I would accept the code as non-trivial easy hack, thus a valid GSoC application (the candidate fixed the bug and demonstrated understanding of LibO code), I do question the validity of this bug. Here is why:

1. Sure, selecting (highlighting) the value  of a text|spin box makes it easier for the user to delete the value or input their own value. But some users might want to use the mouse and change the spin box value by clicking on spin buttons. Highlighting the value might become confusing for them. One man's bug is the other man's feature

2. What to do if there are more input fields in the dialog? Select the first one? Or some other one? What if it's not the one the user wants to change? (selecting multiple input fields is iirc not possible)

3. Finally, if we decide to select (hightlight) the values of input field(s) on opening the dialog, we should do it consistently in every LibO dialog and sidebar. 

UX team: any thoughts?
Comment 5 Heiko Tietze 2015-03-27 08:31:54 UTC
I'd say the most important control in a dialog should get the focus. Looking around for a reference at the Gnome HIG I found the following comment in /gtk/gtkdialog.c 

/* A far too tricky heuristic for getting the right initial
* focus widget if none was set. What we do is we focus the first
* widget in the tab chain, but if this results in the focus
* ending up on one of the response widgets _other_ than the
* default response, we focus the default response instead.
*
* Additionally, skip selectable labels when looking for the
* right initial focus widget.
*/

So the right way for LO is to focus the first control that can receive the focus, as suggested by Eric. And if the dialog is designed well the most important control is located top left (for LTR layout) and is the first in the tab sequence, e.g. initialization of the dialog.
Comment 6 Noel Grandin 2015-03-27 09:15:42 UTC
I like Heiko's suggestion.

Note that we already have a sortIntoBestTabTraversalOrder, so we should just be using the first widget which that method produces.

Any changes or fixes to the tab order should be done inside that method.
Comment 7 Robinson Tryon (qubit) 2015-12-13 10:57:59 UTC Comment hidden (obsolete)
Comment 8 Robinson Tryon (qubit) 2016-02-18 14:51:40 UTC Comment hidden (obsolete)
Comment 9 Regina Henschel 2016-03-17 13:56:00 UTC
Please make sure that this does not break the fix for bug 82784.
Comment 10 Eric Harman 2016-03-17 18:10:52 UTC
(In reply to Katarina Behrens from comment #4)
> This bug has been fixed as a part of GSoC 2015 application process. While I
> would accept the code as non-trivial easy hack, thus a valid GSoC
> application (the candidate fixed the bug and demonstrated understanding of
> LibO code), I do question the validity of this bug. Here is why:
> 
> 1. Sure, selecting (highlighting) the value  of a text|spin box makes it
> easier for the user to delete the value or input their own value. But some
> users might want to use the mouse and change the spin box value by clicking
> on spin buttons. Highlighting the value might become confusing for them. One
> man's bug is the other man's feature
> 
> 2. What to do if there are more input fields in the dialog? Select the first
> one? Or some other one? What if it's not the one the user wants to change?
> (selecting multiple input fields is iirc not possible)
> 
> 3. Finally, if we decide to select (hightlight) the values of input field(s)
> on opening the dialog, we should do it consistently in every LibO dialog and
> sidebar. 
> 
> UX team: any thoughts?

I would like to comment on these points. 

1. I see your point on this, but disagree. It's true that a user might be somewhat confused by seeing a text|spin box highlighted, but simply clicking on the up/down controls would quickly confirm the behavior. For someone who is ready to type the new value with the keyboard they would forever be stuck deleting or highlighting the value before they could do this. 

2. Perhaps my original title is unclear. My ticket was more about the value in the control that has focus not being selected, not a matter of which control has focus. My point is that whichever one has focus it should be selected so that I can easily change the value without extra keystrokes to select/delete initial value. 

3. Agree. I have seen some a mix of behaviors in LibO dialogs and I believe unless there is some specific functional reason for a particular dialog they should be consistent within the app. 

I did a quick check this morning and found any of a number of Windows examples where the value in the control with focus is highlighted:

Notepad: Edit, Goto 
Notepad: Format, Font 
Notepad++ 6.9: Search, Find… [if it auto-fills the nearest string] 
Firefox 45.0: File, Save Page As… (suggested filename) 
Firefox 45.0: Edit, Find (highlights previous search term) 
Libre Office Writer 4.1.2.3: File, Save As… (standard dialog) 
Libre Office Writer 4.1.2.3: File, Save A Copy… (standard dialog) 
Libre Office Writer 4.1.2.3: File, Print… (Number of copies) 
Libre Office Writer 4.1.2.3: Edit, Find & Replace… 
Windows: standard Save dialog for apps that suggest a filename (Paint, Notepad…)
Comment 11 Xisco Faulí 2016-10-10 11:24:56 UTC Comment hidden (obsolete)
Comment 12 Eric Harman 2016-10-10 15:12:28 UTC
I received an email indicating that this has been in NEEDINFO for a long time. It was placed in NEEDINFO on 2015-03-26 related (I think) to, "UX team: any thoughts?" There has been some discussion since that point, but the status has not been changed. I can't think of any info required of me unless I've missed something in the comments. If so, please advise.
Comment 13 Heiko Tietze 2016-10-10 15:27:12 UTC
Created attachment 127928 [details]
Two screenshots comparing current situation with expected result

Reading your report again I understand that you don't talk about traversing the dialog (tab sequence) or what control is selected, but to have the first item focused _and selected_. Reason is to directly enter the new value instead of tab/shift-tab (which was done to create the screenshots) or pressing ctrl+a in order to override the 0.18 pt for instance.

Question to the devs: Can we fix this in general? Otherwise, if every dialog needs to get touched individually, the solution would rather be a guideline - and a large number of issues.

Setting explicitly NEEDINFO for the devs.
Comment 14 Buovjaga 2016-11-01 19:18:18 UTC
Putting it to NEEDINFO will just make developers ignore it. For reference: https://wiki.documentfoundation.org/Development/EasyHacks/Creating_a_new_Easy_Hack
Comment 15 jani 2016-11-01 19:21:10 UTC
As long as it is unconfirmed, it is waste of developers time to look at it.
Comment 16 Cor Nouws 2016-11-01 19:34:59 UTC
Mind: having the focus is not the same as having the content (if relevant) selected
Comment 17 Paddy Landau 2016-11-02 09:40:04 UTC
I agree that this would be a great fix. It has always slowed me down, but I never thought to create or search for a bug report!
Comment 18 Joel Madero 2016-11-12 16:22:34 UTC
Why is this UNCONFIRMED. I just did this:

Writer: Format, Paragraph
  The field with the focus is "Indent, Before text", but the current value there is not selected.

And it's pretty clear what is being requested. The value is not highlighted and it would save some time to have it highlighted right away. Pushing tab highlights *the next* value but in order to get to the first value you have to cycle all the way through which is time consuming and could be annoying for those who rely primarily on keyboard shortcuts.
Comment 19 Regina Henschel 2016-11-12 17:10:11 UTC
Please read the description in bug 103262 for the problem which such preselect behavior gives for bitmap background dialog.
Comment 20 tommy27 2016-12-11 19:00:35 UTC
It seems this one has to be labeled as NEW.
Comment 21 Xisco Faulí 2017-07-13 11:19:06 UTC
Setting Assignee back to default. Please assign it back to yourself if you're
still working on this issue
Comment 22 Shinnok 2017-08-25 13:40:02 UTC
This needs a broad dev. eval. in order to be considered as an easyHack.