Description: When you go to the File -> Document Properties window -> Description tab, cursor does not behave properly, when you use tab to move between Title, Subject, Keywords fields. The cursor should mark (highlight) whole field (all characters there), when you tab between fields, it stops on the start of the field instead. Could you fix it, please? Best regards and thanks for your excellent job! pb Steps to Reproduce: 1. Go to File -> Document Properties window -> Description 2. Tab move between already filled fields Actual Results: Cursor stops on the start of the string Expected Results: Field should be highlighted (all characters marked) to easy change the content Reproducible: Always User Profile Reset: No Additional Info:
I get the following result: It stops behins the last character of the field. Buit I don't know, if this is a bug or the intended behaviour.
Works fo me in Version: 6.4.0.0.alpha0+ Build ID: 9fbedb7929936a45967ae49bc15b985f95e2ebd3 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3;
(In reply to raal from comment #2) > Works fo me in Version: 6.4.0.0.alpha0+ > Build ID: 9fbedb7929936a45967ae49bc15b985f95e2ebd3 > CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; that means, they are highlighted. I can't confirm that with Version: 6.4.0.0.alpha0+ (x64) Build ID: ae823e4633a76d13cebc6432b9e44b9b2862326b CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; TinderBox: Win-x86_64@42, Branch:master, Time: 2019-06-26_23:06:07 Locale: de-DE (de_DE); UI-Language: en-US Calc: threaded
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?
For gtk3 VCL backend I confirm with raal that field content is highlighted on tab navigation entry for Title, Subject, and Keywords fields. For gtk2, gen, and windows I see the cursor positioned after the last character of the field contents on tab entry.
(In reply to Jim Raykowski from comment #5) > For gtk3 VCL backend I confirm with raal that field content is highlighted > on tab navigation entry for Title, Subject, and Keywords fields. For gtk2, > gen, and windows I see the cursor positioned after the last character of the > field contents on tab entry. it used to work in gen the same way gtk3 does Version: 6.1.0.0.alpha1+ Build ID: 3a801799536e6870f2fb111b1cc00b9575a35a39 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: x11; Locale: ca-ES (ca_ES.UTF-8); Calc: group
REgression introduced in range https://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=da9a539999fc8ae47a78542ce646005f3a9be868..852a6a57f99f8ceacee791329f2e6ca04a28dc58 @Caolán, I thought you might be interested in this issue...
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/+/82d3ec916bda195e45d3ac13199fb44f0f169159%5E%21 Resolves: tdf#126190 don't default to WB_NOHIDESELECTION It will be available in 6.4.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.
backport to 6-3 in gerrit
Verified in Version: 6.4.0.0.alpha0+ Build ID: 47a774fbef8c224e4853de3fdd0230b9442bb716 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: x11; Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US Calc: threaded @Caolán, thanks for fixing this issue!! I don't think we need to backport it to 6.2 considering it's a minor issue...
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-6-3": https://git.libreoffice.org/core/+/78ab679130b5110c66c42b0ed6760791de0c316f%5E%21 Resolves: tdf#126190 don't default to WB_NOHIDESELECTION It will be available in 6.3.0.2. 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.