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.
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
(This is an automated message.) LibreOffice development currently prioritizes bugs with the so called MAB (most annoying bugs) -- as this bug has not run through that process (including writing a short rationale for this bug being a candidate and other who are watching the tracker bug silently approving that rationale etc.) its priority is set to high. Note this is effectively no change in the urgency assigned to this bug, as we are currently not making a difference between high and highest and severity is untouched. You can find out more about MABs and how the process works by contacting libreoffice qa on irc: http://webchat.freenode.net/?channels=libreoffice-qa The QA wiki page also gives you hints on how to get in contact with the team (if IRC fails you, your next best choice is the mailing list): https://wiki.documentfoundation.org/QA
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
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'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.
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.
Migrating Whiteboard tags to Keywords: (easyHack, difficultyBeginner, skillCpp) [NinjaEdit]
JanI is default CC for Easy Hacks (Add Jan; remove LibreOffice Dev List from CC) [NinjaEdit]
Please make sure that this does not break the fix for bug 82784.
(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…)
Dear Bug Submitter, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping-20161010
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.
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.
Putting it to NEEDINFO will just make developers ignore it. For reference: https://wiki.documentfoundation.org/Development/EasyHacks/Creating_a_new_Easy_Hack
As long as it is unconfirmed, it is waste of developers time to look at it.
Mind: having the focus is not the same as having the content (if relevant) selected
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!
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.
Please read the description in bug 103262 for the problem which such preselect behavior gives for bitmap background dialog.
It seems this one has to be labeled as NEW.
Setting Assignee back to default. Please assign it back to yourself if you're still working on this issue
This needs a broad dev. eval. in order to be considered as an easyHack.
Changing priority back to 'medium' since the number of duplicates is lower than 5