https://bugs.documentfoundation.org/show_bug.cgi?id=126190
V Stuart Foote <[email protected]> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |[email protected],
| |[email protected],
| |[email protected]
--- Comment #4 from V Stuart Foote <[email protected]> ---
On Windows 10 Home 640bit en-US (1809) with
Version: 6.4.0.0.alpha0+ (x64)
Build ID: a9885aed4ee65067613e5506771b6ae6b5e0bae0
CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win;
TinderBox: Win-x86_64@42, Branch:master, Time: 2019-07-04_01:38:09
Locale: en-US (en_US); UI-Language: en-US
Calc: threaded
Don't agree that selection should be made upon landing in the field--we don't
do that anywhere else in the UI.
Otherwise, cursor positions to start of field using <Tab>, or prior field with
<Shift><Tab>
Selection of the field text is then done with normal edit control with
<Shift>+<End>; and that slection (i.e. highlight) is only released with the
<Shift>+<Home>--not an <Esc> which closes the dialog.
If at the end of the field text, the opposite <Shift>+<Home> selects back to
the start of the field text; and then released with <Shift>+<End>.
IMHO this all is correct--I don't want the field selected (highlighted) on
landing in the field. I want to specifically select it or release the selection
and have control over the edit just like any other fielded data.
The <Esc> close is a little weird--but seems to behave consistently. Only other
issue is being able to move to the next field with selection/highlight still in
place. Not sure that is the right behavior.
But IHMO => WF the OPs issue.
@Jim, Caolán any opinion here?
--
You are receiving this mail because:
You are the assignee for the bug._______________________________________________
Libreoffice-bugs mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
