Download it now!
Bug 126190 - Cursor behavior in the File -> File Properties window
Summary: Cursor behavior in the File -> File Properties window
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
6.2.4.2 release
Hardware: All All
: medium minor
Assignee: Caolán McNamara
URL:
Whiteboard: target:6.4.0 target:6.3.0.2
Keywords: bibisected, regression
Depends on:
Blocks: File-Properties
  Show dependency treegraph
 
Reported: 2019-07-02 11:10 UTC by Peter
Modified: 2019-07-17 09:59 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Peter 2019-07-02 11:10:23 UTC
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:
Comment 1 Dieter 2019-07-02 12:36:29 UTC
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.
Comment 2 raal 2019-07-02 16:08:43 UTC
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;
Comment 3 Dieter 2019-07-03 18:29:15 UTC
(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
Comment 4 V Stuart Foote 2019-07-04 05:05:29 UTC
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?
Comment 5 Jim Raykowski 2019-07-05 03:24:36 UTC
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.
Comment 6 Xisco Faulí 2019-07-09 14:08:43 UTC
(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
Comment 7 Xisco Faulí 2019-07-10 07:49:11 UTC
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...
Comment 8 Commit Notification 2019-07-16 13:19:34 UTC
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.
Comment 9 Caolán McNamara 2019-07-16 14:05:31 UTC
backport to 6-3 in gerrit
Comment 10 Xisco Faulí 2019-07-17 09:58:30 UTC
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...
Comment 11 Commit Notification 2019-07-17 09:59:38 UTC
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.